SOC 2 Compliance for AI Agents
The Runtime Security Controls Your Auditor Will Ask For

Traditional software is predictable. You deploy a function, it does what the code says. Access controls are static. Logging is straightforward. Auditors know how to evaluate it.

AI agents are different. They make runtime decisions about which tools to call, what data to access, and how to respond, all based on unpredictable inputs. An agent with database access might run a query it was never explicitly programmed to run. An agent with email tools might compose a message containing data from an unrelated context window. The behavior is emergent, and traditional RBAC doesn't cover it.

The OWASP Top 10 for Agentic Applications (published December 2025) and the NIST AI Agent Standards Initiative (launched February 2026) have given auditors a vocabulary for agent-specific risks. The gap is no longer awareness. The gap is evidence: you need to prove that your controls are enforced at runtime, not just written in a policy document that nobody reads.

SOC 2 organizes its criteria into five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. For AI agents, the Security category (Common Criteria) carries the most weight. Three groups within it map directly to agent runtime behavior:

Below, we walk through each relevant criterion and map it to the runtime security controls your auditor expects to see.

What your auditor will ask: "How do you restrict which systems and data your AI agents can access?"

This is where most teams stumble. You can point to IAM roles and database permissions, but those control what the application can do, not what the agent decides to do within those boundaries. An agent with access to a query_database tool might run SELECT * FROM users when it should only query product data. Static permissions allow it. Runtime policy enforcement prevents it.

Consider the team at a healthcare SaaS company that passed their SOC 2 audit in 2024. When they deployed a patient-facing AI agent in Q3 2025, their existing controls showed green across the board. The agent had the same database credentials as their application server. But on a Thursday afternoon, a prompt injection attack caused the agent to query billing records it was never meant to access. The IAM role allowed it. Nobody had considered that the agent's behavior was non-deterministic.

The control your auditor wants to see: per-agent tool access policies that are enforced at runtime, not just documented in a spreadsheet. This means defining which tools each agent can call, what parameters are allowed, and blocking any out-of-bounds access before it executes.

Rune's YAML policy engine lets you define per-agent scanner rules and enforcement actions (block, flag, or log). Each policy is declarative and version-controlled, so your auditor can review the exact rules that were active on any given date. For background on how privilege escalation attacks exploit overly broad permissions, see our threat database.

What your auditor will ask: "How do you detect anomalous behavior in your automated systems?"

For traditional systems, this means application logs and infrastructure monitoring. For AI agents, the bar is higher. Agents produce unstructured outputs, call tools in unexpected sequences, and might leak PII or secrets in their responses without any application error being thrown. Standard logging frameworks don't capture this.

The evidence artifact your auditor wants: a comprehensive audit trail of every agent interaction. Each entry should include a timestamp, the agent identifier, what was scanned (input or output), the scan verdict, and what action was taken. This isn't optional context. It's what CC7.1 requires for any system that processes sensitive data.

Our research across 1,000 agent sessions found that 14% contained prompt injection attempts and 9% showed data exfiltration patterns. Without runtime scanning, none of these would appear in your logs. Your auditor would see a clean audit trail not because threats didn't exist, but because you weren't looking for them.

Rune logs every scan event to ClickHouse with full context: agent ID, scan type, input/output content hash, threat classification, severity, and enforcement action. The dashboard surfaces this as a real-time event timeline that doubles as your audit evidence.

What your auditor will ask: "How do you monitor your AI agents in production?"

"We don't really know what our agents are doing in production." This is the most common answer we hear from engineering teams. It's also the worst possible answer to give an auditor. CC7.2 requires that you actively monitor system components for security events, not retroactively investigate them.

For AI agents, monitoring means scanning every input and output in real time. Not sampling. Not periodic batch analysis. Every interaction, evaluated against known attack patterns and behavioral baselines before it completes. The challenge is doing this without adding unacceptable latency to your agent's response time.

This is where a layered approach matters. A single scanning pass is either too slow (if it's thorough) or too shallow (if it's fast). A three-layer pipeline gives you both: fast pattern matching for known threats, semantic analysis for variations, and behavioral analysis for novel attacks.

Rune's SDK wraps your agent I/O with a three-layer scanning pipeline: L1 pattern matching completes in under 5ms, L2 semantic similarity analysis in under 30ms, and L3 behavioral correlation asynchronously for deeper analysis. Your agent's response time stays fast while every interaction gets scanned. For a deeper look at how this works against prompt injection, see our complete guide to AI agent security.

What your auditor will ask: "How do you evaluate and respond to security events from AI agents?"

Detection without evaluation is just noise. CC7.3 requires that detected events are classified by severity, assigned to responsible parties, and acted on within defined timeframes. For AI agents, this means more than a log entry. It means a severity-based alerting system that routes critical events to the right people.

Here's what this looks like in practice. A developer at an e-commerce company deployed a product recommendation agent in January 2026. Two weeks later, their monitoring flagged an unusual pattern: the agent was including customer email addresses in its public-facing recommendations. Not a prompt injection. Not a security breach in the traditional sense. The agent had access to customer data for personalization and was leaking it through its outputs. Because the team had severity-based alerting, the data exfiltration pattern was caught within minutes, not weeks.

The evidence your auditor needs: alert history showing detection timestamps, severity classification, who was notified, and what action was taken. Rune generates alerts automatically when scans detect threats above your configured severity threshold. Critical and high-severity events trigger immediate notifications via Slack, email, or webhook. Each alert includes the full event context, making post-incident review straightforward. For a walkthrough of how this works in a real attack scenario, see our prompt injection case study.

What your auditor will ask: "What is your incident response process for AI agent security events?"

When an agent is compromised, you need three things immediately: a kill switch to stop it, a forensic trail to understand what happened, and a recovery process to get back to a known-good state. CC7.4 requires documented incident response procedures and evidence that they work.

For AI agents, the kill switch is non-negotiable. Unlike a traditional service where you can roll back a deployment, a compromised agent might be actively exfiltrating data or executing unauthorized tool calls right now. You need the ability to block a specific agent in real time without taking down your entire application.

Rune's block mode stops compromised agents immediately. The full event log provides a forensic trail for post-incident review: what the agent did, when, what was scanned, and what was blocked. This evidence is exactly what CC7.4 requires. For a broader incident planning framework, see our agent security checklist (item 8: "Plan for incidents").

What your auditor will ask: "How do you manage changes to your AI agent configurations and security policies?"

AI agent configurations change constantly. New tools get added. Models get swapped. Prompts get updated. Policy thresholds get adjusted. Each of these changes can alter your agent's security posture, and your auditor will want to see a trail of what changed, when, and who approved it.

The simplest way to satisfy CC8.1: treat your security policies as code. Rune policies are defined in YAML and stored alongside your application code in version control. Every change goes through your normal PR review process. Every merged change has an author, a reviewer, and a timestamp. Your auditor can reconstruct the exact policy configuration that was active on any date by checking your git history.