Compliance Controls
for AI Agents

The nine chapters preceding this one describe security controls: what to build, why it matters, and how to implement it. This final chapter connects those controls to the compliance frameworks that organizations are now required — or expected — to satisfy when deploying AI agents. The central finding is that a well-instrumented security architecture largely produces compliance evidence as a side effect. Organizations that build security correctly do not need a separate compliance program for AI agents; they need to know which controls map to which requirements, and to ensure their evidence store is organized to answer the questions an auditor will ask. Organizations that skip the security architecture and try to produce compliance evidence directly will fail at both, because the evidence regulators ask for is the output of real security controls, not a documentation exercise. This chapter is the mapping between the two: security controls on the left, compliance requirements on the right, and the evidence artifact in the middle.

The four major frameworks and what they require

The control-to-compliance mapping

The EU AI Act in detail: what high-risk agentic systems must demonstrate

The EU AI Act's high-risk obligations require organizations to demonstrate, to a notified body or conformity assessment, that the AI system's design and operation satisfies the requirements of Articles 9 through 17. For agentic deployments, the most operationally demanding of these are Article 9 (risk management system, documented and continuously updated), Article 12 (automatic logging sufficient to reconstruct decisions, with retention appropriate to the risk profile), and Article 14 (human oversight capability, technically embedded in the system, not just a procedural fallback). Article 9 is satisfied by the governance program from Chapter 2 and the risk-classification logic from Chapter 3. Article 12 is satisfied by the audit and monitoring infrastructure from Chapter 7, provided the log store is immutable, retention-bound, and can reconstruct the model output, the policy decision, the data accessed, and the action taken for every agent decision. Article 14 is satisfied by the human-in-the-loop guardrails from Chapter 4, provided the technical implementation gives a human the ability to intervene before an agent takes a consequential irreversible action, not just after.

The August 2026 full enforcement date is not a grace period extension — it is the date after which non-compliance carries financial penalties of up to 3% of global annual turnover (Article 99). Organizations that have not yet mapped their AI agent deployments to the high-risk categories in Annex III should do so before that date. The safe assumption for production agents that affect outcomes for natural persons in areas like credit, employment, education, healthcare, or critical infrastructure is that the high-risk tier applies until a documented risk assessment concludes otherwise.

Producing compliance evidence from the security infrastructure

The operational goal is a compliance evidence store that doubles as the security audit log: a single, well-instrumented action log store that can answer any auditor's question about what an agent did, why it did it, what policy governed it, and who authorized it. Teams that build this correctly find that EU AI Act Article 12 evidence, SOC 2 CC7.2 evidence, and NIST AI RMF Measure function evidence are all queries against the same store. Teams that build compliance evidence separately from security observability end up with two incomplete systems that disagree when it matters.

The evidence artifacts that typically satisfy all four frameworks simultaneously are: the agent registry (Chapter 8) demonstrating governance coverage; the action log from Chapter 7 demonstrating runtime decision traceability; anomaly alert records demonstrating continuous monitoring; policy decision records demonstrating least-privilege enforcement; and incident response records (including the shadow/rogue detection procedures from Chapter 8) demonstrating operational response capability. None of these require building a new system; they are outputs of the security controls this series has described.

What the compliance gap looks like in practice

The Cloud Security Alliance's 2026 survey finding — that 67% of compliance leaders say their frameworks don't cover AI agent risk, yet fewer than 20% have updated their control inventories — describes a gap that is partly technical and partly organizational. The technical gap is that AI agents introduce new action types (model calls, tool invocations, inter-agent messages) that existing control frameworks were not designed to capture. The organizational gap is that AI agent deployments often happen outside the procurement and change management processes that would normally trigger a controls review. The detection controls in Chapter 8 address the latter; the controls mapping in this chapter addresses the former. Together, they give a compliance program the coverage it needs to address AI agent risk without waiting for each framework body to publish AI-specific guidance.