AI Agents and SOC 2: Who Owns the Risk?

An AI agent can have an API key, production access, and nobody who remembers granting either.

Start with the account behind the agent. Drafting a support reply is one thing. Exporting customer records, issuing credits, and changing account settings give that same chat window much greater reach.

For SOC 2, ask: who authorized this agent to do what, and what evidence shows those boundaries held? Follow its permissions all the way to the systems it can change.

Who owns an AI agent's risk?

Your organization owns the decisions it makes about deploying an agent, granting access, and accepting its operational risks. Assign a named business owner and a technical operator, with clear authority to restrict or stop the system.

The business owner approves the purpose and acceptable consequences. The technical operator manages credentials, tool configuration, releases, monitoring, and shutdown. Security challenges the design and coordinates incident handling. In a small team, one person may wear several hats. Write down who is wearing each one.

The NIST AI RMF 1.0 Core calls for documented responsibilities, executive accountability, and ways to deactivate systems whose behavior conflicts with intended use. Those outcomes help structure ownership; they do not constitute an agent certification scheme.

A vendor may operate the model while your team controls the connected account. Record that division. Our vendor management gaps guide explains why collecting a supplier's report is only one part of evaluating the relationship.

Does SOC 2 require specific AI agent controls?

SOC 2 evaluates controls within a defined service organization system against applicable Trust Services Criteria, as the AICPA's SOC 2 overview explains. It does not provide a universal agent checklist or certify that a model is safe in every deployment.

An agent that can change customer data may affect access control, change management, monitoring, or incident response. Discuss its role in the system boundary and relevant risks with your auditor. The controls should address your service commitments and actual deployment.

The register and safeguards below are practical recommendations. They are not prescribed SOC 2 requirements. NIST's Generative AI Profile is also a companion to a voluntary risk framework, rather than a replacement for a SOC 2 examination.

Read SOC 2 requirements and the broader AI security controls guide.

What permissions should an AI agent have?

Give an agent the smallest practical set of actions and data access needed for its approved job. Enforce those limits where the action executes, through tool authorization and downstream access controls.

OWASP's Excessive Agency guidance identifies excess functionality, permissions, and autonomy as causes of risk. It recommends narrower tools, minimum privileges, and authorization outside the model's judgment. A prompt asking the agent to behave responsibly cannot enforce those boundaries.

Inspect each connector account, including those available to delegated subagents. Compare the access you intended to grant with the access the connected system actually enforces.

NIST's August 27, 2026 agent identity guidance warns that credential sharing creates accountability gaps. It recommends identifiable agents and appropriately delegated access. Apply that guidance through workload identities or scoped user delegation. Attach the initiating user or system and relevant tenant context to action records.

A permission added to fix one failed task can quietly become permanent.

What should an agent access register contain?

Keep one entry per deployed agent and environment. Link its owner, effective access, approval rules, shutdown procedure, and evidence. An inventory that says only “AI support tool” leaves the important questions unanswered.

Copy these fields into your access review process. Add names, configuration links, and tested procedures another person can use.

Agent name and environment:
Approved purpose and prohibited actions:
Business owner and technical operator:
Workload identity or delegated user scope:
Tools, allowed operations, and data boundaries:
Credential issuer, expiry, and revocation steps:
Actions requiring approval and authorized approvers:
Model, prompt, tool, and policy version references:
Action log location, access rules, and retention:
Last access review, reviewer, and resulting changes:
Last shutdown test and observed result:
Exceptions, accepting owner, and expiry date:

Give the completed entry to someone who did not build the integration. Can they find the credential issuer and stop future actions? If they need the original developer to explain it, the entry needs more work.

Add the register to your SOC 2 readiness checklist, alongside existing access reviews. Review it when ownership, connected systems, or permitted actions change.

When should a human approve an agent action?

Require approval where a mistaken action could cause material harm. OWASP recommends human approval before high-impact actions. Give the reviewer enough detail to make that decision.

For example, a reviewer approving a customer data export should see the recipient, included records, destination, and purpose. Bind approval to that proposed export. If the agent changes the destination afterward, the earlier decision should no longer authorize execution.

Then try to break the approval path: reject the request, let it time out, change its parameters, and replay an earlier approval. Check what happens when the approval service goes down. Does the action stop, or does it slip through?

Keep low-impact, reversible work practical, and give reviewers time and context for consequential decisions.

What would an agent incident look like?

An incident can begin with ordinary business content that an agent mistakes for authority. OWASP describes indirect prompt injection through external material such as files and websites. Access boundaries can limit the damage even when the model follows a hostile instruction; they do not prove that it will resist every injection.

Hypothetical incident: A customer support agent reads an uploaded troubleshooting document. Embedded instructions tell it to change an account's recovery address. Its connector has account administration permissions, although the approved use case only needs ticket summaries. The agent submits the change. No separate approval is required.

Now the response team has to trace the change: which identity acted, which account changed, and which authorization checks ran? Check the queue, too. Disabling the chat interface may leave a worker and its credentials active.

A useful exercise is to revoke the credential, terminate active sessions where needed, cancel pending work, and verify that subsequent tool calls fail across workers and delegated agents. Then test recovery under a newly restricted identity. Preserve the incident record and relevant configuration versions.

The shutdown test is simple to state: after you stop the agent, can any connected worker still act?

What evidence makes agent controls reviewable?

Evidence should let a reviewer trace an action from authorization to outcome. Keep enough context to reconstruct sampled actions without creating another uncontrolled store of customer data.

For a consequential action, retain the timestamp, agent identity, initiating user or system, affected resource, tool operation, authorization result, approval reference where applicable, and execution outcome. Keep the configuration versions, too. A reviewer needs to know which rules applied when the action happened.

Protect these records from unauthorized modification. Define retention and access deliberately; storing every raw prompt indefinitely can expose sensitive material unnecessarily.

Keep access reviews, permission removals, release approvals, failed-action tests, and shutdown exercises alongside operational records. A screenshot of today's settings does not establish what ran three months ago. Our guide to SOC 2 evidence explains that distinction.

When evaluating a supplier, use the same discipline. Read the examined system boundary and period before treating its report as evidence about your agent deployment. The SOC 2 report red flags guide provides a reading checklist.

FAQ

Does our AI provider's SOC 2 report cover our agent?

It may inform your assessment of the provider's services within the report's scope. It does not automatically establish that your connector permissions, approval workflow, or credential handling are effective.

Can an agent use a shared service account?

Prefer a distinct agent identity or scoped delegation that preserves attribution. Shared accounts complicate permission separation and revocation. If you inherit one, assess whether you can identify the agent's actions and stop its access independently before accepting that arrangement.

Must every tool call receive human approval?

No universal SOC 2 rule requires that. Define approval requirements around the deployment's risks, commitments, and potential consequences, then test that the implemented workflow follows those decisions.

What should we ask our auditor first?

Describe what the agent can read and change, where it operates, and who authorizes its access. Ask how that affects scope and evidence expectations. Bring those details to your auditor selection conversation.