Mapping AI Agent Controls to Compliance Requirements

Why Agent Behavior Needs Explicit Control Mapping

SOC 2 and ISO/IEC 42001 were not written with autonomous AI agents in mind. SOC 2 is based on the AICPA Trust Services Criteria, covering categories such as Security, Availability, Processing Integrity, Confidentiality, and Privacy. ISO/IEC 42001 specifies requirements for an AI Management System (AIMS) covering governance, risk management, and controls across the AI system lifecycle. Both are general-purpose control frameworks that agent behavior must be mapped into, rather than standards written specifically for agentic AI.

This creates a practical problem for compliance teams. An auditor examining SOC 2 Security criteria will ask how logical access is restricted and how users and system entities are authenticated before access is granted. An assessor reviewing ISO 42001 will ask how AI system operation is documented and traceable across its lifecycle. Neither question was designed around agents that act autonomously, hold their own permissions, and generate logs of their own decisions. The compliance work is to show, with technical evidence, that existing control intent is met even though the underlying system is an AI agent rather than a human user or a static application.

The Four Core Agent Controls

Four categories of technical controls cover the majority of what auditors and assessors ask for when evaluating agentic systems. Each maps to specific criteria across SOC 2 and ISO/IEC 42001.

SOC 2: Access, Authentication, and Change Management Criteria

The most directly applicable SOC 2 requirements sit within the Security (Common) Criteria. These require that entities restrict logical and physical access through authorization, and identify and authenticate users and system entities before granting access. For an AI agent, the relevant evidence is a distinct machine identity, a record of how that identity was authenticated, and documentation showing what access was authorized and by whom.

SOC 2 also requires monitoring of system components to detect anomalies indicative of malicious acts, errors, or disruption. Audit logs of agent actions serve this function directly, provided they capture enough detail to reconstruct what the agent did, when, and under what permission scope.

Change management criteria are also relevant: any modification to an agent's permissions or configuration should be authorized, tested, approved, and implemented in a documented way, matching the same expectations applied to infrastructure or software changes.

Evidence typically requested under SOC 2

• Machine identity records showing how each agent is uniquely identified and authenticated
• Access authorization documentation showing who approved the agent's permission scope
• Audit logs capturing agent actions, timestamps, and the resources accessed
• Change records for any modification to agent permissions or configuration
• Monitoring alerts or anomaly detection outputs tied to agent behavior

ISO/IEC 42001: AI Management System Controls

ISO/IEC 42001 sets requirements for an AI Management System covering governance, risk management, and controls across the AI lifecycle. Its Annex A includes controls addressing AI system impact assessment, data management, and oversight of AI system use by third parties or suppliers. Agent-specific evidence maps into these areas where the agent's role, data access, and decision-making are treated as part of the AI system being managed.

Where agents depend on external models, tools, or APIs, the third-party and supplier controls in Annex A become directly relevant. Organizations pursuing ISO 42001 certification should be able to show that agent-based systems were included in the required AI system impact assessment, and that oversight of any external components the agent relies on is documented rather than assumed.

Evidence typically requested under ISO 42001

• AI system impact assessment documentation that includes agent-based systems
• Records of data access patterns and data handling for agent operations
• Supplier or third-party oversight documentation for external models, tools, or APIs the agent relies on
• Lifecycle documentation covering how agents are deployed, updated, and retired
• Governance records showing accountability for agent behavior at an organizational level

Documenting Agent Permission Changes for Audit

Permission changes are one of the most frequently scrutinized areas during both SOC 2 audits and ISO 42001 assessments. When an agent's access scope is expanded, restricted, or transferred to a different role, that change should be captured with the same rigor applied to any other access-control modification.

Practically, this means maintaining a record of the original permission state, the requested change, who authorized it, when it took effect, and whether any testing or review was completed before deployment. These records do not need to be held in a specialized system; what matters is that they are complete, retrievable, and tied to specific agent identities rather than generic service accounts.

NIST AI Risk Management Framework Alignment

The NIST AI RMF is organized around four core functions: Govern, Map, Measure, and Manage. Unlike SOC 2 and ISO 42001, it does not produce a certification. Instead, it provides a vocabulary and structure for identifying, evaluating, and responding to AI-related risks. For compliance teams operating alongside engineering and risk functions, it can serve as a useful bridge between technical control implementation and organizational risk posture documentation.

Agent controls map most directly to the Govern and Manage functions. The Govern function calls for defined policies, accountability structures, and workforce awareness. The Manage function covers response and recovery actions for identified AI risks. Audit logs of agent behavior, combined with defined escalation paths for anomalous actions, satisfy much of what NIST AI RMF asks for in these areas.

Frequently Asked Questions