You cannot audit what you cannot attribute

Here is a question worth putting to any AI platform, including ours. An agent has just issued a refund, changed a price, or deleted a record. Who did that?

The answer you want has two names in it: the agent, and the human whose authority it was acting under. In most stacks running today, you can get neither reliably. You get a service account, or an API key, and a timestamp.

That is not a logging problem you can fix with better logging. It is a modelling problem, and it is upstream of everything.

How the incumbent stack represents an agent

The standard approach to AI infrastructure is four vendors and a glue team: an identity provider for authentication, a payments provider for billing, a licensing service for entitlements, and a home-grown telemetry pipeline for usage.

Every one of those systems was designed before agents existed, and it shows. In that stack an AI agent is a client-credentials blob: a machine identity with no concept of acting on someone's behalf, no delegation chain, and no way to attribute what it did back to the person who authorised it.

So when the auditor asks who approved the refund, the honest answer is "a service account called prod-agent-2 did, and we believe Sarah was probably the one who set the workflow up in March". That is not an audit trail. It is a hypothesis.

Agents as principals

The alternative is to model the agent as what it is: a principal in its own right, which authenticates as itself, holds its own role bindings, and carries a delegation chain describing whose authority it is exercising.

Concretely, the record should read "Akora acting for Lee" — one entry, two names, structurally. Not reconstructed afterwards from correlated logs, but recorded that way because the schema has somewhere to put it.

Once that exists, several things stop being hard:

• Revocation has an obvious meaning. Remove the delegation, and every action that depended on it stops. You are not hunting for which keys a departed employee's agents are still holding.
• Blast radius is boundable in advance. An agent's authority is the intersection of its own bindings and what was delegated to it. That is a policy you can write down.
• The audit trail survives erasure. Personal data can be purged while audit events continue to reference principals by opaque identifier — so a GDPR erasure request does not force you to destroy your own compliance record.

That last one is the sort of thing that only looks important the first time somebody files a request.

Audit is not an enterprise feature

There is a convention in this industry that we think is indefensible: audit logs, SSO and role-based access control are enterprise-tier upsells. Two of the largest identity vendors gate all three behind their top plans.

The effect is that the organisations least able to absorb a breach — the two-person team, the small agency handling client data — are the ones sold the version with no record of what happened.

We have taken the opposite position deliberately. Audit at every tier, from the smallest account up, and never as an add-on. It is a design commitment rather than a promotion, which is the only kind worth relying on: a discount can be withdrawn, an architectural decision is harder to reverse.

The same applies to self-hosting. If you run our software inside your own boundary, you run the same build, with the same features. A self-hosted variant that lags the hosted one is a way of charging for control while quietly withholding it.

What we do not have

Certifications, and an external penetration test. Where each of those stands is on the FAQ rather than here, because a status frozen into a post outlives the status — and we are not going to put a date on a blog post to make any of it feel closer.

What we have is the substrate that makes certification achievable rather than retrofitted: an immutable, dual-attributed audit stream, infrastructure defined as code, and a data model where the answers an auditor asks for are queries rather than investigations.

If a vendor tells you they are compliant, ask what they mean. If they tell you they are designed to be auditable, ask them to show you the schema. The second conversation is the one that tells you something.

The question to take away

Not do you have audit logs — everyone says yes.

When an agent acts, does your record name the human whose authority it used, and can you produce that record without a data-engineering project?

If the answer requires joining three systems and a best guess, the logs exist and the attribution does not. Those are different things, and only one of them is worth anything when it matters.