The Accountable Human for Autonomous Agent Actions

Who is the accountable human for an autonomous agent action?

Here's the short answer. The accountable human is whoever's authorization the agent acted under at the moment it ran. You need a record that proves that link. A log line that just names the agent is not enough.

SOC 2 auditors are starting to ask this directly. Teleport's read of the Trust Services Criteria puts it plainly. Auditors treat "no human request" as a major gap. SOC 2 wants privileged actions to trace to a named person, not to an agent or a shared system account. A detailed guide from Pentest Testing makes the same point from the evidence side. A machine identity can show what ran. It often can't show the human, the approved workflow, the policy call, or the result behind it.

So the real question splits in two. First: was there a human, or a pre-approved rule standing in for one, behind this action? Second: can you prove it with a record an auditor can check on their own? Most teams can answer the first in a meeting. Few can answer the second with proof.

Why the attribution gap exists

Three ordinary choices create this gap. None looks wrong from the inside.

Machine identities with no owner. An agent usually runs under a service account, an API key, or a shared connector credential. That credential proves the agent to a system. It does not say which employee asked for the action, or under what rule. Pentest Testing is direct about this: service accounts hide the real user and often carry more power than any one person would get. The log shows a tool name. It does not show clear ownership.

Logs that can be edited. A standard app or SIEM log sits in a store an admin can quietly rewrite. So can a hijacked agent with admin-adjacent access. A hijacked agent with valid credentials writes a normal-looking log entry, since an authorized identity ran an authorized call. If that entry can be edited or wiped with no trace, you lose the evidence right when you need it.

Approvals that live in chat. A Slack message saying "go ahead, ship it" feels like an approval. It is not a durable record. Pentest Testing is blunt here too: chat threads are not reliable authorization records. They lack scope, exact parameters, and a firm link to the action taken. A chat approval has no cryptographic tie to what ran, no stated scope, and no trail an auditor can check without trusting a screenshot.

Put the three together and you get the pattern auditors keep flagging. An action happened. Something logged it. Nobody can trace a clean line from a named human's say-so to that one action.

What SOC 2 evidence actually expects, CC6 and CC7 style

The AICPA Trust Services Criteria never mention AI agents. Auditors use the same Common Criteria for an agent that they use for any system touching customer data. CC6 and CC7 carry most of the weight.

CC6 is logical access. CC6.1 through CC6.3 ask how identities get set up, checked, allowed in, and removed. They ask if access follows least privilege and role separation. For an agent, Pentest Testing frames the CC6.1 test in plain terms: did this action run under an approved identity, with only the authority it needed, and can you prove it? A shared connector account that lets five automations act under one name fails this test on day one.

CC7 is detection and response. CC7.1 and CC7.2 ask if the organization watches for anomalies and unauthorized activity. For an agent, that becomes: could misuse, or unexpected autonomy, show up in what you log? A log that records successful calls but skips denials, blocked attempts, and the policy version in force answers no. Teleport adds a clear rule here: log every agent action, inputs, outputs, and the event that triggered it, in a tamper-evident store an operator can't quietly edit.

Change management (often CC8) rounds it out. Was the change authorized, and can you trace it end to end? A ticket that approves a general goal is not the same evidence as a record showing the agent ran those exact parameters. Pentest Testing lists what a solid chain needs, in order: the requester or trigger, the normalized request, which agent and config ran, the delegated scope, the policy decision, the execution and result, and the review after. Miss a link and the chain stops being evidence. It becomes a story.

One more split matters. A Type I report checks if controls are designed right at one point in time. A Type II report, the one most enterprise buyers want, covers a stretch of months. The auditor samples real transaction chains: denied attempts, approvals, revocation tests. That proves the controls held up in real use, not just on paper.

Per-call authorization: the token has to name a scope, not just an identity

The fix for CC6 starts before the agent calls a tool. Instead of one broad credential for a whole session, each governed call runs on a token with a scope ceiling. That's a hard limit on what this one call may touch, set by the human or policy that opened the session.

DataShield Auth runs this as a pipeline. Every governed tool call passes through a scope ceiling check, then an authority tier check, then a mid-session revocation re-check, then metered dispatch, then a sealed audit entry. A delegated key can never carry more power than its owner meant, even for a global admin. The limit is built into the pipeline, not left to a rule someone has to remember. That's the RFC 8693 token-exchange pattern: delegation with a smaller scope, never a copy of the parent's full power.

The mid-session recheck matters as much as the first grant. Revoke or suspend an agent, and the change hits on its very next tool call. It does not wait for a long-lived token to expire. That's the direct fix for the cross-tenant exposure gap security teams worry about, where power that should have ended keeps working because nobody re-checked it. Per-call metering, tied to the agent that made the call, gives you the CC6.1 answer in one line: this identity, this scope, this call, this result.

Break-glass has to carry its own evidence, not skip evidence

Every real system needs an emergency path. Normal checks fail, or something is on fire and the approval queue can't wait. That's what break-glass access is for. It breaks least privilege on purpose, for exactly this reason.

Here's the risk. The thing that makes break-glass useful, a full override, also makes it the easiest place to lose proof. If a break-glass session leaves a thinner trail than a normal one, you've built the one path an attacker would want, and the one an auditor should trust least.

So break-glass needs to be a dual-logged event with its own evidence. The start gets logged. Every action under the elevated session gets logged. Both land in the same tamper-evident chain as ordinary calls, not a side channel. A deleted break-glass entry has to show up as a deletion, not vanish into a gap. DataShield's break-glass path runs on a time-boxed grant that revokes itself. The start event and every action under it get sealed into the hash chain, so an emergency never becomes a blind spot. More on scope, alerts, and auto-expiry in our break-glass access piece.

The hash-chained log: why tamper-evidence is the part editable logs can't fake

A log an admin can quietly edit is worth very little to an auditor, agent or no agent. The fix is not a bigger log. It's a log you can check yourself, with no need to trust whoever runs the system that wrote it.

DataShield seals every audit row with a SHA-256 hash chain, so each row is bound to the one before it. Checkpoints seal the chain with Ed25519 signatures, and those are chained too. Verification does not just say "valid" or "invalid." It names tampering, insertion, deletion, and truncation as separate results. That's the gap between "something looks wrong" and "row 4,812 was deleted after the fact." You can run the check yourself on a sample chain instead of taking a vendor's word for it.

This closes the CC7 gap directly. Instead of a log that records wins and skips denials, the chain carries the decision itself: which token, which scope, which tool, allowed or denied, under which policy version. That's the anomaly evidence CC7.1 and CC7.2 ask for, sitting in the same tamper-evident record as the actions it governs, not bolted on after the fact. GDPR-style erasure works by crypto-shredding key material, not by deleting rows. The chain stays intact even through a legal deletion request.

Where DataShield fits, and what we are not claiming

To be direct: DataShield does not hold a SOC 2 attestation today. SOC 2 Type II is planned, not done. Nothing here claims that badge. And nothing here claims DataShield sits inline in the prompt path filtering agent traffic. It does not. Data is tokenized at ingest, agents query tokens over MCP, and detokenization is a privileged, audited vault action. That's governance by design, not a live traffic filter.

What DataShield does give you is the mechanism this post covers. Auth issues scope-ceiling MCP tool tokens with a mid-session revocation check on every governed call, break-glass access that's time-boxed and dual-logged, and a SHA-256 hash chain with Ed25519-signed checkpoints anyone can verify. For a fintech agent touching customer NPI, that's the same access, logging, and retention bar GLBA, PCI DSS, and NYDFS-style examiners hold human staff to, now mapped onto an agent identity instead of skipped. See the fintech page for how that maps to GLBA and PCI DSS, and the architecture page for the pipeline stage by stage, as it exists in code, not a diagram.

Frequently asked questions

Related reading