Machine Identity Audit Evidence for SOC 2

Why machine identity audit evidence for SOC 2 is a new ask

An auditor used to be able to assume a person sat behind each special action. Check the identity, check the approval, check the log line, move on. An autonomous agent breaks that assumption quietly. The identity in the log is real. The action is real. The human behind it can be one workflow removed. Or none at all.

Teleport's read of the AICPA Trust Services Criteria is blunt about where this lands. Auditors treat "no human request" behind a special action as a major gap, full stop. The criteria never mention AI. Auditors apply the same Common Criteria they always have. So this is not a new checklist item. It is the old checklist, applied to an identity type most logging never learned to answer for.

So the real question splits in two. Was there a human, or a pre-approved rule standing in for one, behind this agent action? Can you prove it with a record an auditor can check on their own? Rather than take your word for it.

It helps to say plainly why this is not a paperwork problem. Say an auditor cannot get a straight answer to "who or what approved this." They do not write a finding that says so gently. They write a gap. A gap in access control tends to widen each other finding around it. The reviewer starts asking what else the team assumed rather than proved.

What CC6 and CC7 actually expect from a machine identity

The AICPA Trust Services Criteria carry most of the weight for agents in two groups. CC6, logical access, asks how a company provisions, verifies, allows, and removes identities. And whether access follows least privilege. For an agent, that becomes a plain test. Did this action run under an approved identity, with only the authority it needed? Can you prove it after the fact? A shared connector account letting five bots act under one name fails that test on day one. No matter how good the base model is.

CC7, detection and monitoring, asks whether the company watches for odd or unapproved activity. For an agent, that means logging each action, input, output, and the event that triggered it. In a store a person cannot quietly edit. A log that records only allowed calls, and skips denials and blocked tries, answers no to CC7. An auditor sees the gap before finishing the first page.

That proof has to satisfy both groups at once. An identity story for CC6. A tamper-evident activity record for CC7. Most agent platforms can show you one. Few can show you both from the same base record.

Worth naming plainly: these two groups are also the split most agent vendors get half right. A slick identity dashboard satisfies a reviewer's eye for CC6 in a demo. A pile of allowed-call logs looks like CC7 proof, until an auditor asks for the denials no one recorded.

The CC7 hash chain behind this kind of evidence

A SOC 2 Type II audit samples real transaction chains over months. Denied tries, approvals, revocation tests. That means the log itself is proof, not a backup. A log you can edit is not proof at all. It is a claim wearing evidence's clothes.

DataShield Auth targets the CC7 case directly. See how. Each governed MCP tool call, allowed or denied, lands in a SHA-256 hash-chained audit log. Sealed under Ed25519-signed checkpoints. Alter a row, and each hash after it breaks. Delete a row, and verify_chain names the crime. Tampering, insertion, deletion, and truncation are distinct, reportable verdicts. Not one pass-or-fail flag. Verify a sample chain yourself, rather than take this paragraph's word for it.

Pentest Testing's guide to AI agent audit trails lists what a solid chain needs, in order. First the requester or trigger, then the normalized request. Next, which agent and setup ran, and the passed-down scope it carried. Then the policy call, the execution and result, and the review after. Miss a link, and the chain stops being proof. It becomes a story an auditor has to take on faith. Which is the one thing a SOC 2 audit refuses to do.

Why CC6 needs a scope ceiling, not just an identity

Naming the agent is not the same as bounding it. CC6.1 asks for least privilege. For an agent, least privilege means a hard ceiling on what any single passed-down credential can reach. The system checks that ceiling at the moment of the call. It does not assume the ceiling from a role given weeks earlier.

Auth's dispatch pipeline handles exactly that. It checks a token's scope ceiling on each governed call. So a passed-down credential can never grant more access than its owner intended. That holds even for a global admin's own passed-down tokens. Pair that with a mid-session revocation re-check on each call. Auth downgrades a suspended agent on its very next action. Not at the end of a session, or at token expiry. This kind of proof is strongest when the identity story and the activity log come from the same pipeline. That is the only way to prove the pipeline enforced the ceiling on the call the log line describes. Not just a rule set once and hoped for.

That pairing is the whole argument in short. This kind of proof is not one artifact. It is a chain of them: an identity, a bounded scope, a live check on each call, and a record of the result no one can quietly touch later. Weaken any one link, and the other three stop meaning what they claim to mean.

Where DataShield's own SOC 2 status honestly stands

To be direct about it: DataShield does not hold a SOC 2 attestation today. SOC 2 Type II is planned, not done. Nothing on this page claims that badge early. Nothing here claims DataShield sits inline, filtering agent traffic live, either. It does not. DataShield tokenizes data at ingest. Agents query tokens over MCP. Detokenization is a special, audited vault action. That is governance by design, not a live filter. This matters when an auditor asks how the control works.

In place of an early attestation, we offer the system this post describes. Scope-ceiling MCP tool tokens. A mid-session revocation check on each governed call. Break-glass access that is time-boxed and dual-logged. And a hash chain anyone can verify, rather than take on faith. For a Type I or Type II talk with your own auditor, that system is the raw material. It is what machine identity audit evidence for SOC 2 is made from. Read the design for the pipeline stage by stage, as it runs in code. Not as a diagram drawn for a sales deck.

We'd rather a buyer read this paragraph and decide the system is enough for now. Than discover the gap during their own audit cycle.

Frequently asked questions