The Problem
AI agents are indeterministic by nature. They reason about goals, choose tools at runtime, and chain services in ways nobody anticipated. Every existing compliance framework — SOC 2, ISO 27001, HIPAA — was designed to audit static systems with predictable behavior.
The EU AI Act creates a fundamentally different requirement. It asks: What was your AI system allowed to do? What did it actually do? What human controls were active at the moment of decision?
These are runtime questions. No static framework can answer them. And no product bolted onto an agent after deployment can reliably produce the evidence needed, because the evidence has to originate from inside the execution path.
The Compliant Agent Architecture (CAA) defines how to architect AI agents so compliance evidence is generated as a natural byproduct of execution. Not as an afterthought. Not as logging. As an architectural property.
"The real challenge is not proving what happened, but constraining what is allowed before execution."
Design Philosophy
CAA borrows from three fields that have solved analogous problems:
- Banking Model Risk (SR 11-7) — The only compliance framework that validates output behavior, not just infrastructure. CAA applies this thinking to agents.
- Capability-Based Security — Instead of asking "what should this agent NOT do," CAA asks "what is this agent architecturally ABLE to do." Unforgeable capability tokens, not ACL policies.
- Cryptographic Attestation — Every claim of compliance must be backed by a tamper-evident, independently verifiable record. If you can't verify it, it's not evidence.
The Six Principles
Capability Declaration
Every agent must declare its permitted tools, data access scopes, and decision authority in a read-only capability manifest before execution begins. The manifest is immutable at runtime. The agent cannot discover or invoke tools outside its declared capabilities.
This is not a policy document. It is an architectural constraint. The runtime environment enforces the manifest the way an operating system enforces process permissions. An agent that attempts to call an undeclared tool fails at the execution boundary, not at a policy check.
Execution Attestation
Every tool call, API request, and decision the agent makes generates a signed, tamper-evident execution record at the moment of action. Not reconstructed from logs. Not inferred from outputs. Generated at the execution boundary by the runtime itself.
The execution record contains: the action taken, the capability manifest that authorized it, the input context, the timestamp, and a cryptographic signature. An auditor can independently verify that any specific action was authorized by the manifest and occurred at the claimed time.
Decision Provenance
For every agent action, capture the full causal chain: what user input triggered the request, what context the model received, what reasoning produced the decision, what permissions authorized it, and what alternatives were considered.
Decision provenance is not "explainability" in the ML sense. It is a verifiable chain of custody from input to output. If an auditor asks "why did the agent do X on Tuesday at 14:32," the answer is a cryptographic proof, not a narrative.
Sovereign Evidence Chain
All execution records, decision provenance, and compliance evidence must be generated and retained inside the deployment boundary. No telemetry egress to third-party clouds. No compliance analysis by external SaaS.
The reason is circular but absolute: if you send agent behavior data to a US-hosted SaaS for EU AI Act compliance analysis, the act of analyzing compliance itself creates a GDPR compliance problem. Sovereignty is not a feature. It is an architectural invariant.
Human Override Proof
At every point during agent execution, the system must maintain a verifiable record of which human controls were active, what override capabilities existed, and who held the authority to intervene.
"Human in the loop" is not a design pattern. It is an evidence requirement. The EU AI Act does not ask whether a human could theoretically intervene. It asks whether you can prove that intervention capability was active at the specific moment a decision was made.
Deterministic Scope Binding
Agent behavior is bounded by configuration, not by prompting. The agent cannot modify its own capability manifest. It cannot escalate its permissions. It cannot invoke tools that were not declared at initialization. Scope expansion requires a new manifest — which requires human approval and generates a new attestation chain.
This principle directly addresses the indeterminism problem. The agent's reasoning may be non-deterministic, but its scope of action is not. The set of things it can do is fixed. How it decides which of those things to do is where the intelligence lives.
Standards Mapping
CAA is designed as a control overlay that complements existing frameworks. It does not replace SOC 2, ISO 42001, or AIUC-1. It fills the architectural gap that none of them address.
| Requirement | SOC 2 | ISO 42001 | AIUC-1 | CAA |
|---|---|---|---|---|
| Infrastructure security | ✓ | ✓ | ✓ | — |
| AI governance process | — | ✓ | ✓ | — |
| Adversarial testing | — | — | ✓ | — |
| Runtime behavioral evidence | — | — | — | ✓ |
| Architectural enforcement | — | — | — | ✓ |
| Evidence sovereignty | — | — | — | ✓ |
| Capability-bounded agents | — | — | — | ✓ |
Implementation
CAA is an architecture, not a product. It can be implemented with any agent framework. However, we provide open-source reference implementations:
Reference Stack
- SemaProof — Open-source agent firewall. Implements Capability Declaration (Principle 1) and Execution Attestation (Principle 2) as an Envoy sidecar. Sub-50ms latency.
- VERA Evidence Dashboard — Visualizes the execution record chain. Maps evidence to EU AI Act articles and AIUC-1 domains for auditor review.
- CAA Scanner — Free self-assessment that scores your agent architecture against the six CAA principles.
Assess Your Agent Architecture
Score your AI agent's compliance readiness against the CAA principles and EU AI Act in 60 seconds.
Contributing
CAA is an open framework. It will evolve as the regulatory landscape changes and as the community identifies gaps. If you work in AI governance, model risk, or agent infrastructure and see something wrong or missing, we want to hear from you.
Reach out: Yami G on LinkedIn · gopal.yami@gmail.com