What is agent compliance?

By Cameron McClellan, Growth Engineer

·Published June 23, 2026·Updated August 24, 2026

An AI agent does two kinds of compliance-relevant work, and each carries its own obligations. The first is the conversation: the data the agent is given and the output it produces. Data-handling, confidentiality, and retention obligations attach here, the moment information reaches the model, whether or not the agent goes on to act. The second is the action: the tool calls the agent makes to read a record, write a row, or invoke an API, under whatever authority it held at the start of the session. The obligations that govern changing a system of record attach here. Both happen at machine speed and in parallel, under credentials delegated from a human, across systems that were never built to report what an agent saw or did to a compliance team.

So when an auditor asks how the organization governs its AI, they are asking two things: where is the record, and what does it contain? The answer changes with the vendor and the license tier. A managed Claude or ChatGPT Enterprise tenant exposes a compliance API that can export the chat record. A developer running Cursor or Copilot produces almost no exportable record of what the model generated. An employee on a personal ChatGPT Plus or Claude Pro subscription sits outside all of it. The sections below cover what compliance requires, where the new agent security standards sit relative to the frameworks, the three gaps that block a complete record today, and how to close them.

What does agent compliance require?

ISO/IEC 42001, the first certifiable standard for managing AI, is mostly a management system: policies, risk processes, and accountability an organization documents before anything ships. A handful of its Annex A controls are different. They describe what has to be true while the AI runs, and they resolve into evidence only at runtime.

These controls share one hard property. The evidence is a byproduct of the system running, and it exists only if something recorded it as it happened. For an agent that means capturing both surfaces, the conversation and the action, and whether either one gets recorded is decided by the tool the agent runs inside. Most tools capture at most one.

Where does agent compliance sit in the standards stack?

ISO 42001 is one layer of a stack that has grown several more since agents started acting on production systems. The pieces are easy to confuse because each carries the word “compliance,” “trust,” or “conformance” somewhere, but they certify different objects at different altitudes: some certify an organization, one certifies a product, and some certify nothing and exist to make the others concrete. The table below maps the five layers, top to bottom.

ISO 42001 vs AARM: what’s the difference?

The two most often confused sit at opposite ends of the stack. ISO/IEC 42001 certifies an organization’s management process: policies exist, risks are assessed, accountability is assigned. An organization could plausibly pass with excellent documentation and no runtime enforcement at all, because the standard audits the program, not the traffic. AARM, short for Autonomous Action Runtime Management, is a Cloud Security Alliance specification that certifies a product: what a runtime agent security system must do to govern agent actions as they happen. ISO 42001 is to AARM roughly what ISO 27001 is to a protocol conformance spec, process and paperwork on one side, technical behavior on the other. (For how 42001’s own Annex A controls read when the AI is an agent, see ISO 42001 for agentic AI.)

The AARM spec defines nine requirements. The Core level (R1 through R6, all MUST) runs from pre-execution interception through identity binding, tying every action to a human, service, agent, and session; the Extended level (R7 through R9) adds semantic drift tracking, telemetry export to the SIEM, and least-privilege enforcement with scoped, just-in-time credentials. Putting pre-execution interception first codifies the position that detection after the fact does not count as runtime security. As of August 2026, 102 companies build on the spec, eight of them listed in the public builder registry after formal conformance review, and the category has its own conference, INTERCEPT, scheduled for February 2027. With CSA behind it, “is it AARM conformant?” is the kind of question that ends up on enterprise RFP checklists.

What are the Agentic Trust Controls?

Between the management standard and the product spec sits the control catalog. Agentic Trust Controls is an open-source catalog of 40 controls for agentic risks, grouped into identity and authority, action guardrails, memory protection, instruction integrity, adversarial testing, and runtime instrumentation. It exists because ISO 27001 and ISO 42001 expect an organization to define additional controls for risks the standards do not enumerate, and agents are exactly such a risk. The catalog is the missing Annex A for agents, the connective tissue between having an AI management program and knowing what the program checks at runtime.

Catalogs like this become mandatory through a predictable mechanism. GRC platforms ingest them as framework toggles, evidence collection against each control gets automated, and within a procurement cycle or two the controls appear in the security questionnaires an organization receives, whether or not it ever opted in.

How the layers fit together

For a buyer the stack composes top to bottom. An enterprise pursues ISO 42001 certification, adopts a catalog like Agentic Trust Controls as the concrete control set its program commits to, deploys a control plane with the capabilities AARM specifies as the technical implementation of the runtime controls, and exports the control plane’s logs into the GRC platform as evidence. One architecture answers the CISO, who speaks 42001, and the platform team, which needs the runtime capabilities, at the same time. The gaps in the next section all live in the bottom layer of the table, in what today’s evidence collection can actually see.

The three gaps that block agent compliance

The evidence the runtime controls need is capturable in principle. In practice, three gaps stand between an organization and a complete record:

1. The compliance APIs that agent vendors ship are new and uneven
2. A lot of AI usage runs on individual licenses the organization never sees
3. The GRC platforms that own the audit cannot collect any of it.

Vendor compliance APIs are new and uneven

The major vendors fall into two camps, and neither one is complete.

The enterprise chat products expose a compliance API that hands the conversation record to downstream tooling. Anthropic’s Compliance API is the most complete of the set. Running under https://api.anthropic.com/v1/compliance/*, it exposes an activity feed retained for six years, the underlying chat, file, and project content for claude.ai organizations, the directory of users and roles, and the effective settings for each linked organization. Content endpoints support both retrieve and delete, so a legal team can pull a conversation or honor a deletion request programmatically. Access is gated to Claude Enterprise; Team plans get a narrower CSV audit-log export, and Pro and Free get neither.

OpenAI’s Compliance Platform, launched in July 2024, exposes time-stamped interactions as immutable log files: conversations including prompt and response text, uploaded files, custom GPT configuration and metadata, memories, and workspace users. Eight eDiscovery and DLP vendors built integrations at launch, among them Microsoft Purview, Relativity, Smarsh, Netskope, and Zscaler. It is available on ChatGPT Enterprise and Edu only.

The coding tools log the administrative shell and leave the content out. Cursor offers audit logs and an Admin API on its Enterprise plan, but both carry administrative and usage metadata only, and the documentation is explicit that “we do not log agent responses or generated code content.” GitHub Copilot is the same shape. Its audit log captures seat assignment, policy changes, and configuration, and the docs state plainly that it “does not include client session data, such as the prompts a user sends to Copilot locally.” For the tools where an agent reads your codebase and writes changes, there is no native export of what it generated.

Individual licenses sit outside every agent platform’s control

Everything above assumes the AI came through a door the organization controls. Much of it does not. When an employee uses a personal ChatGPT Plus subscription, a Claude Pro account, or Cursor on the free tier, none of the enterprise machinery applies: no admin console, no compliance API, no audit log, no retention control, no SSO. The compliance API bought at the Enterprise tier sees nothing of it, because the activity belongs to a tenant the company does not own. This is the core of shadow AI, and it is the hardest part for compliance: the evidence an organization can produce is bounded by the licenses it centrally manages, and everything bought on a personal card is dark.

GRC platforms never see AI usage

Teams often assume their compliance platform already has this covered. It does not. The vendor compliance APIs above export to eDiscovery and data-loss-prevention archives. They do not directly export to Vanta or Drata.

The AI-vendor connectors that GRC platforms do ship are identity connectors. Vanta’s OpenAI integration and Drata’s OpenAI and Anthropic integrations sync the user roster and roles so that AI accounts can be folded into access reviews and deprovisioning. They pull who can log in. They pull nothing about how the AI is used: no conversations, no tool calls, no model configuration, no AI-specific audit trail.

What’s the difference between monitoring AI compliance and enforcing it?

The three gaps share a root cause, and the stack above makes it visible: every evidence source in them is out-of-band. A GRC platform sits beside the systems it watches. It polls read-only APIs on a schedule, compares what it finds to a framework, and produces evidence and alerts. Nothing passes through it, so it can detect non-compliance after the fact but can never prevent it; that is observability for compliance rather than control.

A control plane is in-band. It sits in the request path, so when an agent calls a tool, the call flows through the control plane, which decides in real time whether the action is allowed. A disallowed action never executes. The audit trail this produces is different in kind from a monitoring export: it is a record of what was enforced, not a snapshot of what was configured.

The distinction matters because of the standing criticism of checkbox compliance, that a company can hold a SOC 2 report and still have poor security, because SOC 2 attests to process rather than outcomes. Out-of-band evidence proves controls existed and were monitored. In-band evidence proves every recorded action passed policy, which closes the gap between being compliant and appearing compliant, and hands the auditor a strictly stronger artifact.

It also matters more for agents than it ever did for people. Detect-and-remediate was a tolerable posture for human employees because humans act slowly; an access review every quarter roughly kept pace with how fast a person could misuse an entitlement. An agent holds delegated credentials and can make ten thousand tool calls before lunch, in parallel, across every system it can reach. A quarterly review is not a meaningful control at that speed, and neither is an alert that fires an hour after the action. There is no auditing your way to safety at machine speed, so the governance has to sit in the path the actions travel.

Closing the gaps with an AI control plane

Closing these gaps means putting a layer in the request path at the boundaries the organization owns, rather than depending on each vendor’s tenant. An AI control plane is that layer: it sits between every AI agent in an organization and every system it can reach, enforces policy on the traffic, and, because every action passes through it, keeps the record the vendor APIs and GRC connectors leave behind, in a form built to export into the GRC platform itself. The record is a byproduct of the enforcement. Four capabilities map onto the gaps above.

Policy enforcement before the tool call runs

A control plane’s first job is the decision, and the record follows from it. Each tool call an agent makes is evaluated in the request path against policy bound to the identity the agent acts under: which tools it may call, on which systems, with which data. A call that fails the check never executes, and the log entry that results records the decision along with the action, which is what turns the audit trail from a snapshot of configuration into a record of enforcement. This is also the capability the runtime standards now name first: AARM’s R1 requires interception before execution, precisely because a record of unprevented actions proves monitoring rather than governance.

Cross-agent capture in one AI audit log

The vendor APIs each cover a single vendor’s conversation surface in a single vendor’s format, and the coding tools export nothing at all. A control plane records every agent the same way, so Claude, ChatGPT, Cursor, Copilot, and whatever ships next produce one uniform, queryable log instead of four partial exports stitched together by hand. Because the record is generated on the path rather than inside a vendor’s tenant, it captures both surfaces: the conversation, what the model saw and produced, and the action, what each agent did, with what arguments, against which system, under whose identity, and what came back. That is the same record ISO 42001 A.6.2.8 asks for, in one shape regardless of which model or tool generated it.

A device agent that captures shadow AI on any license

The hole individual licenses open is that the activity belongs to a tenant the company does not own, so no admin console or compliance API can reach it. A device agent installed on the endpoint closes it. It captures AI usage at the machine, which means a personal ChatGPT Plus or Claude Pro account is recorded the same as a managed enterprise seat, and the evidence an organization can produce stops being bounded by the licenses it centrally manages. Delivered through the MDM the fleet already runs, the agent is in place before the employee opens the laptop.

How the Speakeasy AI control plane fits

Speakeasy is building the AI control plane. The MCP gateway routes and governs every agent-to-tool connection, enforcing authentication and access policy server-side rather than trusting each laptop. Agent hooks instrument every tool invocation in a signed, append-only log: who called what, with what data, and what happened, across managed and unmanaged tools alike, in a form built to survive forensic review and to export into the GRC platform that owns the rest of the program. The design tracks what the AARM specification asks of a runtime agent security system: interception before execution, identity bound to every call, and telemetry that exports into the tools that own the program.

Speakeasy does not get a company certified, write its policies, or run its audit. It produces the runtime enforcement and the operational evidence that ISO 42001, SOC 2, and the EU AI Act require for agents, the part the compliance platform cannot auto-collect and the vendor APIs only partly reach. Vanta and Drata are framework-ingestion machines, and a control plane’s log is the strongest evidence they can ingest, a record of enforced behavior rather than polled configuration, produced with no separate collection step because every action was governed. For a platform or security team mapping how AI flows through the organization before an auditor or a regulator asks, the Speakeasy AI control plane is where that record begins.

Further reading

• What is AI governance?: the four functions an enterprise has to control, and how they fit together.
• What is shadow AI?: the unmanaged-license problem and how to detect it.
• The EU AI Act and the AI control plane: how the Act turns record-keeping and oversight into legal obligations.
• AI agent hooks: the primitive that captures the per-tool-call record at the agent itself.
• The AARM specification: the Cloud Security Alliance spec for what a runtime agent security system must do, with its conformance requirements and builder registry.
• Agentic Trust Controls: the open-source catalog of 40 controls extending ISO 27001 and ISO 42001 to agentic risks.
• AARM: a system specification for securing AI-driven actions at runtime: the paper behind the spec, including its threat model and the four implementation architectures.