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.

In the incident this product came out of, the 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 files across several 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. The SOAR platforms we have looked at operate at the infrastructure layer: logs, events and alerts from known tools, not 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 each tool call block against policy, and decides 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. On a deny the response is rebuilt: the tool_use block is replaced by a text block naming the policy, and the runtime is handed a turn that has ended rather than a call to make.

Each allow and each deny is one row in an append-only, hash-chained trail. That is a record of what was attempted, with the verdict beside it.

What the complete stack looks like

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

Agent code

    ↓

[Interception proxy] ← Policy evaluation (pre-execution)

    ↓

Tool execution

    ↓

SIEM ← Post-execution logging

    ↓

SOAR ← Automated response
        

The proxy is the new layer. It sits between the agent and the tools it calls. It reads each tool call, evaluates it against policy, writes the decision to an append-only row the agent cannot reach, and decides whether execution proceeds.

A verdict beside each attempted action is a field the SIEM does not otherwise have. The control this adds is a decision before the call; everything else in the stack still runs after it.

---

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 is an HTTP proxy in front of the provider endpoint, doing what a Web Application Firewall does for HTTP requests: a policy enforcement point between a process and what it is asking to reach.

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 (an external system between the agent and the API) puts the enforcement outside the process, so the agent cannot turn it off. It can still repoint its base URL at the provider, and closing that path takes network egress control.

What it does not connect to

There is no forwarder to a SIEM and nothing calls out to a playbook on a deny. The events table is queryable per tenant and the dashboard exports the filtered view to CSV. Anything downstream of that, you wire yourself.

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.