SOC 2 for AI Agents: The Control Matrix Wasn't Built for a Caller That Isn't a Person

Ask a SOC 2 auditor to test logical access controls and they reach for a familiar script: pull the user list, sample a few accounts, confirm each one maps to a real employee with a documented reason to have it, check that access was reviewed in the last quarter. That script assumes the thing being tested is a person who logged in with a password and MFA, on a cadence slow enough that a quarterly review actually reflects reality. An AI agent calling your API a few thousand times a day, provisioned once and never looked at again, doesn’t fit the script — and most companies bringing agentic AI into a SOC 2 environment are discovering that the hard way, mid-audit.

The failure: a service account standing in for an identity

A team wires an agent into a workflow — pulling records from a CRM, updating a billing system, triaging support tickets — the same way they’d wire in any other integration: one API key, provisioned once, shared across whatever the agent touches. It works. Nobody revisits it, because nothing about it looks different from the dozen other service accounts already on the list.

Then the SOC 2 auditor asks the standard question: who has access to the billing system, and why. The answer for a human is a name, a role, a ticket approving it. The answer for the agent is a shared API key with no individual accountability behind it, used by whichever workflow happened to invoke it that day, with no record of which specific action used which grant of authority. The auditor’s next question — show me that access was reviewed and is still appropriate — has no clean answer either, because “appropriate” for an agent isn’t a quarterly snapshot. The scope it actually needs can change from one task to the next, and a credential provisioned in January with broad access is not meaningfully “reviewed” by someone glancing at a spreadsheet in April. This is the same shape of problem covered in non-human identity governance: the frameworks were built for identities that don’t multiply, delegate, or improvise, and an agent does all three.

Why mapping the agent onto existing controls doesn’t hold up

The instinct is to treat the agent like any other service account and check the same boxes: rotate the key, log it in the same access-review sheet, call it done. That satisfies the paperwork without satisfying what the controls are actually there to verify.

• CC6.1 (logical access is restricted to authorized users) assumes “authorized” is a static grant checked at login. An agent’s authorization should depend on what it’s doing right now — an agent triaging tickets has no legitimate reason to touch payroll data, even if the underlying key technically can reach it.
• CC6.3 (access is removed or adjusted based on role changes, and least privilege is enforced) can’t be evidenced by a shared key used across five different workflows. There’s no “role” to point to — just one credential wearing five different hats, none of them individually scoped.
• CC7.2 (the entity monitors for anomalies) assumes there’s a log granular enough to show what normal looks like per identity, so a deviation is visible. A shared service-account log shows that calls happened, not which task, which policy decision, or which human’s intent authorized each one — which is the same gap covered in audit trail forensics: you can’t reconstruct what an incident needs from a log that was never granular enough to support it.

None of this is the auditor being unreasonable. It’s the control language — written for humans logging into systems — being asked to certify something it was never designed to describe. A findings letter that says “access review process does not adequately address non-human identities” isn’t rare anymore; it’s becoming the default outcome for any team that treated an agent like a slightly weirder employee instead of a distinct class of identity.

Where the evidence actually has to come from

• Every agent needs its own identity, not a shared service account. Individual accountability — the thing CC6.1 is actually testing for — only exists if a specific call can be traced to a specific agent instance and the workflow it’s serving, the same way scoped credentials narrow what any one grant can do in the first place.
• Access has to be scoped to the task, not provisioned once and left broad. Least privilege for an agent means the credential in its hands right now covers only what the current call needs — not a standing grant sized for the broadest thing it might ever be asked to do.
• The audit trail has to be continuous evidence, not a point-in-time attestation. A quarterly access review answers “did this look fine three months ago.” An auditor testing an agent needs to see what happened, in order, tamper-evident — because an agent’s risk profile can shift inside a single afternoon, not a single quarter.
• Authorization and secret disclosure have to be provably separate events. A control that says “access was approved” only means something if approval and the ability to use the credential are distinct, auditable steps — the same split covered in decision tokens.
• Monitoring has to work at the granularity of one agent, one call, not one shared key across a fleet of workflows — otherwise CC7.2’s “monitors for anomalies” has no baseline to compare against.

The business case: turning agent access into evidence an auditor can use

This is close to the reason Fullmakt exists as a broker rather than a vault teams query themselves:

• Every agent, workflow, or collection gets its own credential identity — never a shared key reused across unrelated tasks — so “who has access to X” has a real answer instead of a shrug toward a shared secret.
• Access is scoped per endpoint and method through policy, not provisioned broad and hoped to stay unused. Least privilege isn’t a quarterly aspiration; it’s what the broker enforces on every call, which is the evidence CC6.3 is actually asking for.
• Every call, approval, and credential issuance lands in one cryptographically chained audit trail, so “show continuous monitoring” is a query against a real record instead of a spreadsheet someone updates before the audit.
• The model never sees the raw secret. The broker dispenses a scoped decision, executes the call, and the underlying credential never transits through the agent’s context — closing the exact gap that turns “we rotate keys” into evidence rather than a policy statement nobody can verify happened.
• Because policy enforcement sits at the broker, on the data plane, the same system that authorizes a call is the system that logs it — auditors get one control to test, not a patchwork of “the agent’s own logging” plus “whatever the API provider happens to record.”

None of that replaces a SOC 2 audit. It replaces the part of the audit that currently has no good answer — the part where the auditor asks a question built for human users and someone has to explain, again, why the AI agent doesn’t quite fit the template.

FAQ

Does SOC 2 even mention AI agents specifically? Not by name — the Trust Services Criteria are written generically enough to apply to any access, human or not. That’s exactly the problem: nothing in CC6 or CC7 tells you how to satisfy it for a caller that isn’t a person, so teams default to treating agents like service accounts and discover the gap when an auditor pushes on it.

Can we just document our agent as a service account and move on? You can, and many teams do for the first audit cycle. It tends to produce a finding or a qualified opinion once the auditor asks the follow-up questions — individual accountability, least privilege per task, and continuous monitoring don’t hold up under a shared key used across unrelated workflows.

Is this only relevant to SOC 2, or does it apply to ISO 42001 and the EU AI Act too? The underlying gap is the same one covered in ISO 42001 for a credential broker and the EU AI Act’s governance requirements: every framework that assumes access is granted to a person and reviewed periodically needs the same fix when the caller is an autonomous agent — per-identity scoping and continuous, evidentiary logging.

What’s the fastest way to know if we’d survive this question in an audit? Ask your team to show, for one AI agent, exactly which credential it used for a specific call last week, what scope that credential carried, and who or what authorized it. If the honest answer involves grepping application logs or can’t be answered at all, that’s the finding waiting to happen.

Does scoping credentials per agent slow anything down operationally? Less than a failed audit does. Scoped, short-lived credentials are issued per call through policy the broker already evaluates — the overhead is a broker hop, not a manual provisioning step, so the audit trail comes free with the access control rather than as separate work bolted on afterward.

An auditor asking “who has access to this, and can you prove it’s still appropriate” isn’t a new question — it’s the oldest question in access control. What’s new is a caller that can’t answer it the way a person can. The fix isn’t a better spreadsheet; it’s an access layer that was built to answer that question continuously, for an identity that was never going to sit still long enough for a quarterly review to catch up to it.