Your AI Agents Pass Code Review. What Are They Doing in Production?

Your AI agent passed every code review. The prompt templates were vetted. The tool permissions were scoped. The architecture follows the patterns from your audit-ready LLM design. And then the agent hit production, connected to six MCP servers, generated 1,400 log events in two hours, and accessed a customer database table that wasn't in any of your test scenarios.

Nobody noticed for three weeks.

This is the gap between what I'd call "shift left" security - catching problems during design and development - and what actually happens at runtime. Most teams building with AI agents have invested heavily in the first part. Almost nobody has invested in the second. A CSO Online investigation published today makes the case that runtime monitoring for AI agents is the next major challenge facing security teams. Having worked with startups deploying agents in production, I think the compliance angle is even more urgent than the security one.

The 100x cost problem

Endor Labs CEO Varun Badhwar puts a number on the gap: fixing a security issue caught at build time costs roughly $40. Catching the same issue at runtime costs around $4,000. That's a 100x multiplier, and it maps directly to what I've seen with compliance remediation.

When an auditor finds an unmonitored agent during a SOC 2 review, you're not just fixing the monitoring gap. You're reconstructing what the agent did during the observation period, proving it didn't access data it shouldn't have, and documenting controls that should have been in place from the start. That forensic reconstruction work is where the real cost lives.

The problem is that build-time security alone can't prevent every runtime issue. Agents make dynamic decisions. They invoke tools based on prompt context that didn't exist when you wrote the code. They interact with external systems that change independently. You can design the perfect architecture and still have an agent behave in ways nobody anticipated, because the entire point of agents is that they respond to novel situations.

This is why the "shift left, shield right" framing resonates. Shift left means designing your agent architecture for compliance from day one - scoped permissions, structured logging, access controls at every layer. I covered that in depth in the audit-ready LLM architecture guide. Shield right means monitoring what agents actually do in production and catching the behaviors that slipped past your design assumptions.

You need both.

What agents actually look like at runtime

Joe Sullivan, the former CSO at Uber, Cloudflare, and Facebook, described AI agents with a line that stuck with me: "Agents are like teenagers - they have all access and none of the judgment."

The data backs this up. During a typical two-hour session, a human user generates 50-100 log events. An AI agent running the same workload generates 500-2,000 events. That's 10-20x more activity, and the activity patterns are fundamentally different from human behavior.

Here's what that looks like in practice:

That last row is the one that keeps me up at night. When a human hits a permission error, they stop and ask someone. When an agent hits a permission error, it might try a different tool, use a different credential, or find an alternative path to the same data. That's exactly what agents are designed to do - solve problems autonomously. But from a compliance perspective, it means your access controls face an adversarial workload that traditional monitoring wasn't built to handle.

The three runtime gaps SOC 2 auditors are finding

I've been tracking the questions auditors are starting to ask about AI agents, and three gaps come up repeatedly. Each one maps to a specific SOC 2 trust services criterion.

Gap 1: Missing agent inventory

You can't monitor what you don't know exists. Most companies I talk to can't answer a basic question: how many AI agents run in your environment right now?

Agents proliferate across teams. Marketing deploys a content agent. Engineering ships a coding assistant. Customer success connects an AI to the support queue. Each team provisions their own agent through their own channels, and the security team has no central registry.

This directly conflicts with SOC 2 CC6.1 (logical and physical access controls) and CC6.2 (credentials and authentication mechanisms). If you can't enumerate the agents in your environment, you can't demonstrate that each one has appropriate access controls.

I covered the identity governance side of this problem in my post on AI agents as identity dark matter - the 70% of enterprises running agents in production with no IAM visibility. Runtime monitoring starts with solving the inventory problem.

Gap 2: Inadequate logging

Not all agent platforms generate audit trails by default. Some coding agents overwrite session logs when sessions are replayed. Some agent frameworks log tool invocations but not the prompt context that triggered them. Some log nothing at all.

For SOC 2, this is a CC7.1 (security monitoring) and CC7.2 (anomaly detection) problem. Your auditor will ask: can you show me a complete log of this agent's actions over the last quarter? If the answer is "the agent platform doesn't retain logs beyond 30 days" or "logs are stored in the agent's own filesystem and the agent can modify them," you have a finding.

The critical detail from the CSO investigation: behavioral logs must be stored in write-protected, separate systems. Not the agent platform's native logging. Not a log file the agent process can access. An external, append-only log store that the agent has no ability to modify or delete.

Gap 3: No behavioral baseline

Even when agents are logged, most teams have no baseline for what "normal" agent behavior looks like. They can tell you what the agent did. They can't tell you whether what the agent did was expected.

This matters for SOC 2 CC7.2 specifically, which requires monitoring for anomalous activity. An agent that normally makes 200 API calls per hour suddenly making 2,000 should trigger an alert. An agent that normally accesses three database tables suddenly querying a table containing PII should trigger an alert. Without a behavioral baseline, these anomalies are invisible.

CrowdStrike CTO Elia Zaitsev describes the technical approach: EDR technology can "associate end behavior with agentic systems" through threat graphs, essentially treating agent activity as a trackable chain of causation rather than isolated events. The key insight is that agent-specific policies need to be different from human employee controls, because the behavioral patterns are fundamentally different.

A practical runtime monitoring architecture

Here's the monitoring architecture I recommend for startups deploying AI agents. It's designed to satisfy SOC 2 requirements without requiring enterprise-grade tooling.

Layer 1: Agent registry

Before anything else, build a central inventory. Every agent in your environment gets an entry with:

• Unique agent identifier (not a shared service account)
• Human owner/sponsor
• Approved tool and data access list
• Deployment environment (dev/staging/production)
• Date provisioned and last review date

This can start as a spreadsheet. It doesn't need to be a product. The point is that when your auditor asks "what AI agents run in your environment?" you have a definitive answer.

Layer 2: Structured event logging

Every agent action needs to produce a structured log event. At minimum, capture:

{
  "timestamp": "2026-03-17T14:23:01Z",
  "agent_id": "support-agent-prod-01",
  "agent_owner": "cs-team@company.com",
  "action": "tool_invocation",
  "tool": "crm_read",
  "input_summary": "customer lookup by email",
  "output_summary": "1 record returned, fields: name, plan, last_contact",
  "prompt_context_hash": "sha256:abc123...",
  "session_id": "sess-7f3a2b",
  "duration_ms": 340,
  "data_classification": "pii"
}

Two critical requirements: these logs go to a write-protected external store (not the agent's own filesystem), and they include enough context to reconstruct the decision chain (why did the agent invoke this tool?).

Layer 3: Behavioral baselines

After two weeks of production data, you'll have enough history to establish baselines. Track at minimum:

• Volume: Average tool invocations per hour, per agent
• Scope: Which tools and data sources each agent typically accesses
• Timing: When each agent is normally active
• Error rate: How often each agent hits permission errors or tool failures
• Data sensitivity: What classification level of data each agent normally touches

Alert when any metric deviates more than 2 standard deviations from baseline. This gives you the anomaly detection SOC 2 CC7.2 requires without needing a dedicated SIEM for agent activity.

Layer 4: Agent-specific policies

This is where most teams get it wrong. They apply the same monitoring rules to agents that they apply to human users. But agent behavior is fundamentally different, and the policies need to reflect that.

Agent-specific policies I recommend:

That last row is particularly important. A human user physically can't download your entire customer database in a single session. An agent can, if its permissions allow it. Volume-based caps on data access, specific to each agent's approved use case, are a control that doesn't exist in most traditional monitoring setups.

Layer 5: Incident response for agents

Your incident response plan needs agent-specific runbooks. The key questions are different:

1. Containment: Can you revoke this agent's credentials within minutes? Not hours. Minutes.
2. Forensics: Can you reconstruct the agent's complete action chain across all tools and services it touched?
3. Blast radius: If the agent's credentials were compromised, what's the maximum data exposure? (This maps directly to understanding liability when agents go wrong - the forensic record you build here determines your legal exposure.)
4. Recovery: Can you replay the agent's session against a known-good baseline to identify exactly which actions were anomalous?

If you can't answer these four questions for every production agent, you have a gap that will show up in your next SOC 2 review.

The EU AI Act angle

If you're shipping into European markets, runtime monitoring isn't just a SOC 2 consideration - the EU AI Act has explicit requirements.

Article 26(5) mandates that deployers of high-risk AI systems monitor their operation and report serious incidents to providers and authorities. Article 14 requires human oversight mechanisms that can "understand the capacities and limitations of the high-risk AI system and be able to duly monitor its operation."

Even if your agent doesn't qualify as "high-risk" under the Act's classification, Article 50 imposes transparency obligations on all AI systems that interact with people. You need to prove that users know they're interacting with AI, and you need records showing the system operated within its documented parameters.

Runtime monitoring gives you the evidentiary basis for all of these requirements. Without it, you're asserting compliance you can't prove.

Start small, start now

I know this looks like a lot of infrastructure. But the 100x cost differential between build-time and runtime remediation means every week you delay makes the eventual implementation more expensive.

Here's the minimum viable version:

1. This week: Build your agent registry. List every agent running in production, who owns it, and what it can access.
2. Next sprint: Add structured logging to your highest-risk agent (the one with the broadest data access). Ship logs to an external, append-only store.
3. Within 30 days: Establish behavioral baselines from the log data. Set up alerts for 2-sigma deviations.
4. Within 60 days: Document agent-specific monitoring policies and incident response procedures.
5. Before your next audit: Review the full monitoring architecture against SOC 2 CC6.1, CC7.1, and CC7.2 requirements.

The teams that build runtime monitoring into their agent infrastructure now will have clean audit evidence when their SOC 2 observation period includes AI agents. The teams that wait will be reconstructing months of unmonitored agent activity under auditor pressure.

I've seen both scenarios. You want to be in the first group.

Keep reading:

• Audit-Ready LLM Architecture: SOC 2, EU AI Act, and ISO 42001
• AI Agents Are Identity Dark Matter - And Your IAM Stack Can't See Them
• AI Agents and Liability: Who's Responsible When the Agent Gets It Wrong?

Deploying AI agents and need to pass your SOC 2 audit? Let's talk.