What "One Place to See Everything" Actually Requires: Audit Logs at Platform Scale

"We log everything" is easy to say and hard to verify from the outside. The more useful question for a security-conscious evaluator isn't whether a platform has an audit log — almost every platform does, somewhere — it's what specifically guarantees an action gets captured, and what the honest limits of that coverage are today. Audit-trail completeness is repeatedly named in 2026 agentic-AI governance research as one of the sharpest differentiators between AI deployments organizations trust enough to scale and ones that stay stuck in pilot. Here's the actual mechanics for Piskes.

What's captured, and how it's enforced

Audit logging runs through a dedicated append-only worker — records written there aren't editable after the fact, which is the baseline property any audit trail needs to be worth trusting; a log an admin can quietly edit isn't really an audit log. Twenty-five separate Workers across the platform bind to this audit service, which is a meaningfully wide surface — this isn't one app's activity feed, it's a shared logging path a majority of the platform's backend services write through.

Coverage isn't just a convention teams are asked to follow. A dedicated guardrail check runs at commit time and fails the build if a new DELETE route ships without a corresponding audit-log call. That's the difference between "we try to log destructive actions" and "code that deletes something without logging it doesn't get committed" — the second is a much stronger claim, because it doesn't depend on every engineer remembering the rule on every route, every time.

Logged data is exported nightly in NDJSON format to R2 storage, which gives the platform a durable, queryable copy of audit history outside the live database — useful both for retention and for the kind of after-the-fact investigation an audit trail exists to support in the first place.

What isn't there yet, stated plainly

This is the part a features page usually leaves out, and it's worth including precisely because a real diligence process will find it anyway: the audit log table doesn't currently have a workspace_id column. In a platform where multiple workspaces share infrastructure, that's a meaningful limitation — it constrains how cleanly audit data can be filtered and scoped per workspace today, and it's a known gap, not an oversight nobody's noticed.

There is also no customer-facing audit-log export API yet, and no SIEM integration — no built-in way to stream Piskes's audit events into a customer's own Splunk, Datadog, or equivalent security tooling. For a security team used to centralizing every vendor's audit trail into one monitoring system, that's a real current gap, not a minor inconvenience. Both of these are roadmap items, not shipped capabilities, and the honest way to describe them is exactly that — direction, not done.

Why the gap is worth stating rather than glossing over

A platform that lists "audit logs" as a bullet point on a security page and stops there is asking a buyer to trust a claim with no texture to it. Stating specifically what's captured (every bound Worker's actions, enforced by a build-time check on delete routes, append-only, exported nightly) alongside what isn't yet built (workspace-scoped filtering, self-service export, SIEM integration) gives a security reviewer something they can actually act on: know what to rely on today, and know what to ask about again before treating this as a completed capability rather than a maturing one.

That's a more useful answer than either extreme — neither "audit logging is fully enterprise-grade" nor "we don't really have this yet" is accurate. The real answer is specific: strong, enforced, real-time capture with a clear mechanism behind it, and two concrete gaps — tenant scoping and external export — that are known and sequenced as next work rather than quietly unaddressed.