Loading
Loading
3366 Members
Join Permit's SlackThis is a SOC 2 CC6 and ISO 27001 access control checklist for AI agents. Existing logical-access and logging controls were designed around human users, provisioned accounts, predictable sessions, and admin actions that could be tied back to a person. AI agents and MCP tool calls break that model because authority is delegated, chained, and converted into side effects after login. The answer is not to throw away OAuth, but to map CC6, CC7, and ISO 27001 Annex A to the real enforcement point: the tool call, workflow step, or sensitive action. Then produce evidence from deterministic authorization decisions, policy changes, approvals, and audit logs.
SOC 2 and ISO 27001 are not implementation checklists. They are outcome-based criteria and controls. That distinction matters because AI agents do not necessarily violate the wording of a control, but they often break the operating assumptions behind how companies prove the control works.
For SOC 2, the relevant source is the AICPA 2017 Trust Services Criteria, with Revised Points of Focus, 2022. In practice:
For ISO, the relevant source is ISO/IEC 27001:2022 information security management. Annex A includes several controls that map directly to authorization and auditability:
None of these controls say, "only humans can access systems." But most access-control evidence programs were built as if that were true.
The traditional model assumed:
That model worked reasonably well for SaaS applications, internal admin consoles, and service accounts with narrow use cases. It starts to fail when an agent is given broad delegated authority, chains multiple tools, and turns a user intent into a series of machine-executed actions.
Agents do not behave like ordinary interactive users.
An agent can operate continuously. It can call tools in sequence. It can take a token that was valid for one context and use it to trigger actions in another. It can call an MCP server, fetch data from one system, transform it, and write to another. The human may have initiated the work, but the actual side effects happen later, often through tool calls that the human never reviews line by line.
This is the core compliance problem: OAuth alone is not an agent authorization system.
OAuth remains useful. It is still the right primitive for delegated authentication and scoped access between systems. But OAuth generally answers, "Can this client obtain or use this token?" It does not fully answer, "Should this agent, acting for this user, in this workflow, with this data sensitivity, at this moment, call this tool and perform this specific side effect?"
That missing decision is where audit evidence gets weak.
The common failure modes are straightforward:
automation@company.com, access reviews and incident investigations lose the actual actor, requester, policy, and reason.This is not theoretical. We have already seen the pattern in the wild: when agent tooling meets broad credentials, the blast radius is determined less by the login event and more by what the agent is allowed to do afterward. I wrote about this dynamic in the context of the Muse incident here: The Muse 0-day isn't about Muse, it's about agents and credentials. The point is not to dunk on any vendor. The point is that credentials built for humans become dangerous when autonomous tools inherit them without deterministic authorization at action time.
Most SOC 2 programs run a periodic user access review (often quarterly) under CC6. Agents usually never show up in it, because they are not "users" in the IdP. That is the gap. If an agent can act on production systems or customer data, its entitlements belong in the review.
Each cycle, certify:
Explicit policy makes this reviewable. Permissions buried in prompts or shared keys do not. For how the authorization model shapes what you can show a reviewer, see Authorization Models to Least-Privilege Evidence.
ISO/IEC 27001:2022 Annex A still expects defined access control, managed access rights, and restricted privileged access. For AI agents, that means agent identities, entitlement reviews, and privileged tool lists must be explicit. The control-by-control table below maps A.5.15, A.5.18, and A.8.2 to agent and MCP evidence. Soft framing only: an authorization layer supports evidence for these controls. It does not by itself certify you.
A.8.15 is about logging security events so you can investigate. For agents, IdP login events are not enough. You need authorization decisions at the tool call: who or what acted, for whom, on which resource, under which policy version, allow or deny, and the outcome. Tie those records to your SIEM the way you would other audit logs.
The practical move is to remap the control evidence from "who logged in?" to "who or what was allowed to do what, under which policy, at the moment the side effect happened?"
| Control | What it originally assumed | How agents break it | Evidence to produce | How an authorization layer produces it |
|---|---|---|---|---|
| SOC 2 CC6, logical access | Human users have accounts, roles, groups, and application permissions. Access is granted, modified, reviewed, and revoked. | Agents act on behalf of users, services, or workflows. A token may be valid, but the specific tool call may exceed the intended authority. | Policy definitions, role and attribute mappings, agent identity, user delegation context, resource sensitivity, allow and deny decisions, access review exports. | Evaluates each sensitive action against RBAC, ABAC, or ReBAC policies. Records who delegated authority, what agent acted, which resource was targeted, and why the decision was allowed or denied. |
| SOC 2 CC7, system operations and monitoring | Logs show user sessions, admin actions, errors, and anomalies. Monitoring detects suspicious human or service activity. | Agent activity is high volume, chained, and context dependent. A single user intent can create many downstream actions. | Decision logs, tool-call logs, anomaly signals, failed authorization attempts, escalation events, approval records, incident investigation trail. | Emits structured authorization logs for each decision, including subject, action, resource, policy version, attributes, and outcome. Denies become monitored events, not just application errors. |
| ISO 27001 A.5.15, access control | Access rules are defined for users, systems, networks, and applications based on business requirements. | Agents blur the boundary between user access and system access. They may combine permissions across tools. | Access-control policy, enforcement architecture, tool inventory, agent permissions, mapping of business rules to tool actions. | Centralizes policy for agent and application actions, then enforces it consistently at the API, service, workflow, or MCP gateway layer. |
| ISO 27001 A.5.18, access rights | User access rights are provisioned, reviewed, changed, and removed through defined processes. | Agent authority may be implicit in prompts, OAuth scopes, API keys, or service accounts, and may not appear in normal access reviews. | Agent entitlement inventory, delegation records, periodic review reports, revocation evidence, exceptions, approval history. | Makes agent permissions explicit as policies and relationships. Produces reviewable evidence of which agents can act for which users, on which resources, and under what conditions. |
| ISO 27001 A.8.2, privileged access rights | Privileged accounts are identified, restricted, approved, monitored, and periodically reviewed. | Agents can effectively become privileged users if they inherit admin tokens, broad service accounts, or write access to critical systems. | Privileged tool list, privileged action policies, just-in-time approvals, human-in-the-loop records, separation-of-duties evidence. | Requires additional policy checks for privileged actions. Can route high-risk agent actions through approval flows before execution. |
| ISO 27001 A.8.15, logging | Logs capture relevant security events, user activity, exceptions, and administrative actions for investigation. | Logs may show that an API was called, but not why the agent was authorized, what policy applied, or which human delegation caused it. | Immutable or retained audit logs, decision history, policy version history, correlation IDs across tools, evidence of denied attempts. | Produces decision-level audit logs that can be correlated with application, IdP, SIEM, and MCP logs. Supports investigation of "why was this allowed?" and "why was this denied?" |
The language here is important. An authorization layer does not magically "make you SOC 2 compliant" or "make you ISO 27001 compliant." It supports evidence for the controls by making the access decision explicit, deterministic, reviewable, and logged.
For deeper background on why the deny path matters for auditors, see Explainable Deny. For investigation workflows, see Why Was This Allowed?. For least privilege evidence, see Authorization Models to Least-Privilege Evidence.
Agents are non-human identities, and non-human identity management is where many access programs are weakest. If every agent action appears as automation@company.com or a single shared API key, access reviews and incident investigations lose the actual actor, requester, policy, and reason. Auditors flag that attribution gap under CC6-style logical access and under privileged-access conversations. Give agents distinct identities, bind them to the human principal when they act on someone's behalf, and log both.
The enforcement point has to move closer to the side effect.
Login is too early. Consent is too broad. A static OAuth scope is often too coarse. The meaningful compliance question is asked later:
Can this agent, acting for this user or service, in this workflow, call this tool, with these parameters, against this resource, given the current policy and risk context?
That decision needs to happen at the point delegated authority becomes a side effect. In an MCP architecture, that means the MCP tool call or gateway. In a SaaS application, it may be the API endpoint. In an internal workflow, it may be the job runner, approval step, or service boundary. In a data system, it may be the read, export, transform, or write action.
The architecture usually has five pieces.
First, define policy as code or policy as configuration that engineers and GRC teams can reason about. RBAC is still useful for coarse permissions. ABAC handles context such as environment, data classification, ownership, region, device posture, or risk. ReBAC handles relationships such as owner, manager, team member, account admin, case assignee, or delegated agent.
Second, put a Policy Decision Point close enough to the action to make a deterministic decision. The PDP should receive the subject, action, resource, and context. For agent systems, the subject should not be only "the service account." It should include the agent identity, the delegating user where applicable, the tool, the workflow, and the target resource.
Third, keep decision logs. The authorization decision is compliance evidence. It should include the evaluated policy, policy version, attributes used, outcome, timestamp, and correlation IDs. Without this, an auditor or incident responder is left reconstructing intent from IdP logs and application logs after the fact.
Fourth, add approval flows where the policy requires human judgment. Not every action should be blocked, and not every action should be automatic. High-risk actions, such as exporting sensitive records, changing production configuration, deleting data, or using privileged tools, may require human-in-the-loop approval. The approval itself should become part of the evidence trail.
Fifth, distribute policy and authorization data in real time. Agent behavior is fast, and stale authorization data is a real risk. If a user loses access, changes teams, or a resource becomes sensitive, the agent authorization layer needs to know quickly. This is where a hybrid PDP model matters: local enforcement for latency and availability, with real-time policy and data updates distributed to the places decisions are made.
At Permit.io, this is the pattern we focus on: a hybrid PDP architecture, OPAL-based policy and data distribution, decision logs, and enforcement points that can sit inside applications, services, workflows, and agent gateways. For the broader program view, see Permit's AI compliance hub and Permit.io for compliance teams. Also related: MCP gateway for SOC 2 and HIPAA. For implementation details, see the docs for audit logs and the Permit MCP Gateway. For agent-side enforcement, Nexus PDP is the concrete direction: authorization decisions at the gateway and tool-call layer, backed by the same policy model and evidence trail.
The goal is simple: do not let an agent convert broad delegated authority into unreviewable side effects. Make every sensitive action explainable before it happens and auditable after it happens.
CC6 is about logical access controls in the AICPA Trust Services Criteria. Points of focus such as CC6.1 are outcome-based: restrict logical access to authorized users and systems. When agents act, "authorized" has to include agent identity, delegation, and the specific action, not only a human login.
You usually cannot, and that is the problem. Shared keys collapse attribution. Use distinct agent identities, bind the human principal, authorize each tool call, and retain decision logs that name the agent, user, tool, resource, and policy version.
They help, but they are usually not enough. IdP logs can show authentication, token issuance, group membership, and sometimes consent. They usually do not show the full authorization decision for each downstream agent action, including policy version, resource context, and why the action was allowed or denied.
Define how agents are identified, how entitlements are granted and reviewed, which tools are privileged, when human approval is required, and what must be logged (see A.8.15). Map those rules to enforcement at the tool-call boundary, then produce reviewable evidence.
If they can access in-scope systems or data, yes, in practice. The TSC do not name AI agents, but CC6 evidence is about who and what can access systems. Review each agent's owner, entitlements, delegations, and privileged tools on the same cadence as other privileged access.
No. OAuth is still useful for delegated authentication and token-based access. But OAuth alone does not decide whether a specific agent tool call should be allowed in a specific business context. You still need deterministic authorization at the action point.
No. Even if your system is not classified as high-risk AI, SOC 2 and ISO 27001 evidence still has to explain logical access, privileged access, monitoring, and logging. For Article 12 logging specifically, see EU AI Act Article 12 and ISO 42001 Logging for AI Agents.
Co-Founder / CEO at Permit.io
