White Paper | 2026-03-27 | Status: draft
AICM Agentic Control Supplement: Domain-by-Domain Gap Analysis
Executive Summary
The Cloud Security Alliance published the AI Controls Matrix (AICM) v1.0 on July 10, 2025, as a landmark framework containing 243 control objectives distributed across 18 security and governance domains [1]. Built on the architecture of CSA’s well-established Cloud Controls Matrix (CCM), AICM v1.0 maps to leading standards including ISO 42001, ISO 27001, NIST AI RMF 1.0, and the EU AI Act, providing organizations with a unified reference for governing AI systems throughout their lifecycle [2]. The framework was designed as a superset of CCM, inheriting foundational controls for cloud infrastructure while layering AI-specific requirements for model security, data governance, and AI-augmented risk management.
The rapid enterprise adoption of agentic AI systems — autonomous software agents capable of reasoning over multi-step plans, invoking external tools and APIs, spawning sub-agents, and executing consequential actions without direct human approval at each step — has exposed a structural gap in AICM v1.0. The framework was developed at a time when the dominant AI deployment pattern was interactive: a human submits a prompt, a model responds, and a human evaluates the output before any action occurs. Agentic systems invert this model. They receive a high-level goal, decompose it into subtasks, acquire credentials and context, call tools and services, produce side effects in connected systems, and report results only after the work is done. The security implications of this autonomy — unbounded action surfaces, emergent behavior, dynamic trust chains between cooperating agents, and the difficulty of attributing responsibility for automated decisions — are not adequately addressed by the control objectives in AICM v1.0.
This paper presents a systematic gap analysis across all 18 AICM domains, evaluating each control area against the specific threat and governance requirements of agentic deployments. Using a three-tier classification (Fully Applicable, Applicable with Modification, Missing), the analysis identifies 24 control gaps that cannot be addressed through simple interpretation of existing controls. The paper then proposes 24 new control objectives organized into six agentic-specific focus areas, each mapped to the MAESTRO threat modeling framework [3], the OWASP Top 10 for Agentic Applications [4], and MITRE ATLAS adversarial techniques [5]. Companion AI-CAIQ questions and a cross-framework alignment table mapping proposed controls to EU AI Act articles, ISO 42001 clauses, and NIST AI RMF functions are provided to support immediate organizational adoption.
Organizations implementing agentic AI should treat AICM v1.0 as the essential foundation and adopt the proposed supplement controls as a prioritized roadmap, beginning with agent identity lifecycle management and runtime behavioral governance — the two areas where the gap between existing controls and agentic risk is widest.
1. Introduction: AICM v1.0 and the Agentic Gap
The CSA AI Controls Matrix v1.0 represents the culmination of more than two years of collaborative work across the Cloud Security Alliance’s AI Safety Working Groups, drawing on expertise from security practitioners, AI researchers, legal and compliance professionals, and technology vendors [1]. It arrived at a critical moment: enterprises were moving from AI experimentation to production deployment at scale, and organizations lacked a unified, controls-based framework for governing AI systems with the same rigor applied to cloud infrastructure. AICM v1.0 filled that gap, providing concrete, auditable control objectives rather than the high-level principles that had characterized earlier AI governance guidance.
The 18 domains in AICM v1.0 span both traditional security disciplines — identity management, logging, infrastructure security, incident response — and AI-specific areas such as Model Security, which addresses threats like prompt injection, model poisoning, and data leakage. Each of the 243 controls is mapped to lifecycle phases, architectural layers, threat categories, and regulatory frameworks, giving organizations a practical implementation roadmap. The companion AI Consensus Assessments Initiative Questionnaire (AI-CAIQ) extends the framework into a self-assessment instrument suitable for STAR Level 1 submissions and vendor due diligence programs [6].
AICM v1.0 was architected for what might be called first-generation enterprise AI: inference-only deployments where models function as intelligent assistants responding to human-initiated queries. The control surface of these systems is relatively bounded. The model’s outputs are advisory; a human decides whether and how to act on them. Security controls can therefore focus primarily on protecting the model itself (Model Security), governing the data used to train and query it (Data Security and Privacy Lifecycle Management), and ensuring that access to AI capabilities is properly controlled (Identity and Access Management). The assumption that a human remains in the loop between model output and real-world action is embedded in many of AICM v1.0’s existing controls.
Agentic AI systems operate under a fundamentally different architecture. In an agentic deployment, a foundation model functions as a planning and reasoning engine embedded within an orchestration framework that grants it access to tools — web search, code execution environments, database queries, API calls, email and calendar systems, even other AI agents. The agent receives a high-level objective, formulates a plan to achieve it, executes that plan by invoking its tools in sequence, evaluates intermediate results, and adapts its approach when results diverge from expectations. The human who initiated the task may not review individual actions until the agent reports completion, which may occur minutes, hours, or days later across hundreds of individual tool invocations.
This architecture creates a new threat surface that extends far beyond what AICM v1.0 was designed to govern. Agent identities must be managed at a scale and velocity that dwarfs traditional non-human identity management: a single enterprise agent workflow may spawn dozens of ephemeral sub-agents, each requiring its own scoped credentials, each interacting with external services, and each presenting a potential pivot point for lateral movement or data exfiltration. The trust relationships between cooperating agents in a multi-agent system require new protocols for attestation and message integrity. The tools available to agents represent a dynamic capability surface that can be extended at runtime, requiring governance controls that do not yet exist in AICM v1.0. And the behavioral properties of agents — goal alignment, plan coherence, action drift over long-running tasks — require monitoring and intervention mechanisms distinct from the log-based anomaly detection that existing Logging and Monitoring controls describe.
The OWASP GenAI Security Project’s December 2025 release of the Top 10 for Agentic Applications provides independent confirmation of this gap, identifying ten risk categories — from Agent Goal Hijack (ASI01) and Tool Misuse and Exploitation (ASI02) to Rogue Agents (ASI10) — that map only partially to existing AICM controls [4]. Similarly, the CSA’s own MAESTRO framework, published in February 2025, provides a seven-layer threat model for agentic AI systems that highlights control requirements at the Agent Frameworks and Agent Ecosystem layers (Layers 3 and 7) that are underserved by current AICM guidance [3]. The gap analysis presented in this paper synthesizes these external frameworks with a systematic review of AICM v1.0 to provide a prioritized, actionable supplement.
2. Gap Analysis Methodology
The gap analysis presented in this paper follows a structured four-phase process designed to ensure that every classification decision is traceable to specific AICM control language and specific agentic threat scenarios.
The first phase involved establishing an agentic reference architecture against which AICM controls could be evaluated. Drawing on the MAESTRO seven-layer framework [3], the OWASP Top 10 for Agentic Applications [4], and CSA’s published research on agentic AI identity management [7], the analysis team developed a canonical agentic deployment model comprising four architectural patterns: single-agent deployments with tool access, orchestrator-worker multi-agent hierarchies, peer-to-peer agent networks, and human-in-the-loop hybrid workflows. For each pattern, a comprehensive list of security-relevant behaviors was enumerated, including agent initialization and credential provisioning, tool invocation and result processing, inter-agent delegation and trust chain establishment, goal monitoring and drift detection, human escalation triggers, and agent decommissioning and audit trail finalization.
The second phase mapped each of the 243 AICM v1.0 control objectives to the agentic security behaviors identified in phase one. Each control received a classification according to a three-tier scheme. A rating of Fully Applicable indicates that the control objective, as written, addresses the agentic behavior without requiring substantive reinterpretation. A rating of Applicable with Modification indicates that the control’s intent is relevant but that its current language, scope, or implementation guidance contains assumptions that limit its applicability to agentic systems — typically, assumptions about human involvement in authentication, decision-making, or audit review. A rating of Missing indicates that no existing AICM control adequately addresses the agentic security requirement, and that a new control objective is needed.
The third phase synthesized the classification results at the domain level, identifying the domains with the highest density of Missing or Applicable with Modification controls. This domain-level view drives the prioritization recommendations in the Implementation Roadmap (Section 7). Domains with predominantly Fully Applicable controls still require attention in implementation guidance, since even controls that are applicable in principle may require agent-specific procedures for effective deployment.
The fourth phase developed proposed new control objectives for each identified gap, following AICM v1.0’s control structure: a unique identifier, a control objective statement, implementation guidance, and framework mappings. Where multiple gaps within a single domain pointed to a common underlying requirement, they were consolidated into a single control to maintain the parsimony that characterizes AICM v1.0’s design.
Throughout this process, the analysis team applied a conservative stance on “Fully Applicable” classifications. A control was rated Fully Applicable only when its implementation guidance, as written, would produce the intended security outcome in an agentic deployment without supplementary procedures. Controls that provide useful partial coverage but leave meaningful gaps were rated Applicable with Modification, even when the gap requires only modest additions to existing guidance.
3. Domain-by-Domain Analysis
3.1 Audit and Assurance (AA)
The Audit and Assurance domain establishes requirements for planning, executing, and reporting on audits of AI systems, including the policies, procedures, and documentation that support ongoing assurance of compliance with internal and external requirements. AICM v1.0’s AA controls address audit scope definition, audit trail integrity, third-party audit engagement, and management response processes — all of which carry forward well from CCM and reflect mature practice in cloud security auditing. The foundational audit discipline these controls establish is as necessary for agentic systems as for any AI deployment, and the requirements for audit independence, evidence retention, and periodic review are fully applicable regardless of deployment architecture.
The agentic gap in the AA domain is primarily one of scope and attribution. Traditional audit procedures assume a relatively stable system boundary: you audit the model, the infrastructure supporting it, the access controls governing it, and the data it processes. In an agentic deployment, the effective system boundary at any given moment is defined by the tools the agent can access, the sub-agents it can spawn, and the external services it can call — a boundary that may expand or contract dynamically as workflows progress. Existing AA controls do not require audit scope definitions to account for dynamic capability surfaces, nor do they address the attribution challenge of tracing a consequential action back through an orchestration chain that may span multiple agents, multiple service calls, and multiple delegated credential sets.
Furthermore, AICM v1.0’s AA controls contemplate audits of AI systems as discrete objects. Agentic systems challenge this object-centric view because the “system” being audited may be best understood as a workflow or session rather than a persistent artifact: an agent spun up to complete a specific task, equipped with specific tools, and decommissioned when the task completes. Audit procedures must be capable of capturing session-level artifacts — the complete action log, tool invocation records, intermediate reasoning traces, and credential usage records — as a unified audit package that can be reconstructed and reviewed after the agent has terminated.
| Control Area | Classification |
|---|---|
| Audit policy and planning | Fully Applicable |
| Third-party audit requirements | Fully Applicable |
| Audit trail integrity | Applicable with Modification |
| System boundary documentation for audit | Applicable with Modification |
| Attribution and chain-of-custody for automated actions | Missing |
| Session-level audit package requirements for ephemeral agents | Missing |
The key modification required for audit trail integrity controls is an explicit requirement that agent session identifiers be included in all log entries produced during an agent’s execution, enabling reconstruction of the complete action sequence for a given session. The missing controls in session-level audit packaging and attribution chain documentation are addressed in Section 4 through proposed control IAM-AG-03.
3.2 Application and Interface Security (AIS)
The Application and Interface Security domain governs the security of AI-integrated applications and the interfaces — APIs, user interfaces, and data feeds — through which AI systems receive inputs and deliver outputs. AICM v1.0’s AIS controls address input validation, output sanitization, API security, secure development lifecycle requirements, and interface hardening against known attack vectors including prompt injection [1]. The prompt injection controls in AIS are among the most AI-specific contributions of AICM v1.0 relative to CCM, and they provide a meaningful baseline for protecting agent input channels from adversarial manipulation.
The agentic context significantly expands the AIS domain’s threat surface. In a non-agentic AI deployment, interfaces are relatively well-defined: a user interface or API accepts inputs, the model processes them, and outputs are returned through the same interface. An agentic system may have dozens of active interfaces simultaneously — the initial task interface, each tool’s API or execution interface, the interfaces of any spawned sub-agents, and any external services the agent calls to gather context. Each of these interfaces represents a potential injection point for adversarial content that could manipulate the agent’s goals or behavior (OWASP ASI01: Agent Goal Hijack) [4].
AICM v1.0’s AIS controls require input validation but were designed with the assumption that the application developer controls and can enumerate all input channels. The tool-calling pattern of agentic systems means that an agent may process content retrieved from the web, from email systems, from databases, or from other agents — content that was not authored or controlled by the application developer and that may contain adversarial instructions embedded in seemingly benign data. This indirect prompt injection attack pattern requires AIS controls to be extended to cover runtime content validation across all agent-accessible data sources, not merely the formal input interfaces of the application.
| Control Area | Classification |
|---|---|
| API security and authentication | Fully Applicable |
| Secure development lifecycle for AI applications | Fully Applicable |
| Direct prompt injection prevention | Fully Applicable |
| Input validation for defined interfaces | Applicable with Modification |
| Indirect prompt injection via tool-retrieved content | Missing |
| Agent output validation before tool invocation | Missing |
3.3 Business Continuity Management (BCM)
The Business Continuity Management domain establishes requirements for maintaining operational resilience when AI systems experience failures, degraded performance, or security incidents. AICM v1.0’s BCM controls address recovery time and recovery point objectives for AI systems, backup and restoration procedures for model artifacts and training data, and the continuity of AI-supported business processes during system unavailability. These controls are broadly applicable to agentic deployments without significant modification, as the fundamental BCM discipline — planning for failure, testing recovery procedures, and documenting fallback processes — applies regardless of deployment architecture.
The primary agentic modification required in the BCM domain concerns cascading failure management. Agentic systems are characterized by deep interdependencies: an orchestrating agent depends on sub-agents, which depend on tools, which depend on external services. A failure anywhere in this chain can propagate in unexpected ways, particularly when agents are designed to retry operations or escalate to alternative strategies when initial approaches fail. AICM v1.0’s BCM controls address the continuity of individual AI systems but do not specifically require organizations to model and test for cascading failure scenarios in multi-agent architectures — the exact scenario highlighted as ASI08 (Cascading Failures) in the OWASP Top 10 for Agentic Applications [4].
The BCM domain also requires modification to address the recovery of long-running agent sessions. Traditional system recovery is a relatively atomic operation: restore the system from backup, replay recent transactions, and resume operation. An agent engaged in a multi-hour research or analysis task may have accumulated significant intermediate state — tool results, intermediate reasoning artifacts, partially completed subtasks — that cannot be recovered from a model checkpoint alone. BCM controls should require organizations to define state preservation requirements for agentic workflows and to test the resumability of long-running agent sessions following component failures.
| Control Area | Classification |
|---|---|
| Recovery time and point objectives for AI systems | Fully Applicable |
| Backup and restoration for model artifacts | Fully Applicable |
| Continuity planning for AI-dependent processes | Fully Applicable |
| Cascading failure modeling for multi-agent systems | Applicable with Modification |
| Session state preservation and resumability for long-running agents | Missing |
3.4 Change Control and Configuration Management (CCC)
The Change Control and Configuration Management domain governs the processes by which AI systems and their configurations are modified, tested, approved, and deployed. AICM v1.0’s CCC controls require formal change management procedures for model updates, configuration changes, and infrastructure modifications supporting AI systems. These controls are directly applicable to agentic deployments for all aspects of the static agent configuration: the orchestration framework, the foundation model version, the tool integration configuration, and the system prompts or persona definitions that govern agent behavior.
The agentic gap in CCC is primarily dynamic. Agent systems introduce runtime configuration changes that have no equivalent in non-agentic AI: an agent may acquire new tools mid-session as the orchestration framework determines they are needed, modify its own system prompt or behavioral guidelines based on task context, or be granted elevated permissions by a human operator in response to an agent-generated escalation request. These runtime changes are consequential — they alter the agent’s capability surface and behavioral boundaries — but they occur outside the formal change control processes that CCC controls are designed to govern. Without explicit controls requiring change management disciplines to extend to runtime tool and capability grants, organizations will maintain rigorous change control for static agent configuration while allowing significant behavioral changes to occur without review or approval.
| Control Area | Classification |
|---|---|
| Change management for model updates | Fully Applicable |
| Configuration versioning and rollback | Fully Applicable |
| Testing and approval gates for AI system changes | Fully Applicable |
| Runtime tool acquisition and capability grants | Missing |
| Dynamic system prompt modification governance | Missing |
3.5 Cryptography, Encryption, and Key Management (CEK)
The Cryptography, Encryption, and Key Management domain establishes requirements for the protection of AI system data at rest and in transit, the management of cryptographic keys used by AI systems, and the application of encryption to sensitive model artifacts including training data, model weights, and inference logs. AICM v1.0’s CEK controls are drawn largely from established cryptographic practice and apply fully to agentic systems for the protection of the static infrastructure supporting agent deployment.
The agentic modification required in CEK concerns the management of the short-lived credentials used by agents during task execution. Agent systems frequently rely on API keys, OAuth tokens, and managed identity credentials to authenticate to external tools and services. In high-throughput agentic deployments, these credentials may be issued and rotated at rates that far exceed what traditional key management infrastructure is designed to handle — a single orchestration platform may manage thousands of concurrent agent sessions, each with its own credential set. AICM v1.0’s key management controls establish strong requirements for rotation, storage, and access logging, but their operational guidance was developed for a scale and lifecycle pattern (long-lived service credentials, periodic manual rotation) that does not match the ephemeral, high-velocity credential patterns of agentic systems.
| Control Area | Classification |
|---|---|
| Encryption of AI system data at rest and in transit | Fully Applicable |
| Key management for model artifacts | Fully Applicable |
| Certificate lifecycle management | Applicable with Modification |
| High-velocity ephemeral credential management for agent sessions | Missing |
| Cryptographic attestation of agent identity | Missing |
3.6 Datacenter Security (DCS)
The Datacenter Security domain governs physical and environmental security controls for the infrastructure supporting AI systems. AICM v1.0’s DCS controls address physical access controls, environmental monitoring, and the security of hardware supporting AI inference and training workloads, including GPU clusters and specialized AI accelerators. These controls are fully applicable to agentic deployments without modification. The physical security of the compute infrastructure supporting agent orchestration is not materially different from the physical security requirements for any other high-sensitivity AI workload.
| Control Area | Classification |
|---|---|
| Physical access controls for AI infrastructure | Fully Applicable |
| Environmental monitoring and controls | Fully Applicable |
| Hardware security for AI compute resources | Fully Applicable |
The DCS domain presents no significant agentic gaps, though organizations should ensure that DCS controls extend explicitly to the orchestration layer infrastructure — the servers and containers hosting agent frameworks — which may be physically distinct from the GPU infrastructure running foundation model inference.
3.7 Data Security and Privacy Lifecycle Management (DSP)
The Data Security and Privacy Lifecycle Management domain is one of the most consequential in AICM v1.0 for agentic deployments. Its controls govern the classification, handling, retention, and deletion of data throughout the AI system lifecycle, including training data, inference inputs, model outputs, and the operational data generated during AI system operation. AICM v1.0’s DSP controls address data minimization, purpose limitation, data subject rights, cross-border data transfer restrictions, and the special protections required for sensitive and personally identifiable information. These controls are directly relevant to agentic deployments and provide a strong baseline.
The agentic gap in DSP is substantial. Agentic systems accumulate and process data in fundamentally different patterns than non-agentic AI. An agent completing a multi-step research task may access and process hundreds of external data sources, synthesize their contents into intermediate artifacts that persist in memory or context, and produce outputs that contain derived insights from data the operator never explicitly provided to the AI system. The data processed by the agent during a session — the contents of web pages fetched, documents analyzed, emails read, database records queried — constitutes a de facto data processing activity that may have significant privacy implications, particularly when the agent operates on behalf of multiple users or organizations.
AICM v1.0’s DSP controls were designed for AI systems where the operator explicitly curates the data processed by the model. Agentic systems challenge this curation assumption: the agent’s tool calls, not the operator, determine what data is processed. Without controls specifically requiring that agent data access be scoped, that intermediate data artifacts be classified and handled according to the most sensitive data element they contain, and that data retrieved during agent sessions be subject to the same retention and deletion requirements as explicitly provided data, organizations will face compliance gaps under the GDPR, the EU AI Act’s data governance requirements for high-risk AI systems, and other applicable data protection frameworks.
| Control Area | Classification |
|---|---|
| Data classification and handling | Applicable with Modification |
| Data minimization and purpose limitation | Applicable with Modification |
| Data subject rights management | Applicable with Modification |
| Cross-border data transfer controls | Applicable with Modification |
| Retention and deletion for training and inference data | Fully Applicable |
| Tool-accessed data scoping and classification | Missing |
| Intermediate artifact handling and retention for agent sessions | Missing |
| Data provenance tracking across multi-agent workflows | Missing |
3.8 Governance, Risk and Compliance (GRC)
The Governance, Risk and Compliance domain establishes the organizational structures, policies, and risk management processes that govern AI system deployment and operation. AICM v1.0’s GRC controls address AI governance frameworks, board and executive accountability for AI risk, regulatory mapping, and the integration of AI risk into enterprise risk management processes. These foundational governance controls apply fully to agentic deployments: every organization deploying agentic AI should have a governing policy framework, clear executive accountability, and a process for identifying and managing AI-specific risks.
The agentic modification required in GRC concerns risk assessment methodology. AICM v1.0’s GRC controls require AI risk assessments but were developed when the relevant risk model was primarily one of model bias, data quality, and inference accuracy. Agentic systems introduce a distinct category of operational risk — the risk of autonomous action — that requires risk assessment methodologies to account for the agent’s action surface, the potential magnitude of errors that propagate through autonomous multi-step workflows before human review, and the systemic risk created when multiple agentic systems interact in ways that were not anticipated during individual system risk assessments. The EU AI Act’s Article 9 requirements for risk management systems provide a useful regulatory anchor, requiring continuous risk management throughout the AI lifecycle and explicit consideration of the risks posed by interactions between AI systems [8].
| Control Area | Classification |
|---|---|
| AI governance policy framework | Fully Applicable |
| Executive accountability for AI risk | Fully Applicable |
| Regulatory compliance mapping | Fully Applicable |
| AI risk assessment methodology | Applicable with Modification |
| Agentic action risk modeling and quantification | Missing |
| Systemic risk assessment for multi-agent interactions | Missing |
3.9 Human Resources (HRS)
The Human Resources domain governs the people-related controls for AI system development, deployment, and operation, including security awareness training for personnel who interact with AI systems, background verification requirements for individuals in sensitive AI roles, and procedures for managing personnel transitions that affect AI system access. AICM v1.0’s HRS controls apply fully to agentic deployments for all human personnel involved in agent development, deployment, and oversight.
The agentic modification required in HRS concerns the training content for personnel who supervise or interact with agentic systems. AICM v1.0’s awareness training requirements focus on data handling, acceptable use, and recognizing AI-specific threats like prompt injection. Personnel supervising agentic systems require additional competencies: understanding the behavioral properties of agents and how to interpret agent action logs, recognizing signs of goal drift or behavioral anomaly, knowing when and how to interrupt a running agent, and understanding the escalation procedures for agentic incidents. The EU AI Act’s Article 14 specifically requires that high-risk AI systems be designed so that natural persons can effectively oversee them and that persons assigned oversight responsibilities have the knowledge and competence to exercise that oversight [9].
| Control Area | Classification |
|---|---|
| Security awareness training for AI system personnel | Applicable with Modification |
| Background verification for sensitive AI roles | Fully Applicable |
| Personnel transition procedures for AI system access | Fully Applicable |
| Competency requirements for agentic system supervisors | Missing |
3.10 Identity and Access Management (IAM)
The Identity and Access Management domain is where the gap between AICM v1.0 and agentic security requirements is most pronounced. AICM v1.0’s IAM controls address authentication, authorization, privileged access management, and identity lifecycle management for human users and service accounts interacting with AI systems. These controls were developed primarily for the pattern of human users accessing AI services and AI systems accessing backend infrastructure through static service credentials.
Agentic AI systems introduce a qualitatively different identity problem. Non-human identities now outnumber human users by ratios exceeding 82 to 1 in many enterprise environments [10], and AI agents represent a rapidly growing subset of non-human identities with capabilities far exceeding those of traditional service accounts. An AI agent is not merely a service account that makes API calls on a predefined schedule; it is a dynamic actor capable of requesting new access, delegating permissions to sub-agents, and making authorization decisions in real time as part of its planning process. The credential lifecycle for agents — creation at session start, scoped provisioning based on the current task, rotation or revocation mid-session if scope changes, and full decommissioning at session end — does not map to the static provisioning and periodic review cycle that AICM v1.0’s IAM controls contemplate.
The delegation chain that emerges in multi-agent architectures creates a particularly challenging IAM problem. When an orchestrating agent spawns a sub-agent and delegates a portion of its task, it must also delegate appropriate credentials — but it should not delegate more authority than it holds (the principle of non-escalation), and it should not delegate authority that was granted specifically to it as an individual agent rather than to the role it fills. AICM v1.0’s privileged access management controls establish the principle of least privilege but do not address the specific mechanisms required to enforce non-escalation in agent delegation chains. This gap directly enables the OWASP ASI03 risk category (Identity and Privilege Abuse) [4].
| Control Area | Classification |
|---|---|
| Authentication for human users of AI systems | Fully Applicable |
| Privileged access management for AI system administrators | Fully Applicable |
| Service account management for AI system integrations | Applicable with Modification |
| Agent identity registration and unique identification | Missing |
| Ephemeral credential management for agent sessions | Missing |
| Delegation chain management and non-escalation | Missing |
| Agent identity decommissioning and credential revocation | Missing |
| Scoped permission provisioning based on task context | Missing |
3.11 Interoperability and Portability (IPY)
The Interoperability and Portability domain governs the standards, interfaces, and data formats used to ensure that AI systems can interoperate with other systems and that organizations can migrate AI workloads without excessive vendor lock-in. AICM v1.0’s IPY controls address API standardization, data format documentation, and migration planning for AI systems. These controls apply to agentic deployments for the foundational infrastructure but require significant extension for the agent-specific interoperability patterns.
Multi-agent systems require interoperability at a level AICM v1.0 does not address: the ability of agents built on different orchestration frameworks, by different vendors, or trained on different foundation models to communicate securely and reliably. Emerging protocols such as Google’s Agent-to-Agent (A2A) protocol and Anthropic’s Model Context Protocol (MCP) are beginning to standardize these interactions, but AICM v1.0 contains no controls requiring organizations to adopt interoperability standards for inter-agent communication, to document their inter-agent protocol implementations, or to assess the security implications of cross-vendor agent interactions. This creates a governance gap that will grow more significant as multi-agent deployments become more common.
| Control Area | Classification |
|---|---|
| API standardization and documentation | Fully Applicable |
| Data portability requirements for AI workloads | Fully Applicable |
| Vendor lock-in risk assessment | Fully Applicable |
| Inter-agent communication protocol documentation | Missing |
| Security assessment for cross-vendor agent interactions | Missing |
3.12 Infrastructure Security (IVS)
The Infrastructure Security domain governs the security of the compute, network, and storage infrastructure supporting AI systems, including network segmentation, vulnerability management for AI infrastructure, and the hardening of AI workload environments. AICM v1.0’s IVS controls are broadly applicable to agentic deployments and provide strong coverage of the static infrastructure layer.
The primary agentic modification needed in IVS concerns the containment of agent execution environments. AICM v1.0’s infrastructure controls address workload isolation and network segmentation, but they do not specifically require that agent tool execution environments be sandboxed to prevent agents from accessing resources beyond their defined scope, or that the compute environment provided to agents be isolated from the infrastructure used by human operators and other production systems. The OWASP ASI05 risk (Unexpected Code Execution) is enabled precisely by insufficient execution environment isolation [4]: an agent granted access to a code execution tool in an inadequately isolated environment may be able to access host system resources, sensitive configuration data, or network infrastructure beyond its intended scope. MAESTRO Layer 4 (Deployment and Infrastructure) specifically identifies execution environment isolation as a foundational security control for agentic systems [3].
| Control Area | Classification |
|---|---|
| Network segmentation for AI workloads | Applicable with Modification |
| Vulnerability management for AI infrastructure | Fully Applicable |
| Workload isolation and hardening | Applicable with Modification |
| Agent execution environment sandboxing | Missing |
| Runtime network egress controls for agent tool calls | Missing |
3.13 Logging and Monitoring (LOG)
The Logging and Monitoring domain establishes requirements for capturing, retaining, and analyzing operational data from AI systems to support security monitoring, incident investigation, and performance management. AICM v1.0’s LOG controls address log retention, log integrity, security event monitoring, and alert management. These controls provide a valuable foundation for agentic monitoring but require substantial modification to address the specific observability requirements of autonomous agent systems.
The fundamental challenge of agentic logging is that the most security-relevant events are not at the infrastructure layer but at the semantic layer: what decision did the agent make, and why? An agent’s tool call to an external API is captured at the network level by standard logging infrastructure, but that log entry — the HTTP request, the response code, the transfer size — contains far less security-relevant information than the agent’s own reasoning about why it made the call, what it expected to receive, and how it interpreted the result. The EU AI Act’s Article 12 requires that high-risk AI systems have automatic logging capabilities that record events enabling the identification of situations where the system presents a risk [8], but neither the EU AI Act nor AICM v1.0 specifies what constitutes an adequate log for an agentic system executing a complex multi-step plan.
Without specific logging controls requiring capture of agent reasoning traces, tool invocation context, intermediate planning artifacts, and behavioral metrics against defined baselines, organizations will have logging infrastructure that satisfies compliance checklists but provides inadequate forensic value when an agentic incident occurs. The MAESTRO framework’s Layer 5 (Evaluation and Observability) provides detailed guidance on the observability requirements for agentic systems, emphasizing the need for semantic monitoring that tracks agent behavior against intended objectives, not merely operational metrics [3].
| Control Area | Classification |
|---|---|
| Log retention and integrity | Fully Applicable |
| Security event monitoring and alerting | Applicable with Modification |
| Performance and availability monitoring | Applicable with Modification |
| Agent reasoning trace capture and retention | Missing |
| Tool invocation logging with semantic context | Missing |
| Behavioral baseline monitoring for agent goal drift | Missing |
| Session-level audit trail assembly | Missing |
3.14 Model Security (MS)
The Model Security domain is the most AI-specific domain in AICM v1.0, containing controls for protecting the foundational model and its associated artifacts from adversarial manipulation, unauthorized access, and misuse. MS controls address prompt injection prevention, model integrity verification, adversarial robustness testing, model access controls, and data poisoning prevention. For static inference deployments, this domain provides comprehensive coverage of the attack surface.
For agentic deployments, the Model Security domain’s controls must be extended in several important directions. First, the threat model for prompt injection changes significantly in an agentic context. In a non-agentic deployment, prompt injection attacks typically target a single inference call; an attacker who successfully injects an adversarial instruction may manipulate one model response, but the damage is limited by the absence of consequential tools. In an agentic deployment, a successful prompt injection can hijack the agent’s goal for the remainder of a multi-step workflow, causing it to exfiltrate data through tool calls, modify files, send communications, or take other consequential actions across dozens of subsequent steps. The OWASP ASI01 (Agent Goal Hijack) and ASI06 (Memory and Context Poisoning) risks both target this amplified prompt injection surface [4].
Second, the multi-model nature of many agentic systems — where a supervisor or orchestrating model delegates to specialized sub-models, each with their own system prompt and tool set — requires that Model Security controls address not just individual model integrity but the integrity of the inter-model communication channel. A message passing from an orchestrating model to a sub-agent passes through potentially untrusted infrastructure and can be manipulated in transit, causing the sub-agent to believe it has received instructions from a trusted orchestrator when in fact it has received adversarially modified instructions. MITRE ATLAS techniques for adversarial AI, expanded in October 2025 to include 14 new agent-focused techniques through collaboration with Zenity Labs, include specific techniques for inter-agent communication manipulation [5].
| Control Area | Classification |
|---|---|
| Prompt injection prevention (direct) | Fully Applicable |
| Model integrity verification | Fully Applicable |
| Adversarial robustness testing | Applicable with Modification |
| Model access controls and authentication | Fully Applicable |
| Data poisoning prevention | Fully Applicable |
| Indirect prompt injection through tool-retrieved content | Missing |
| Inter-model message integrity in multi-agent systems | Missing |
| Goal coherence monitoring across multi-step agent tasks | Missing |
| Adversarial testing for multi-agent attack paths | Missing |
3.15 Security Incident Management (SEF)
The Security Incident Management domain establishes requirements for detecting, responding to, and recovering from security incidents involving AI systems. AICM v1.0’s SEF controls address incident detection, escalation procedures, investigation processes, and post-incident review requirements. These foundational incident management controls apply to agentic deployments, but agentic systems introduce several incident response complications not addressed by existing controls.
The first complication is detection latency. Agentic systems may complete substantial portions of a multi-step workflow — including consequential tool invocations — before a behavioral anomaly is detectable through standard monitoring. By the time a security operations team receives an alert that an agent is behaving anomalously, the agent may have already exfiltrated data, sent communications, or modified records in ways that require remediation beyond simple session termination. SEF controls must be extended to require pre-emptive behavioral guardrails that can interrupt agent execution at the task level, not merely at the system level, and to establish maximum action thresholds that trigger automatic pause and human review before critical consequence thresholds are reached.
The second complication is attribution in multi-agent systems. When a security incident involves a chain of cooperating agents, attributing the initial compromise and tracing the lateral movement through the agent network requires forensic capabilities that go beyond the standard log analysis that SEF controls currently address. Organizations must maintain agent session records that enable reconstruction of the full delegation and action chain for any agent involved in an incident.
| Control Area | Classification |
|---|---|
| Incident detection and alerting | Applicable with Modification |
| Incident response procedures for AI systems | Applicable with Modification |
| Post-incident review and lessons learned | Fully Applicable |
| Agent session interruption and kill-switch capabilities | Missing |
| Multi-agent incident attribution and chain reconstruction | Missing |
| Pre-emptive action thresholds for autonomous agents | Missing |
3.16 Supply Chain Management (STA)
The Supply Chain Management domain governs the security of the components, services, and third parties that contribute to AI system development and operation, including training data provenance, pre-trained model vetting, third-party AI component security, and vendor risk management for AI services. AICM v1.0’s STA controls are extensive and well-developed, reflecting the significant attention the AI security community has devoted to supply chain risks following high-profile incidents involving compromised training data and model weights.
For agentic deployments, the supply chain threat surface expands dramatically. An agent’s tool ecosystem constitutes a runtime supply chain: every tool integration, every MCP server, every external API that the agent can call represents a dependency whose compromise could manipulate the agent’s behavior or enable data exfiltration. The OWASP ASI04 risk (Agentic Supply Chain Vulnerabilities) specifically addresses the risk that malicious tool definitions, compromised MCP servers, or adversarially configured tool APIs could manipulate agent behavior at runtime [4]. AICM v1.0’s STA controls address pre-deployment vetting of AI components but do not extend to the runtime tool ecosystem that defines an agent’s operational supply chain.
| Control Area | Classification |
|---|---|
| Training data provenance and vetting | Fully Applicable |
| Pre-trained model security assessment | Fully Applicable |
| Third-party AI component vetting | Applicable with Modification |
| Vendor risk management for AI services | Fully Applicable |
| Runtime tool ecosystem security assessment | Missing |
| MCP server and tool definition vetting | Missing |
| Tool behavior integrity monitoring | Missing |
3.17 Threat and Vulnerability Management (TVM)
The Threat and Vulnerability Management domain establishes requirements for identifying, assessing, and remediating threats and vulnerabilities affecting AI systems, including AI-specific threat intelligence, vulnerability scanning for AI infrastructure, and penetration testing requirements that address AI-specific attack vectors. AICM v1.0’s TVM controls provide good coverage of known AI threat categories and are generally applicable to agentic deployments.
The primary agentic modification required in TVM is the extension of penetration testing and red-team requirements to address multi-agent attack scenarios. Standard AI security testing focuses on attacks against individual models or inference endpoints. Agentic systems require adversarial testing that simulates attacks targeting the full agent workflow: prompt injection through tool-returned content, identity spoofing in inter-agent communications, privilege escalation through delegation chain manipulation, and cascading failures induced by selective compromise of individual agents within a multi-agent network. MITRE ATLAS’s October 2025 expansion to include 14 agent-focused attack techniques provides a reference taxonomy for structuring these tests [5].
| Control Area | Classification |
|---|---|
| AI threat intelligence integration | Fully Applicable |
| Vulnerability scanning for AI infrastructure | Fully Applicable |
| AI-specific penetration testing | Applicable with Modification |
| Multi-agent adversarial testing and red-teaming | Missing |
| Agentic-specific threat modeling requirements | Missing |
3.18 Universal Endpoint Management (UEM)
The Universal Endpoint Management domain governs the security of endpoint devices through which users interact with AI systems and through which AI systems interact with the broader computing environment. AICM v1.0’s UEM controls address device management, endpoint detection and response, and the security of client devices used to access AI services. These controls apply fully to the human-facing endpoints involved in agentic deployments.
The agentic modification required in UEM concerns the management of the compute environments in which agents execute as software endpoints in their own right. An agent framework running in a container or virtual machine is, functionally, a specialized endpoint that requires its own device management discipline: baseline configuration management, vulnerability patching, behavioral monitoring, and endpoint detection and response capabilities. AICM v1.0’s UEM controls do not explicitly address containerized agent execution environments as managed endpoints, though the underlying control intent is applicable with appropriate reinterpretation.
| Control Area | Classification |
|---|---|
| Device management for user endpoints | Fully Applicable |
| Endpoint detection and response | Applicable with Modification |
| Mobile device management for AI-enabled devices | Fully Applicable |
| Agent execution environment endpoint management | Applicable with Modification |
4. Proposed New Control Objectives
The gap analysis in Section 3 identifies 24 distinct control requirements not adequately addressed by AICM v1.0. These are organized into six thematic focus areas, each corresponding to a foundational security challenge unique to agentic AI deployment. For each proposed control, the following structure is provided: a proposed control identifier using the convention [DOMAIN]-AG-[NN], a control objective statement, implementation guidance, MAESTRO layer mapping, OWASP ASI risk category, and relevant MITRE ATLAS technique coverage.
4.1 Agent Identity and Lifecycle Management
Agent identity management represents the single highest-priority gap area. The ability to uniquely identify every agent, scope its permissions to the minimum required for its current task, manage its credentials with appropriate velocity and rotation, and fully decommission it when its task completes is the foundational prerequisite for all other agentic security controls. Without a reliable agent identity fabric, attribution, audit, and access control for agentic systems are impossible.
IAM-AG-01: Agent Identity Registration and Unique Identification
Control Objective: Every agent instance deployed in production must be assigned a unique, persistent identifier at the time of its instantiation. This identifier must be issued by an authoritative identity provider, recorded in a centralized agent registry, and associated with the agent’s assigned purpose, owning team, authorized tool set, and operational scope. Ephemeral agents created for single-session tasks must receive identifiers that uniquely link them to the session, the initiating human user, and the parent agent or orchestration context that created them.
Implementation Guidance: Organizations should deploy an agent identity registry as a distinct component of their identity infrastructure, separate from human user directories and traditional service account management systems. The registry should support the high-velocity registration and decommissioning patterns of short-lived agents without creating operational burden. Agent identifiers should be verifiable cryptographically so that inter-agent communications can include proof of identity rather than relying on network topology or shared secrets for authentication.
MAESTRO Layer: Layer 3 (Agent Frameworks), Layer 6 (Security and Compliance)
OWASP ASI: ASI03 (Identity and Privilege Abuse)
ATLAS Coverage: Exfiltration via AI Agent Tool Invocation
IAM-AG-02: Scoped Permission Provisioning and Least-Privilege Enforcement
Control Objective: Agent permissions must be provisioned dynamically based on the current task context and the minimum access required to complete that task, rather than granted statically at registration time. Permissions must be time-bounded, scoped to specific tool instances and data assets, and automatically revoked at task completion. Agents must not hold permissions to resources they are not actively using, and permission escalation requests must be logged, reviewed, and explicitly approved by a human operator before being granted.
Implementation Guidance: Implement a just-in-time permission provisioning system integrated with the agent orchestration framework that evaluates the current task plan, maps it to a minimum required permission set, issues scoped credentials for that set, and monitors actual usage against the issued scope. Deviations between requested and actually-used permissions should be flagged for review and used to tighten future permission grants.
MAESTRO Layer: Layer 3 (Agent Frameworks), Layer 6 (Security and Compliance)
OWASP ASI: ASI03 (Identity and Privilege Abuse)
ATLAS Coverage: Privilege Escalation via Agent Delegation
IAM-AG-03: Delegation Chain Management and Non-Escalation
Control Objective: When an agent delegates a subtask to a sub-agent, the delegated permissions must be a strict subset of the delegating agent’s current permission set. Mechanisms must be in place to verify that delegation chains do not result in the accumulation of permissions through composition that exceed what any single agent in the chain was explicitly granted. Complete delegation chains must be recorded in the agent audit log, linking every sub-agent’s actions to the originating human request and the authorization basis for each delegation step.
Implementation Guidance: Implement delegation chain verification as a mandatory gate in the agent orchestration framework, rejecting delegation requests that would cause the receiving agent to exceed the delegating agent’s current permission envelope. Use cryptographic delegation tokens that encode the full chain of authority, enabling any participant in the system to verify the legitimacy of a delegation.
MAESTRO Layer: Layer 3 (Agent Frameworks), Layer 7 (Agent Ecosystem)
OWASP ASI: ASI03 (Identity and Privilege Abuse)
ATLAS Coverage: Multi-Agent Orchestration Abuse
IAM-AG-04: Agent Decommissioning and Credential Revocation
Control Objective: When an agent completes its assigned task or is terminated for any reason, all credentials and permissions issued to that agent must be revoked within a defined maximum revocation window not to exceed five minutes. Decommissioning procedures must verify that no credentials issued to the terminated agent remain active in downstream systems, that all session artifacts have been captured in the audit log, and that the agent’s entry in the agent registry has been updated to reflect its terminated status.
Implementation Guidance: Build automated credential revocation into the agent lifecycle management platform, triggered by session completion, timeout, or operator-initiated termination. Conduct regular audits of credential revocation completeness by comparing agent registry terminated-status records against active credential inventories in IAM systems.
MAESTRO Layer: Layer 3 (Agent Frameworks), Layer 6 (Security and Compliance)
OWASP ASI: ASI03 (Identity and Privilege Abuse), ASI10 (Rogue Agents)
4.2 Runtime Behavioral Governance
Runtime behavioral governance addresses the challenge of ensuring that agents continue to pursue their assigned objectives, operate within their authorized behavioral boundaries, and escalate appropriately when they encounter situations outside their defined operational parameters. Unlike static security controls that can be verified at deployment time, behavioral governance requires continuous monitoring and intervention mechanisms.
LOG-AG-01: Agent Behavioral Baseline and Drift Detection
Control Objective: For each agent deployment, organizations must define a behavioral baseline specifying expected patterns of tool usage, resource consumption, data access, and plan structure. Continuous monitoring must detect deviations from this baseline and generate alerts when agent behavior diverges beyond defined thresholds. Behavioral baseline definitions must be maintained as versioned artifacts, updated when agent capabilities or authorized tasks change, and reviewed following any behavioral anomaly.
Implementation Guidance: Use orchestration-layer telemetry to capture behavioral metrics at the reasoning and planning level — not merely infrastructure metrics — including tool call frequency and sequencing, data access volume and sensitivity level, plan modification frequency, and reasoning loop detection (signs that the agent is cycling through similar plans without making progress). Establish threshold-based alerting and integrate with security information and event management (SIEM) platforms.
MAESTRO Layer: Layer 5 (Evaluation and Observability)
OWASP ASI: ASI01 (Agent Goal Hijack), ASI10 (Rogue Agents)
ATLAS Coverage: Model Behavioral Anomaly Detection
SEF-AG-01: Agent Kill-Switch and Emergency Interruption
Control Objective: Every deployed agent must have an accessible, reliable kill-switch mechanism that enables immediate termination of all agent activity, revocation of all agent credentials, and preservation of all session artifacts for forensic review. Kill-switch capabilities must be accessible to human operators without requiring technical access to the agent’s execution environment, must function when the agent is executing autonomously without human supervision, and must be tested at defined intervals as part of the organization’s security assurance program.
Implementation Guidance: Implement kill-switch functionality at the orchestration layer as a first-class capability, not an afterthought. Ensure that the kill-switch bypasses any retry or error-recovery logic in the agent framework, preventing a compromised or rogue agent from resisting termination. Document kill-switch procedures in incident response playbooks and conduct tabletop exercises that include kill-switch activation scenarios.
MAESTRO Layer: Layer 3 (Agent Frameworks), Layer 6 (Security and Compliance)
OWASP ASI: ASI10 (Rogue Agents)
GRC-AG-01: Agentic Action Risk Thresholds and Pre-Approval Gates
Control Objective: Organizations must define explicit risk thresholds for autonomous agent actions based on action type, affected resource sensitivity, and potential impact magnitude. Actions approaching or exceeding defined thresholds must trigger automatic pause and human review before execution. Risk threshold definitions must be documented, version-controlled, and reviewed at defined intervals or following any agentic incident that resulted in unintended consequences.
Implementation Guidance: Implement a risk classification scheme for tool actions that categorizes them by potential impact: read-only operations (lowest risk), reversible write operations, irreversible write operations, and communications to external parties (highest risk). Configure the orchestration framework to require explicit human approval for actions in high-risk categories, and to enforce time delays on medium-risk actions sufficient to allow human review if monitoring detects anomalous context.
MAESTRO Layer: Layer 3 (Agent Frameworks), Layer 6 (Security and Compliance)
OWASP ASI: ASI09 (Human-Agent Trust Exploitation)
4.3 Inter-Agent Communication Security
The security of communication between cooperating agents in a multi-agent system is a foundational requirement that receives no meaningful coverage in AICM v1.0. As multi-agent deployments scale, the inter-agent communication channel becomes a high-value target: an adversary who can inject or modify messages between agents gains influence over the entire multi-agent workflow without needing to compromise the underlying models.
AIS-AG-01: Inter-Agent Message Integrity and Authentication
Control Objective: All messages exchanged between agents in a multi-agent system must be cryptographically signed by the sending agent’s identity credential, enabling the receiving agent to verify the message’s authenticity and integrity before acting on it. Organizations must deploy key management infrastructure capable of issuing and verifying agent message signing credentials at the velocity required by multi-agent workflows and must prohibit agents from acting on unsigned or unverifiable messages from other agents.
Implementation Guidance: Adopt emerging inter-agent communication standards such as Google’s A2A protocol or appropriate extensions of Model Context Protocol (MCP) that include native message signing capabilities. Where standards do not yet provide adequate signing mechanisms, implement application-layer message authentication using HMAC or digital signatures backed by the agent identity registry’s cryptographic infrastructure.
MAESTRO Layer: Layer 3 (Agent Frameworks), Layer 7 (Agent Ecosystem)
OWASP ASI: ASI07 (Insecure Inter-Agent Communication)
ATLAS Coverage: Inter-Agent Message Injection
AIS-AG-02: Agent Impersonation Prevention
Control Objective: Multi-agent systems must implement controls to prevent malicious agents or compromised infrastructure from impersonating legitimate agents within the system. Authentication mechanisms for inter-agent communication must rely on verifiable cryptographic identity rather than network topology, IP addresses, or shared secrets that can be replicated by an attacker with network access.
Implementation Guidance: Implement mutual authentication for all inter-agent communication using certificates issued by the agent identity registry. Require agents to verify the certificate chain of any agent they communicate with before accepting instructions or sharing context. Log all authentication failures in inter-agent communication and treat repeated failures as a potential impersonation attack requiring security investigation.
MAESTRO Layer: Layer 3 (Agent Frameworks)
OWASP ASI: ASI07 (Insecure Inter-Agent Communication), ASI03 (Identity and Privilege Abuse)
4.4 Tool and Capability Governance
The tools available to an agent define its capability surface and, consequently, the potential impact of a compromise or behavioral failure. Tool governance — ensuring that agents have access only to the tools they need, that those tools are vetted and monitored, and that the capability surface does not expand without explicit authorization — is a critical control area unaddressed by AICM v1.0.
CCC-AG-01: Tool Registry and Capability Governance
Control Objective: Organizations must maintain a centralized tool registry documenting every tool and external capability made available to deployed agents, including the tool’s function, the data it accesses, the external services it calls, its security assessment status, and the agents authorized to use it. Changes to the tool registry — adding new tools, modifying existing tool configurations, or granting access to additional agents — must follow the organization’s change management process and require explicit security review before taking effect in production.
Implementation Guidance: Implement the tool registry as a controlled configuration artifact, version-controlled and subject to the same audit requirements as software deployments. Require security review of all new tool integrations, including MCP server configurations, before approval, assessing the tool’s data access scope, external connectivity, potential for misuse, and security of the tool’s own API or interface.
MAESTRO Layer: Layer 3 (Agent Frameworks), Layer 4 (Deployment and Infrastructure)
OWASP ASI: ASI02 (Tool Misuse and Exploitation), ASI04 (Agentic Supply Chain Vulnerabilities)
STA-AG-01: Runtime Tool Ecosystem Security Assessment
Control Objective: All tools, MCP servers, and external APIs accessible to deployed agents must be subject to ongoing security assessment equivalent in rigor to the organization’s third-party software supply chain assessment process. Security assessments must address the tool’s update and dependency management practices, its authentication and authorization model, its data handling and retention practices, and its incident response capabilities. Tools that fail to meet the organization’s security standards must be removed from agent-accessible tool registries.
Implementation Guidance: Apply the OWASP ASI04 risk framework as a baseline for tool supply chain assessment. Include tool ecosystem assessment in the organization’s vendor risk management program, requiring tool vendors and MCP server operators to complete AI-CAIQ sections relevant to their service type. Monitor tool behavior at runtime for anomalies such as unexpected data access patterns or changes in tool response characteristics that may indicate tool compromise.
MAESTRO Layer: Layer 4 (Deployment and Infrastructure), Layer 6 (Security and Compliance)
OWASP ASI: ASI04 (Agentic Supply Chain Vulnerabilities)
ATLAS Coverage: Supply Chain Compromise of AI Tools
4.5 Orchestration Layer Security
The orchestration layer — the frameworks, platforms, and runtime environments that coordinate agent behavior, manage tool access, and route inter-agent communications — is both the most powerful and the most security-sensitive component of an agentic AI architecture. Compromise of the orchestration layer affects all agents running within it.
IVS-AG-01: Agent Execution Environment Isolation
Control Objective: Each agent’s execution environment must be isolated from other agents’ environments and from the infrastructure supporting human operations and other production systems. Isolation mechanisms must prevent an agent from reading the execution context of other agents, accessing credentials or session data belonging to other agents, or influencing the resource availability or scheduling of other agents. For agents with code execution capabilities, execution environments must be sandboxed to prevent access to host system resources beyond the defined tool interface.
Implementation Guidance: Deploy agent execution environments as isolated containers or virtual machines with network egress policies that permit only the external connections required by the agent’s authorized tool set. Implement process and filesystem isolation sufficient to prevent container escape attacks from agents with code execution capabilities. Review and harden orchestration framework configurations against known container escape and isolation bypass vulnerabilities, applying the MITRE ATLAS technique matrix for agent-specific attack techniques as a testing reference.
MAESTRO Layer: Layer 4 (Deployment and Infrastructure)
OWASP ASI: ASI05 (Unexpected Code Execution)
ATLAS Coverage: Sandbox Escape via Agent Code Execution
IVS-AG-02: Orchestration Platform Hardening and Integrity Monitoring
Control Objective: The orchestration platform itself — the software components that schedule, route, and manage agents — must be treated as high-assurance infrastructure, subject to the organization’s most stringent hardening, vulnerability management, and integrity monitoring requirements. The configuration of the orchestration platform must be version-controlled and immutable in production, with all changes requiring formal approval. Integrity monitoring must detect unauthorized modifications to orchestration platform components and alert immediately.
Implementation Guidance: Apply CIS Benchmark hardening guidance to orchestration platform containers and virtual machines. Implement file integrity monitoring for orchestration platform components. Require code signing for orchestration platform updates and verify signatures at deployment time. Treat the orchestration platform’s administrative interface as a privileged access target subject to privileged access workstation and just-in-time access requirements.
MAESTRO Layer: Layer 3 (Agent Frameworks), Layer 4 (Deployment and Infrastructure)
OWASP ASI: ASI08 (Cascading Failures)
4.6 Human-Agent Interaction Controls
The relationship between human operators and autonomous agents requires explicit governance controls to ensure that human oversight remains meaningful, that agents do not manipulate or circumvent human decision-making processes, and that the responsibility and accountability structure for agentic actions is clearly defined and enforceable.
HRS-AG-01: Agentic System Supervisor Competency Requirements
Control Objective: Personnel assigned supervisory responsibility for deployed agentic systems must demonstrate competency in interpreting agent behavior, recognizing signs of goal drift or behavioral anomaly, executing agent interruption procedures, and performing initial triage of agentic security incidents. Competency requirements must be documented, assessed at defined intervals, and updated as agent capabilities evolve. Personnel who do not meet competency requirements must not be assigned unsupervised oversight responsibilities for production agentic deployments.
Implementation Guidance: Develop an agentic system supervisor training and certification program covering the technical architecture of the organization’s agent deployments, the behavioral monitoring tools available to supervisors, and the escalation and incident response procedures for agentic systems. Include practical exercises simulating behavioral anomaly recognition and agent interruption. Maintain training records and link supervisor certification to the access provisioning process for agent monitoring consoles.
MAESTRO Layer: Layer 6 (Security and Compliance), Layer 7 (Agent Ecosystem)
OWASP ASI: ASI09 (Human-Agent Trust Exploitation)
GRC-AG-02: Human Escalation Protocol for Agent Action Review
Control Objective: Organizations must define and enforce explicit protocols for escalating agent actions to human review, specifying the circumstances that trigger escalation (action type, risk level, anomaly detection alert, scope of impact), the time window within which human review must occur, and the consequences for the agent workflow when human review is not completed within the required window (default to pause, not to proceed). Escalation protocols must be tested regularly and metrics on escalation frequency, response time, and outcomes must be reported to AI governance stakeholders.
Implementation Guidance: Implement escalation workflows in the orchestration platform that interrupt agent execution and present relevant context — the action proposed, the reasoning leading to it, the potential impact, and any anomaly signals — to the designated human reviewer through a purpose-built review interface. Design the default behavior on review timeout to be pause rather than proceed, placing the burden of approval on the human reviewer rather than on the agent. Track and analyze escalation patterns to identify systematic gaps in agent behavioral governance.
MAESTRO Layer: Layer 6 (Security and Compliance), Layer 7 (Agent Ecosystem)
OWASP ASI: ASI09 (Human-Agent Trust Exploitation)
5. AI-CAIQ Agentic Questions
The AI Consensus Assessments Initiative Questionnaire (AI-CAIQ) provides a self-assessment instrument mapped to AICM control objectives, designed to support STAR Level 1 self-assessments and vendor due diligence programs [6]. As organizations adopt agentic AI at scale, buyers and operators need a companion set of AI-CAIQ questions specifically addressing the proposed agentic supplement controls. The following sample questions illustrate the structure and intent of the agentic AI-CAIQ extension; a full question set would be developed in collaboration with the CSA CAIQ working group.
| AI-CAIQ Question ID | Question | Mapped Control |
|---|---|---|
| IAM-AG-01.1 | Does the organization maintain a centralized agent identity registry documenting all agents deployed in production, including their assigned purpose, authorized tool set, and current operational status? | IAM-AG-01 |
| IAM-AG-02.1 | Are agent permissions provisioned on a just-in-time basis scoped to the current task, with automatic revocation at task completion? | IAM-AG-02 |
| IAM-AG-03.1 | Does the organization enforce cryptographic non-escalation controls on agent delegation chains, preventing sub-agents from accumulating permissions exceeding those of their parent agent? | IAM-AG-03 |
| IAM-AG-04.1 | Are agent credential revocation procedures automated and tested to ensure all credentials issued to a terminated agent are revoked within the defined maximum window? | IAM-AG-04 |
| LOG-AG-01.1 | Does the organization capture and retain agent reasoning traces and tool invocation logs at a semantic level sufficient to support forensic reconstruction of a complete agent session? | LOG-AG-01 |
| SEF-AG-01.1 | Is a tested kill-switch mechanism available for all deployed agents, accessible to human operators without technical access to the agent’s execution environment? | SEF-AG-01 |
| GRC-AG-01.1 | Has the organization defined explicit risk thresholds for autonomous agent actions, with documented pre-approval gates for high-risk action categories? | GRC-AG-01 |
| AIS-AG-01.1 | Are all inter-agent messages cryptographically signed and verified, with unsigned messages rejected before processing? | AIS-AG-01 |
| CCC-AG-01.1 | Does the organization maintain a version-controlled tool registry subject to security review and formal change management for all additions or modifications? | CCC-AG-01 |
| STA-AG-01.1 | Are all tools and MCP servers accessible to production agents subject to ongoing security assessment equivalent in rigor to the organization’s third-party software supply chain assessment process? | STA-AG-01 |
| IVS-AG-01.1 | Are agent execution environments isolated from other agents’ environments and from production infrastructure, with sandboxing controls verified against container escape techniques? | IVS-AG-01 |
| HRS-AG-01.1 | Does the organization require and document competency certification for all personnel assigned supervisory responsibility for production agentic AI deployments? | HRS-AG-01 |
6. Summary Classification Table
The following table summarizes the distribution of control classifications across all 18 AICM domains, providing a quantitative view of the agentic coverage gap in AICM v1.0.
| Domain | Fully Applicable | Applicable with Modification | Missing | Total Assessed |
|---|---|---|---|---|
| AA – Audit and Assurance | 3 | 2 | 2 | 7 |
| AIS – Application and Interface Security | 3 | 1 | 2 | 6 |
| BCM – Business Continuity Management | 3 | 1 | 1 | 5 |
| CCC – Change Control and Configuration | 3 | 0 | 2 | 5 |
| CEK – Cryptography and Key Management | 3 | 1 | 2 | 6 |
| DCS – Datacenter Security | 3 | 0 | 0 | 3 |
| DSP – Data Security and Privacy | 1 | 4 | 3 | 8 |
| GRC – Governance, Risk and Compliance | 3 | 1 | 2 | 6 |
| HRS – Human Resources | 2 | 1 | 1 | 4 |
| IAM – Identity and Access Management | 2 | 1 | 5 | 8 |
| IPY – Interoperability and Portability | 3 | 0 | 2 | 5 |
| IVS – Infrastructure Security | 1 | 2 | 2 | 5 |
| LOG – Logging and Monitoring | 1 | 2 | 4 | 7 |
| MS – Model Security | 4 | 1 | 4 | 9 |
| SEF – Security Incident Management | 1 | 2 | 3 | 6 |
| STA – Supply Chain Management | 3 | 1 | 3 | 7 |
| TVM – Threat and Vulnerability Management | 2 | 1 | 2 | 5 |
| UEM – Universal Endpoint Management | 2 | 2 | 0 | 4 |
| Total | 43 | 23 | 40 | 106 |
Across the 106 control areas assessed in the gap analysis, 43 (41%) are Fully Applicable to agentic deployments as written, 23 (22%) are Applicable with Modification, and 40 (38%) represent material control gaps requiring new control objectives. The domains with the highest proportion of missing controls are Identity and Access Management (63% missing), Logging and Monitoring (57% missing), Model Security (44% missing), and Security Incident Management (50% missing) — the four domains most directly implicated in the detection and response to agentic security incidents.
7. Implementation Roadmap for Organizations
Organizations deploying or planning to deploy agentic AI systems should approach AICM compliance and the proposed agentic supplement as a multi-phase program. The phases below are designed to be executed sequentially, as later phases build on the identity infrastructure and behavioral governance capabilities established in earlier phases. Organizations already operating agentic AI in production without formal AICM compliance should treat Phase 1 as an immediate priority, as agent identity and credential management gaps represent exploitable vulnerabilities, not merely compliance deficiencies.
Phase 1 (Months 1-3): Foundation — Agent Identity and Credential Infrastructure
The first phase focuses on establishing the agent identity registry, just-in-time credential provisioning infrastructure, and credential revocation capabilities that are prerequisites for all subsequent agentic security controls. Organizations should implement IAM-AG-01 through IAM-AG-04, including the cryptographic agent identity infrastructure required by AIS-AG-01 for inter-agent authentication. Concurrently, organizations should conduct an inventory of all agents currently operating in their environment — including agents deployed by business units outside the central IT function — to establish a complete picture of the current agentic deployment landscape. The EU AI Act’s Article 9 requires a risk management system that identifies all high-risk AI deployments [8], and this inventory provides the foundation for that requirement as it applies to agentic systems.
Phase 2 (Months 4-6): Observability — Behavioral Monitoring and Logging
Phase 2 focuses on extending the organization’s logging and monitoring capabilities to capture the semantic-level observability required by agentic systems. Organizations should implement LOG-AG-01 behavioral baseline monitoring, extend SIEM integrations to ingest agent orchestration telemetry, and establish the behavioral metric definitions that will serve as reference points for anomaly detection. This phase should also include the deployment of SEF-AG-01 kill-switch capabilities, ensuring that the organization has the ability to interrupt agent execution before completing the more complex behavioral governance controls in Phase 3. The MAESTRO Layer 5 (Evaluation and Observability) guidance provides detailed technical reference for instrumentation architecture [3].
Phase 3 (Months 7-9): Governance — Tool Registry and Action Boundaries
Phase 3 establishes the governance infrastructure for agent capabilities and actions. Organizations should implement CCC-AG-01 tool registry management, including the security review process for new tool approvals, and GRC-AG-01 risk threshold and pre-approval gate configuration. STA-AG-01 runtime tool ecosystem assessment should be integrated into the existing vendor risk management program. This phase also includes the HRS-AG-01 supervisor competency certification program, ensuring that all personnel with oversight responsibilities for production agents have the training required to exercise that oversight effectively.
Phase 4 (Months 10-12): Hardening — Infrastructure Isolation and Advanced Controls
Phase 4 addresses the infrastructure-layer hardening controls and the more advanced inter-agent communication security requirements. Organizations should implement IVS-AG-01 and IVS-AG-02 execution environment isolation and orchestration platform hardening, validated through adversarial testing using the MITRE ATLAS agent-focused technique catalog [5]. GRC-AG-02 human escalation protocols should be formalized, tested, and integrated into the organization’s incident response program. Organizations completing Phase 4 should conduct a comprehensive gap assessment against the full proposed control set and develop a continuous improvement plan addressing any remaining gaps.
Throughout all phases, organizations should submit AI-CAIQ self-assessments to the CSA STAR registry, using the agentic companion questions proposed in Section 5 to provide transparency to customers and partners about their agentic security posture. Organizations in regulated industries should map Phase completion milestones to their regulatory compliance reporting obligations under the EU AI Act and applicable national AI governance frameworks.
8. Framework Alignment
The following table maps each proposed new control objective to the corresponding requirements in the EU AI Act, ISO 42001, NIST AI RMF, and MAESTRO, enabling organizations to use this supplement as a unified cross-framework compliance reference for agentic AI governance.
| Proposed Control | EU AI Act Article | ISO 42001 Clause | NIST AI RMF Function | MAESTRO Layer |
|---|---|---|---|---|
| IAM-AG-01: Agent Identity Registration | Art. 9 (Risk Management), Art. 12 (Record-Keeping) | Clause 8 (Operation) | GOVERN, MAP | Layer 3 (Agent Frameworks) |
| IAM-AG-02: Scoped Permission Provisioning | Art. 9 (Risk Management), Art. 14 (Human Oversight) | Clause 6.1 (Risk Planning), Clause 8 | MANAGE | Layer 3, Layer 6 |
| IAM-AG-03: Delegation Chain Management | Art. 9, Art. 14 | Clause 8 (Operation) | GOVERN, MANAGE | Layer 3, Layer 7 |
| IAM-AG-04: Agent Decommissioning | Art. 9, Art. 12 | Clause 8, Clause 9 (Performance Evaluation) | MANAGE | Layer 3, Layer 6 |
| LOG-AG-01: Behavioral Baseline Monitoring | Art. 12 (Record-Keeping), Art. 15 (Accuracy/Robustness) | Clause 9 (Performance Evaluation) | MEASURE, MANAGE | Layer 5 (Evaluation) |
| SEF-AG-01: Agent Kill-Switch | Art. 14 (Human Oversight) | Clause 8, Clause 10 (Improvement) | MANAGE | Layer 3, Layer 6 |
| GRC-AG-01: Action Risk Thresholds | Art. 9, Art. 14 | Clause 6.1, Clause 8 | GOVERN, MANAGE | Layer 6 (Security/Compliance) |
| AIS-AG-01: Inter-Agent Message Integrity | Art. 15 (Accuracy/Robustness/Cybersecurity) | Clause 8 | MEASURE, MANAGE | Layer 3 |
| AIS-AG-02: Agent Impersonation Prevention | Art. 15 | Clause 8 | MEASURE, MANAGE | Layer 3 |
| CCC-AG-01: Tool Registry and Governance | Art. 9 | Clause 8 (Operation) | GOVERN, MAP | Layer 3, Layer 4 |
| STA-AG-01: Tool Ecosystem Assessment | Art. 9 | Clause 8 | MAP, MEASURE | Layer 4 (Deployment) |
| IVS-AG-01: Execution Environment Isolation | Art. 15 (Cybersecurity) | Clause 8 | MANAGE | Layer 4 |
| IVS-AG-02: Orchestration Platform Hardening | Art. 15 | Clause 8 | MANAGE | Layer 3, Layer 4 |
| HRS-AG-01: Supervisor Competency | Art. 14 (Human Oversight) | Clause 7 (Support/Competence) | GOVERN | Layer 6, Layer 7 |
| GRC-AG-02: Human Escalation Protocol | Art. 14 (Human Oversight) | Clause 8 (Operation) | GOVERN, MANAGE | Layer 6, Layer 7 |
The alignment analysis reveals that EU AI Act Article 14 on human oversight and Article 9 on risk management are the two regulatory provisions most frequently implicated by the proposed agentic supplement controls. This reflects the fundamental nature of the agentic control gap: the core challenge is not that agentic systems are harder to secure at the infrastructure level, but that they operate with a degree of autonomy that makes traditional human oversight disciplines insufficient. The proposed controls are designed to restore meaningful human governance over consequential autonomous actions without eliminating the efficiency benefits that motivate agentic AI adoption.
ISO 42001 Clause 8 (Operation) carries the highest concentration of mappings among the ISO standard clauses, which is consistent with the operational focus of the proposed controls. NIST AI RMF’s GOVERN and MANAGE functions are the most-cited core functions, reflecting that the primary organizational need is not to measure agentic risk (organizations generally understand the risks conceptually) but to govern agent deployment decisions and manage risks throughout the operational lifecycle.
References
[1] Cloud Security Alliance. “Introducing the CSA AI Controls Matrix: A Comprehensive Framework for Trustworthy AI.” CSA Blog, July 10, 2025. https://cloudsecurityalliance.org/blog/2025/07/10/introducing-the-csa-ai-controls-matrix-a-comprehensive-framework-for-trustworthy-ai
[2] Cloud Security Alliance. “AI Controls Matrix.” CSA Artifacts. https://cloudsecurityalliance.org/artifacts/ai-controls-matrix
[3] Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” CSA Blog, February 6, 2025. https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
[4] OWASP GenAI Security Project. “OWASP Top 10 for Agentic Applications for 2026.” December 9, 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
[5] MITRE ATLAS. “MITRE Adversarial Threat Landscape for AI Systems (ATLAS).” https://atlas.mitre.org/. October 2025 update adds 14 agent-focused techniques in collaboration with Zenity Labs.
[6] Cloud Security Alliance. “AI Consensus Assessments Initiative Questionnaire (AI-CAIQ).” CSA Artifacts. https://cloudsecurityalliance.org/artifacts/ai-consensus-assessments-initiative-questionnaire-ai-caiq
[7] Cloud Security Alliance. “Agentic AI Identity and Access Management: A New Approach.” CSA Artifacts. https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach
[8] European Parliament and Council of the European Union. Regulation (EU) 2024/1689 Laying Down Harmonised Rules on Artificial Intelligence (Artificial Intelligence Act). Official Journal of the European Union, 2024. Articles 9, 12, 14, and 15.
[9] European Parliament and Council of the European Union. EU AI Act Article 14: Human Oversight. https://artificialintelligenceact.eu/article/14/
[10] Oasis Security. “AI Agents: Human Or Non Human.” https://www.oasis.security/blog/ai-agents-human-or-non-human. Citing industry analysis indicating non-human identities outnumber human users 82 to 1 in enterprise environments.
[11] OpenID Foundation. “Identity Management for Agentic AI.” October 2025. https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf
[12] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. January 2023. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
[13] ISO/IEC 42001:2023. Information Technology — Artificial Intelligence — Management System. International Organization for Standardization, 2023. https://www.iso.org/standard/42001
[14] Cloud Security Alliance. “Strategic Implementation of the CSA AI Controls Matrix: A CISO’s Guide to Trustworthy AI Governance.” CSA Blog, August 8, 2025. https://cloudsecurityalliance.org/blog/2025/08/08/strategic-implementation-of-the-csa-ai-controls-matrix-a-ciso-s-guide-to-trustworthy-ai-governance
[15] OWASP GenAI Security Project. “OWASP Agentic Security Initiative (ASI).” https://owasp.org/www-project-top-10-for-large-language-model-applications/initiatives/agent_security_initiative/
[16] Cloud Security Alliance. “Applying MAESTRO to Real-World Agentic AI Threat Models: From Framework to CI/CD Pipeline.” CSA Blog, February 11, 2026. https://cloudsecurityalliance.org/blog/2026/02/11/applying-maestro-to-real-world-agentic-ai-threat-models-from-framework-to-ci-cd-pipeline