Assurance
How does AI agent governance map to regulatory requirements?
Most frameworks converge on the same four demands for AI systems that take actions: know what the system is able to do, keep a human able to intervene, record what happened automatically, and restrict access to what is authorized. The specific articles differ; the controls that satisfy them largely do not. What follows is a control mapping rather than a certification claim — the obligations belong to you as the deployer.
The four demands underneath the frameworks
Reading the EU AI Act, NIST AI RMF, ISO/IEC 42001 and SOC 2 side by side, the same requirements recur in different vocabulary.
- Know the system's capability. An inventory of AI systems and a documented understanding of what each can do in its context of use. For agents this means the action surface, not the model card.
- Keep a person able to intervene. Human oversight with real authority to interrupt, assigned to identified, competent people.
- Record events automatically. Logging over the system's lifetime, generated by the system rather than assembled afterwards.
- Restrict access and monitor operation. Least privilege on what the system may reach, plus ongoing monitoring for deviation.
An organisation that can satisfy those four for its agents is most of the way through every framework below. The mapping that follows is which capability produces the evidence for which obligation.
Control mapping
| Framework | Obligation | Capability that produces the evidence |
|---|---|---|
| EU AI Act — Art. 14, Human oversight | High-risk systems designed so a person can oversee operation and intervene or interrupt it. | Actions crossing a policy threshold are held before execution and routed to a named approver. |
| EU AI Act — Art. 12, Record-keeping | Automatic recording of events over the lifetime of the system. | Every allow, block, and escalate written to a tamper-evident ledger at the moment of decision. |
| EU AI Act — Art. 26, Deployer obligations | Assign oversight to competent, authorized people; retain generated logs. | Approvers named per policy scope, so each approval records who held the authority. |
| NIST AI RMF — GOVERN, MAP | Inventory AI systems; document risk in the context of use. | Design-time action-surface mapping and classification, plus a live registry of agents and tools. |
| NIST AI RMF — MEASURE, MANAGE | Monitor identified risks on an ongoing basis and act on them. | Runtime tracing and anomaly detection, plus deterministic enforcement for known-unacceptable risks. |
| ISO/IEC 42001 — AI management system | Documented controls, objectives and operational evidence across the lifecycle. | One policy model spanning design-time classification and runtime decision records. |
| SOX — Segregation of Duties | Whoever initiates a transaction must not be the one who approves it. | SoD boundaries evaluated deterministically on every action; crossings blocked or escalated. |
| SOC 2 — CC6, CC7 | Restrict access to what is authorized; monitor system operation for deviation. | Least-privilege scoping enforced per operation, and a complete record of every decision including denials. |
| OWASP LLM Top 10 — LLM06:2025 | Limit tools, scope permissions to least privilege, require human approval for high-impact actions. | All three, as design-time scoping plus pre-execution authorization with named-approver escalation. |
| AIUC-1 — D003 | Per-agent tool authorization, parameter validation, logging of every tool call, human approval workflows. | Arbiter's pre-execution check on tool, operation and parameters, recorded per call. |
Where the deployer's obligation actually begins
A point worth being blunt about, because vendor compliance pages tend to blur it: under most of these frameworks the obligation is yours, not your vendor's.
The EU AI Act places distinct duties on providers and deployers, and an enterprise running agents in its own workflows is generally a deployer. Article 26 duties — assigning oversight to competent people, retaining logs, monitoring operation — do not transfer to a tool you bought. What a tool can do is produce the evidence that you met them, and make meeting them operationally possible.
So the useful question when evaluating any AI governance product is not whether it is "compliant" but which specific obligation each capability produces evidence for, and whether that evidence would survive being handed to a reviewer. A SOC 2 badge on the vendor says something about the vendor's own controls and nothing about your agents.
What auditors are starting to ask
Agent-specific audit questions have converged quickly, and they are unusually concrete for a new area:
- Which AI agents are running in production, who owns each, and what can each one reach?
- For this specific action: which agent took it, on whose authority, and against which policy?
- Which agent actions require human approval, and can you show the approvals?
- How do you know an agent cannot perform an action outside its approved scope?
- Show me a case where a control fired and prevented something.
The last one catches organisations out most often. Demonstrating that a control exists means showing it operating, which requires that denials are recorded as carefully as approvals — a system that only logs what succeeded cannot evidence that it would have stopped anything.
Common questions
Does the EU AI Act apply to internal enterprise AI agents?
It depends on what the agent does rather than on whether it faces customers. The Act's obligations attach by risk classification and role, and an enterprise running agents in its own workflows is typically a deployer rather than a provider. Agents operating in areas the Act treats as high-risk — employment decisions, access to essential services, creditworthiness among them — bring Article 26 deployer duties regardless of being internal. Agents outside those categories carry lighter obligations, but the underlying capabilities that satisfy the Act are the ones you need for SOX and SOC 2 anyway, so the practical answer is usually to build once.
Is a control mapping the same as certification?
No, and conflating them is the most common error in this area. A control mapping states which capability produces evidence for which obligation; certification is an independent assessment that an organisation's controls operate effectively, performed by an accredited body against a standard like ISO/IEC 42001. A mapping is what lets you prepare for and survive that assessment, and it is what an internal audit function needs in order to test coverage. No vendor can certify your deployment, because the obligations attach to how you have configured and operated it.
How do SOX Segregation of Duties rules apply to AI agents?
Directly, and that surprises people who expect SOX to be about people. The control is about incompatible functions being performed by the same actor, and an agent taking actions in a financial system is an actor for this purpose. If an agent can both raise a purchase order and approve one, the SoD control is broken whether or not a person was involved. What changes is enforcement: organisational friction that keeps people apart does not exist for an agent that can call both operations in the same second, so the boundary has to be evaluated on the action itself, before it executes.
What evidence do these frameworks actually want to see?
Records that a determination was made, not logs that something occurred. Across the Act's record-keeping article, ISO/IEC 42001's operational evidence expectations and SOC 2's monitoring criteria, the common requirement is contemporaneous and system-generated: written when the decision happened, by the system that made it, rather than assembled afterwards by someone correlating sources. That is why enforcement and evidence are the same problem — records produced as a by-product of an authorization decision meet the bar, and reconstructions built from application and gateway logs are an interpretation.
Do you need separate controls for each framework?
Rarely, because the demands overlap heavily. Design-time action-surface mapping serves NIST's GOVERN and MAP functions, ISO/IEC 42001's documentation expectations, and the scoping OWASP LLM06 calls for. Named-approver escalation serves EU AI Act Articles 14 and 26, AIUC-1's D003, and the human-authority element of SOX SoD. A contemporaneous decision ledger serves Article 12, SOC 2's CC7, and evidence expectations under 42001. The efficient approach is building those capabilities once and mapping outward, rather than running a control programme per framework.
Find the control gaps before your auditor does.
LangGuard maps your complete agent action surface in minutes. Free for the first five managed agents, with every Scope included from day one.