What do auditors need for AI agent compliance?

Auditors need evidence that controls exist and function at runtime. For AI agents, that means structured audit logs showing every action the agent took, policy configurations proving restrictions were in place, and tamper-evident records proving the logs were not modified after the fact. A description of your model or a list of intended behaviors is not sufficient.

Which frameworks apply to AI agents?

SOC 2 Trust Services Criteria apply when agents process customer data. The EU AI Act (Articles 9, 12, 14, 15) applies to high-risk AI systems starting August 2, 2026. NIST SP 800-53 Rev. 5 covers federal and regulated environments. The OWASP Top 10 for Agentic Applications (2026) defines the 10 most common agent-specific security risks. Each framework has different evidence requirements, but all of them require audit logging and runtime controls.

How do you prove an AI agent followed policy?

You need three things: a record of every action the agent attempted, proof that policy controls were active during those actions, and tamper-evidence showing the records were not altered. Pipelock's flight recorder writes hash-chained JSONL logs with Ed25519 signed checkpoints. The pipelock assess command generates signed evidence bundles that map controls to specific framework requirements.

AI Agent Compliance

AI agents make HTTP requests, call external tools, read files, and write code. Each of those actions creates compliance exposure. If an agent leaks credentials, calls an unauthorized API, or follows a prompt injection into a policy violation, your organization owns the consequences.

AI agent compliance is the practice of proving that agents operated within defined boundaries. Not describing what they should do. Proving what they did.

What Auditors Actually Ask

Auditors do not ask “what model do you use?” They ask:

What controls restrict agent behavior? They want to see policy configurations, not architecture diagrams.
What evidence proves those controls were active? Logs with timestamps, not a slide deck.
Can someone tamper with the evidence? They look for integrity guarantees: hashing, signing, chain-of-custody.
What happens when a control fails? They want fail-closed behavior, not “the agent retries.”

The gap for most teams is that traditional application monitoring does not capture agent-specific actions. Your APM tool logs HTTP responses. It does not log which MCP tool the agent called, what arguments it passed, or whether DLP scanning blocked a credential in the request body.

Risk Areas for AI Agents

Agents introduce risks that do not exist in traditional software:

Data leaks. Agents handle credentials, API keys, and customer data in tool arguments and HTTP bodies. A single unscanned request can exfiltrate secrets to an attacker-controlled domain.

Unauthorized actions. An agent with broad tool access can call APIs it was never intended to use. Without tool-level policy, there is no boundary between “allowed” and “not allowed.”

Unmonitored tool use. MCP servers give agents access to databases, file systems, and external services. If tool calls are not logged, you have no record of what the agent did.

Prompt injection leading to policy violations. An attacker injects instructions into content the agent reads. The agent follows those instructions, bypasses its intended behavior, and the violation looks like normal operation unless you inspect the content that triggered it.

Framework Mappings

Different frameworks ask for different things. Here is what each one requires for agents:

Framework	Agent-Relevant Requirements	Evidence Type
SOC 2 (TSC)	Access controls, monitoring, data confidentiality, processing integrity	Audit logs, policy configs, incident records
EU AI Act (Art. 9, 12, 14, 15)	Risk management, automatic event logging, human oversight, cybersecurity	Structured logs, override records, fail-closed proof
NIST 800-53 Rev. 5	AC (access control), AU (audit), CM (config management), SI (system integrity)	Per-family control evidence, continuous monitoring data
OWASP Agentic Top 10	Goal hijack, tool misuse, supply chain, privilege abuse, rogue agents	Scanner results, tool policy logs, injection detection records

SOC 2 auditors want to see that you know what your agents access and that you restrict it. The EU AI Act wants automatic logging and a stop button. NIST 800-53 maps to specific control families. OWASP gives you a threat checklist to test against.

For detailed framework-specific mappings, see Compliance Evidence and EU AI Act Compliance.

The Evidence Model

Compliance evidence for agents has four layers:

Audit logs. Structured records of every agent action: URL, method, scanner verdict, timestamp, request ID. These are the foundation. Without them, nothing else matters.

Signed receipts. Each action gets an Ed25519 signed receipt proving the mediator observed it and reached a decision. Receipts include the policy hash that was active at the time, the verdict, and the transport surface that processed the action.

Tamper-evident chains. Receipts and log entries are hash-chained. Each entry includes the SHA-256 hash of the previous entry. Insert, delete, or reorder a record and the chain breaks. Signed checkpoints at configurable intervals provide cryptographic proof the chain was intact at that point.

Redaction for sensitive data. Compliance logs should not become a second source of leaked secrets. DLP scanning runs on each entry before it is written. Matched patterns are replaced with redaction markers. For incident response, encrypted escrow sidecars preserve the original content under a separate key.

Runtime Policy Controls

Evidence without enforcement is just observation. Agents need runtime policy controls that restrict behavior before it happens:

Domain allowlists. Agents can only reach domains you explicitly permit. Everything else is blocked.

DLP scanning. Credential patterns, environment variables, and high-entropy strings are detected and blocked in request bodies, URLs, headers, and MCP tool arguments.

Tool restrictions. MCP tool policies define which tools an agent can call and what arguments are allowed. Unauthorized tool calls are blocked at the proxy layer.

Budget controls. Rate limiting prevents runaway agent behavior. Per-agent profiles isolate settings so one agent’s permissions do not leak to another.

Human-in-the-loop. Flagged actions pause the agent and require human approval. Timeout defaults to deny.

Kill switch. Four independent activation sources (config file, API endpoint, signal, sentinel file). Any one active blocks all traffic immediately.

How Pipelock Supports Compliance

Pipelock is an open-source AI agent firewall that sits between agents and the network. It enforces policy at runtime and generates the evidence auditors need.

Flight recorder. Hash-chained, tamper-evident JSONL audit log with Ed25519 signed checkpoints and DLP redaction. Every scan decision, policy action, and session event is recorded. See Flight Recorder for the full format.

Signed assessment reports. pipelock assess runs attack simulations, scores your config, verifies your installation, and discovers unprotected MCP servers. The output is a signed evidence bundle with framework-specific control mappings. Generate reports for auditors with a single command. See Assess.

OWASP coverage. Pipelock maps to all 10 categories in the OWASP Agentic Top 10. Scanner layers are mapped to specific threat categories so you can show auditors exactly which control addresses which risk.

Runtime enforcement. Domain allowlists, DLP scanning, MCP tool policy, SSRF protection, prompt injection detection, rate limiting, and human-in-the-loop approval. Controls are active at runtime, not applied after the fact.

Fail-closed architecture. Scan errors, parse failures, DNS errors, and HITL timeouts all default to block. Auditors want to know what happens when something goes wrong. The answer is: traffic stops.

AI Agent Compliance: Audit Logs, Policy, and Evidence