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 for AI agents is whoever's authorization the agent acted under. That's true 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 special actions to trace to a named person. Not to an agent. Not to a shared system account. A detailed guide from Pentest Testing makes the same point from the proof side. A machine ID 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 behind this action? Or a pre-approved rule standing in for one? 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. Or under what rule. Pentest Testing is direct about this. Service accounts hide the real user. They often carry more power. More 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 it. So can a hijacked agent with admin-adjacent access. A hijacked agent with valid credentials writes a normal-looking log entry. An allowed ID ran an allowed call. That entry can be edited or wiped. No trace left. You lose the proof right when you need it most.

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. They lack exact parameters. And a firm link to the action taken. A chat approval has no cryptographic tie to what ran. It carries no stated scope. And no trail an auditor can check. Not 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. Fixing this means naming the accountable human for AI agents. At each step. Not just at the start of a session.

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. The same they use for any system touching customer data. CC6 and CC7 carry most of the weight.

Logical access is CC6. CC6.1 through CC6.3 ask how identities get set up. How they get 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 ID? With only the authority it needed? Can you prove it? A shared connector account fails this test on day one. It lets five automations act under one name.

CC7 is detection and response. CC7.1 and CC7.2 ask if the company watches for anomalies. And for unauthorized activity. For an agent, that becomes this: could misuse show up in what you log? Or unexpected autonomy? A log can record successful calls. But skip denials and blocked tries. Then the policy version in force answers no. Teleport adds a clear rule here. Log each agent action. Inputs, outputs, and the event that triggered it. Put it in a tamper-evident store. One an operator can't quietly edit.

Change management (often CC8) rounds it out. Was the change allowed? Can you trace it end to end? A ticket that approves a general goal is not proof. You need a record. It should show the agent ran those exact parameters. Pentest Testing lists what a solid chain needs. In order. Start with the requester or trigger, then the normalized request. Add which agent and config ran. Add the passed-down scope and the policy call. Finish with the execution and result. Then the review after. Miss a link, and the chain stops being proof. It becomes a story.

One more split matters. A Type I report checks one thing. Are controls designed right, at one point in time? A Type II report covers a stretch of months. It's the one most enterprise buyers want. The auditor samples real transaction chains. Denied tries, 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. The human or policy that opened the session sets it.

DataShield Auth runs this as a pipeline. Each governed tool call passes through a scope ceiling check, then an authority tier check. Then a mid-session revocation re-check runs. Metered dispatch follows, then a sealed audit entry. A passed-down 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. Power that should have ended keeps working, because nobody re-checked it. Per-call metering ties to the agent that made the call. It gives you the CC6.1 answer in one line: this ID, this scope, this call, this result. That one line names the accountable human for AI agents, on each call, not just the first one.

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

Each 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. A break-glass session might leave a thinner trail than a normal one. If it does, you've built the one path an attacker would want most. It's also the one path an auditor should trust least.

So break-glass needs to be a dual-logged event with its own evidence. The start gets logged. Each action under the elevated session gets logged too. 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 each action under it get sealed into the hash chain. That way, 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 each 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 call itself. It shows which token, which scope, which tool, allowed or denied, under which policy version. That's the anomaly proof CC7.1 and CC7.2 ask for. It sits 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. Detokenization is a special, audited vault action. That's governance by design, not a live traffic filter.

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

Frequently asked questions

Related reading