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 every privileged action. Check the identity, check the approval, check the log line, move on. An autonomous agent breaks that assumption quietly, because the identity in the log is real, the action is real, and 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 privileged action as a major gap, full stop. The criteria themselves never mention AI. Auditors apply the same Common Criteria they always have, which means this is not a new checklist item, it is the old checklist applied to an identity type that most logging was never built 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? And can you prove it with a record an auditor can check on their own, rather than take your word for?

It helps to say plainly why this is not a paperwork problem. An auditor who cannot get a straight answer to "who or what approved this" does not write a finding that says so gently. They write a gap, and a gap in access control tends to widen every other finding around it, because the reviewer starts wondering what else was assumed rather than proven.

What CC6 and CC7 actually expect from a machine identity

The AICPA Trust Services Criteria carry most of the weight for agents in two families. CC6, logical access, asks how identities are provisioned, authenticated, authorized, and removed, 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, and can you prove it after the fact? A shared connector account letting five automations act under one name fails that test on day one, no matter how good the underlying model is.

CC7, detection and monitoring, asks whether the organization watches for anomalies and unauthorized activity. For an agent, that means logging every action, input, output, and the event that triggered it, in a store an operator cannot quietly edit. A log that records only successful calls and skips denials and blocked attempts answers no to CC7 before an auditor even finishes reading it.

That evidence has to satisfy both families at once: an identity story for CC6, and a tamper-evident activity record for CC7. Most agent platforms can show you one. Few can show you both from the same underlying record.

Worth naming plainly: these two families are also the split most agent vendors get half right. A slick identity dashboard satisfies a reviewer's eye for CC6 in a demo, and a pile of successful-call logs looks like CC7 evidence until an auditor asks for the denials that never got recorded.

The CC7 hash chain behind this kind of evidence

A SOC 2 Type II examination samples real transaction chains over months: denied attempts, approvals, revocation tests. That means the log itself is evidence, not a supporting exhibit, and an editable log is not evidence at all, it is a claim wearing evidence's clothes.

This is where DataShield Auth is built specifically for the CC7 case. Every 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 every 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 accountability lists what a solid chain needs in order: the requester or trigger, the normalized request, which agent and configuration 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 an auditor has to take on faith, which is the one thing a SOC 2 examination is built not 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 delegated credential can reach, checked at the moment of the call, not assumed from a role assignment made weeks earlier.

Auth's dispatch pipeline enforces exactly that. A token's scope ceiling is checked on every governed call, so a delegated credential can never grant more access than its owner intended. That holds even for a global admin's own delegated tokens. Pair that with a mid-session revocation re-check on every call, and a suspended agent is downgraded on its very next action, not at the end of a session or at token expiry. This kind of evidence is strongest when the identity story and the activity log come from the same pipeline. That is the only way to prove the ceiling was actually enforced on the call the log line describes, rather than merely configured somewhere and hoped for.

That pairing is the whole argument in miniature. This kind of evidence is not one artifact, it is a chain of them: an identity, a bounded scope, a live check on every call, and a record of the result nobody can quietly touch afterward. 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, and nothing on this page claims that badge early. Nothing here claims DataShield sits inline filtering agent traffic in real time either. It does not. Data is tokenized at ingest, agents query tokens over MCP, and detokenization is a privileged, audited vault action. That is governance by design, not a live traffic filter, and the distinction matters when an auditor asks how the control actually works.

What we offer in place of an early attestation is the mechanism this post describes. That means scope-ceiling MCP tool tokens, a mid-session revocation check on every 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 conversation with your own auditor, that mechanism is the raw material machine identity audit evidence for SOC 2 is made from. Read the architecture for the pipeline stage by stage, as it runs in code, not as a diagram drawn for a sales deck.

We'd rather a prospective customer read this paragraph and decide the mechanism is enough for now than discover the gap during their own audit cycle.

Frequently asked questions