The Missing Layer — Why SIEM, SOAR, and Guardrails Don't Cover Agent Actions

Your security stack has layers. Endpoint detection. Network monitoring. SIEM correlation. SOAR playbooks. Prompt guardrails. Each was designed for a specific threat model. None were designed for AI agents that can call tools.

A SIEM detects threats after they execute. A SOAR automates response to known incident patterns. Guardrails filter input prompts and output text. They're all doing their job. But for AI agents with tool access — agents calling kubectl, modifying databases, executing shell commands — they all operate too late in the chain. By the time they trigger, the damage is done.

SIEM: Detection after the fact

SIEMs are built to detect threat patterns in event logs. They ingest data from endpoints, networks, cloud APIs, and log aggregators, then correlate that data to find suspicious activity. When an attacker exfiltrates data, a SIEM picks it up from network logs. When malware deletes files, it shows up in endpoint logs. When a rogue admin changes firewall rules, that appears in cloud API audit trails.

The operational model is: action executes → logs are generated → SIEM collects logs → SIEM correlates and alerts → SOC responds.

For AI agents, this happens in real time, but the damage accrues in milliseconds. One customer reported a telling detail: "Our SIEM flagged it six minutes later. Six minutes is a long time." An agent was given access to production infrastructure and a goal to "clean up stale artefacts." In those six minutes, it deleted dozens of files across multiple systems. By the time the SIEM alert landed in the SOC dashboard, the rollback was already underway. The SIEM did its job. It just did it after the attack was over.

For compliance and forensics, that's acceptable. SIEMs are forensic tools by design. For agents making automated decisions against infrastructure you depend on, post-facto detection is not a control — it's damage assessment.

SOAR: Orchestration for known playbooks

SOAR platforms were built to automate incident response. When a SIEM alerts, a SOAR playbook can automatically isolate a host, revoke a compromised credential, kill a suspicious process, or page an engineer. The value is in automating well-understood, repeatable responses to known incident types.

But SOAR operates downstream of the threat. The incident has to be detected first. And for AI agents, SOAR doesn't understand the threat model at all.

An agent is non-deterministic. You don't know ahead of time what specific tool calls it will make. You can't write a SOAR playbook that says "if the agent calls kubectl delete pod, revoke its credentials" because that requires a SOAR platform that understands LLM output formats, parses tool call blocks, and can make decisions at the layer where the agent generates its intent. Most SOAR platforms operate at the infrastructure layer — logs, events, alerts from known tools — not at the agent layer.

More fundamentally, SOAR is reactive automation. It responds to what happened. What you need for agents is preventive control. You need to intercept the tool call before the agent ever executes it. SOAR doesn't do that.

Guardrails: Text filtering for chatbots

Prompt guardrails — tools like Guardrails AI, Lakera, NeMo Guardrails — were designed for a different problem: keeping chatbots from generating harmful text. They filter input prompts for injection attacks, filter output text for harmful content, and try to keep the system from going off-rails.

They work well for conversational AI where the risk is bad text. An LLM that's been jailbroken might generate instructions for making explosives or misinformation. Guardrails can detect that pattern in the output and block it.

Agents with tool access create a completely different risk. The risk is not "bad text." The risk is bad actions. When an agent decides to call `kubectl delete pod --all`, that's not a prompt injection and it's not harmful text — it's a structured function call. You can't guardrail-filter a structured tool call in the same way you filter natural language. The tool call is semantically precise. "Delete all pods" is exactly what the agent intends to do.

Guardrails also operate after the model has generated its intent, when the damage is nearly done. The model has already decided what it wants to do. Guardrails can refuse to execute it, but the agent knows it wanted to do something it wasn't allowed to do — and depending on the agent framework, it might retry, reframe, or escalate. That's not governance, it's a conversation with a refusal.

The missing layer: Pre-execution enforcement

The gap is this: between the moment an agent decides to act and the moment that action touches infrastructure, there is a window where policy can be enforced. That window is where real governance happens.

Every agent framework works the same way at this level:

• Agent calls LLM API with current context
• LLM returns response with structured tool-call blocks
• Agent parses tool-call block and executes the tool

The missing layer sits between steps 2 and 3. It intercepts the LLM response, evaluates every tool call block against policy, and makes a real-time decision to forward or block before the agent's code ever runs the command.

This is pre-execution enforcement. The tool call never reaches the agent unless it passes policy. If it's blocked, the agent sees a structured response explaining why — "This action violates policy because..." — and can adapt its next request accordingly. But the malicious or erroneous tool call never executes.

For SIEM, this means every allow/deny decision gets logged to an immutable audit trail. For SOAR, this means you have a complete record of attempted actions and enforcement decisions. For guardrails, this means you're not just detecting bad intent — you're preventing it.

What the complete stack looks like

A properly architected security posture for production AI agents looks like this:

The proxy is the new layer. It sits between the agent and the tools it calls. It reads every tool call, evaluates it against policy, logs the decision immutably, and decides whether execution proceeds.

This makes the rest of the stack work. SIEMs can now correlate enforce-enforced actions. SOARs can now respond to attempted violations. Guardrails can now operate at the policy layer, not the text layer. Everything downstream gets better because everything upstream gets a control point.

Why this architecture matters for different teams

For CISOs: You need to tell your board "we have pre-execution controls on agent actions." Post-execution monitoring doesn't meet that bar. Pre-execution enforcement does.

For SOC managers: You need agents to be detectable, but you also need them to be containable before they cause damage. A proxy-based governance layer gives you both: visibility into what the agent is trying to do, and the ability to deny it in real time.

For platform engineers: You need to run agents against infrastructure without fear. A governance layer that sits between the agent and the API endpoints it calls means you can grant agents access without granting them unlimited authority.

For compliance and audit: You need an immutable record of every decision made by every agent. SIEM logs show what happened. A governance proxy shows what was allowed to happen and what was prevented.

---

The key insight is this: your existing security stack was not designed with agents in mind. It assumes actions execute first, then get logged. Agents reverse that assumption — intent is generated before execution. The missing layer is the control point that sits in between.

How to think about tool-call interception

Tool-call interception sounds complex, but the principle is simple. It's the network-layer equivalent of what AppArmor or SELinux does for system calls, or what a Web Application Firewall (WAF) does for HTTP requests — it's a policy enforcement point that operates between a process and the resources it's asking to access.

For AI agents, the "resources" are tools: shell executors, database connectors, cloud API clients, file system operations. The "policy" is a set of rules that define what tools the agent can call, under what conditions, with what parameters.

The interception happens at the API layer. The agent makes requests to an LLM API, the proxy intercepts responses, reads the tool-call blocks, and decides whether they're permitted before returning them to the agent.

This is why architecture matters: an SDK-based approach (where the agent's code imports a library to enforce policy) can be disabled or bypassed by the agent itself. A proxy-based approach (where an external system sits between the agent and the API) is tamper-resistant. The agent cannot bypass what it cannot see.

Integrating the new layer with existing tools

Adding pre-execution enforcement doesn't replace SIEM, SOAR, or guardrails. It changes what they see and what they can do with it.

SIEM integration: The proxy writes every enforcement decision — allow or deny — to an immutable log that the SIEM ingests. This gives you a record of agent actions with policy verdicts attached, not just raw action logs.

SOAR integration: When the proxy denies an action, it can trigger a SOAR playbook to investigate why the agent attempted it. Was this a legitimate edge case that should be escalated? Was the agent confused about its permissions? SOAR can now orchestrate agent-specific incident response, not just infrastructure-level responses.

Guardrails integration: Guardrails can now focus on the output layer — preventing harmful text, jailbreaks, and unfiltered responses — while pre-execution enforcement focuses on the action layer. They operate at different levels and solve different problems.

---

The Missing Layer isn't a replacement for what you have. It's the control point that makes everything else in your stack work better for agents.

Getting started

If you're running or planning to run AI agents in production, ask yourself: Where in my stack can I enforce policy before an agent action executes?

If the answer is "I can't," then you're relying entirely on detection and response. That works for external attackers. It doesn't work for your own agents making mistakes.

The missing layer exists to answer that question. It's the point between "the agent decided to act" and "the action executed." That's where governance happens.

See the stack: Tool-call interception, AI agent proxy. Related reading: OWASP 17 Agentic AI Threats, Tool Misuse: The Biggest Agentic AI Threat.