Attribution: Every Change Traces to the Human Who Initiated It

Only 21.9% of organizations treat AI agents as independent, identity-bearing entities in their security model, per Gravitee's State of AI Agent Security 2026 survey of 900+ executives and practitioners. The most common agent-to-agent authentication method in the same survey: shared API keys, at 45.6%. Most agent work today ships under somebody else's credential. That is the attribution problem in one sentence: the record says a human did work a human never saw.

Attribution is the first of the seven properties an auditable agent system has to satisfy, and it is the one the rest stand on. Every claim in the compliance case (who approved, who was segregated from approving, who is accountable when a change breaks) resolves to identity. If the identity is wrong, no downstream control can be right.

(Caveat up front: Gravitee sells agentic IAM products, and the survey's methodology disclosure is thin. Treat the precision skeptically; the direction is hard to argue with.)

The bar: a distinct AI identity, scoped to the initiating human

An AI cannot be deposed, fired, or held liable. A person can. So every action an agent takes must resolve to a responsible human, and the record must never confuse the two. Concretely:

  • AI work runs under a distinct, synthetic AI identity, never a borrowed human token. Human-authored and AI-authored are always distinguishable in the record.
  • That AI identity is scoped to the human who initiated the task. Not one shared bot per vendor: this change exists because this person asked for it, and the credential itself carries that binding.
  • Every artifact carries the identity that performed it. Commits, PRs, approvals, deploys. The audit answer to "who did this?" is always a real entity, never "the bot."

Brex states the requirement plainly in its build log: agent work "needs to be attributed back to an actual human and not just a bot." How Brex implements that, it does not say.

No shipping platform fully meets this bar today. The per-initiating-human scoping in the second bullet is the standard to hold, not the current state of the market. Here is where the field actually stands.

Where the platforms stand: one full chain, several halves

PlatformDistinct AI identityBound to a humanScoped per initiating humanScoped per role
GitHub Copilot cloud agentYes: signed commits, "Verified" badgeYes: requester as co-authorNo: one shared Copilot actorNo: one actor across functions
Cursor cloud agentsYes: HSM-backed Ed25519 commit signingNot documentedNoNot documented
OpenAI Codex cloudUndocumentedUndocumentedNoUndocumented
Google JulesUndocumentedUndocumentedNoUndocumented

Copilot is the only complete documented attribution chain in the field. Its commits are "authored by Copilot, with the developer who assigned the issue or requested the change to the pull request marked as the co-author," signed so they show as Verified. Automations extend the chain: PRs opened by an automation are attributed to the user who created it. The gap is scoping. Copilot is a single shared actor; the human binding lives in a co-author field, not in the credential.

Cursor has the cryptographic half. "Cloud Agents sign every commit with a HSM-backed Ed25519 key," so your team can confirm a commit came from Cursor. But its docs describe no link from the commit to the human who launched the run. "Came from Cursor" answers half the auditor's question. Codex and Jules say nothing about commit identity at all; Codex's setup flow suggests work rides the user's own GitHub connection, which would be exactly the borrowed-identity pattern, but that is an inference, not a documented fact. Identity vendors are building the substrate (Microsoft's Entra Agent ID gives agents first-class directory identities with logged authentication), but a directory entry is not yet a per-task binding to a requester.

Scoped per role: the second axis segregation of duties needs

Per-initiating-human scoping answers accountability: which person is on the hook for this work. Per-role scoping answers actor distinctness: which function performed this step. A role-scoped identity is persistent per function: one identity that only ever implements, a separate identity that only ever reviews, no matter who initiated the task.

The difference is invisible while a human holds the approving step, because a human approver is already a distinct actor. It becomes load-bearing the moment the approver is itself AI, the shape Intercom and Uber run in production.

Segregation of duties requires three distinct actors: the authoring agent, the initiating human, and an approver distinct from both. Hand one AI identity, scoped to whoever started the task, both the authoring and the reviewing step of the same task, and authored-by and approved-by resolve to the same actor. Every per-human requirement is met, and the record still shows an author approving its own work.

When the implementing function and the reviewing function each hold their own identity, author and approver stay distinct on every task that routes through both, with nothing left for a capability boundary to catch. In a workflow engine the mechanism is a pin on the step: the review step names the reviewing identity, and that pin wins over whichever identity is driving the rest of the task (one managed platform builds its review gate this way). Copilot reaches the same guarantee from the opposite side, a single shared actor with the approval capability removed, and that construction holds only while every approver is human.

Neither axis replaces the other. Per-role identity without the human binding loses the accountability trace.

Attribution is what the other controls stand on

Without a distinct AI identity, segregation of duties is unenforceable: if the agent commits as you, the system cannot stop you from approving your own bot's work. Copilot shows the payoff of getting it right: because the requester is the attributed author, GitHub "prevents the user who asked Copilot cloud agent to create a pull request from approving it." The audit trail needs it too. Intercom keeps every AI-approved PR "labelled, logged, and queryable," and pairs the label with a human on the hook: "The engineer who ships a change is expected to watch it go live, monitor its behaviour in production, and be ready to roll back."

This is the direct replacement for the laptop model's "commits come from your token," which makes attribution trivially true and completely uninformative (see why the laptop model breaks). Attribution is a property the system either has or does not have; it is produced upstream, when you decide how work is assigned. The mechanics that generate the evidence (issuing a distinct AI identity and binding it to the requesting human) live in agent identity and binding to the human.

The bar, restated

A distinct, synthetic AI identity on every commit, PR, and approval, distinguishable from human work, and scoped to the human who initiated the task. Where the approving step is itself AI, a distinct identity per role as well, so author and approver can never resolve to one actor. Copilot's co-author field is the closest documented approximation. Nobody ships the credential-level binding yet. Hold the bar anyway; it is the property every downstream control assumes.