Guardrails stop prompts, not agent network traffic

At a glance

What this is: This is an analysis of why text-layer AI guardrails are necessary but insufficient when agents can act through network and tool channels.

Why it matters: It matters because IAM, NHI, and AI security teams need layered controls that cover runtime tool use, not just model prompts and outputs.

Context

AI guardrails are designed to classify text, not to govern every action an agent can take once it moves beyond the prompt. In practice, that leaves a governance gap between what the model sees and what the surrounding runtime, network, and tool stack actually does.

For AI agents, the primary security question is not whether a prompt is safe enough to pass a classifier. It is whether the broader execution path, including HTTP, MCP, DNS, and WebSocket activity, is governed as part of the agentic AI security boundary.

Key questions

Q: How should teams secure AI agents when guardrails only inspect prompts and completions?

A: Treat guardrails as one layer in a broader runtime control stack. Use them for text safety, then add tool hooks and egress inspection so HTTP, MCP, DNS, and WebSocket traffic are governed outside the model. Otherwise, the agent can pass a safe-looking conversation while still leaking data or following malicious tool instructions.

Q: What breaks when organisations rely on prompt classifiers to secure agents?

A: They lose visibility into the parts of the session that matter most for exfiltration and abuse. Prompt classifiers cannot see network payloads, encoded blobs, or resolver traffic, so an agent can move secrets out of the environment without tripping the control that appears to be in place.

Q: How do security teams know whether an AI agent control stack is actually working?

A: Look for three things: every agent has a traceable identity, permissions are narrow enough to explain in operational terms, and actions can be audited end to end. If any of those are missing, the control stack is incomplete even if the data layer uses advanced privacy techniques. Identity, scope, and logging should all line up.

Q: What is the difference between guardrails and runtime egress controls?

A: Guardrails evaluate what the model says. Runtime egress controls inspect what the agent sends over the network, including HTTP bodies, MCP frames, and DNS queries. The first is a text-safety control, while the second is a transport and exfiltration control.

Technical breakdown

Why prompt classifiers miss agent network traffic

A guardrail is typically a classifier applied to user input and model output. That makes it effective for prompt jailbreaks, tone enforcement, and PII redaction in free-form text, but blind to anything that happens after the model decides to act. When an agent issues HTTP requests, resolves DNS names, or opens WebSocket sessions, the security-relevant data is no longer in the prompt transcript. The classifier cannot inspect POST bodies, headers, or protocol frames because those artefacts live below the text layer. Practical implication: treat guardrails as a text control, not as a substitute for runtime and egress inspection. See the Agentic AI Security Guide.

Practical implication: Use guardrails for text safety, then place separate controls on the agent’s network and tool execution paths.

Why MCP tool surfaces need separate inspection

MCP changes the problem because tool descriptions, arguments, and responses become part of the agent’s operating context. That means malicious instructions can arrive through a legitimate tool channel rather than through the user prompt, and a prompt-only control will not recognise them as hostile. The same issue applies to encoded payloads hidden in otherwise ordinary-looking fields. A text classifier sees strings, not semantics about tool trust or provenance. Practical implication: inspect MCP frames as an attack surface in their own right, not as an extension of the prompt channel.

Practical implication: Scan MCP descriptions, arguments, and responses independently of prompt classification.

Why layered controls are the only workable boundary

The article’s central control lesson is that no single layer can see every agent behaviour. Guardrails cover text safety, runtime hooks can stop a dangerous tool call before execution, and egress inspection can spot exfiltration in HTTP, DNS, or MCP traffic. Each layer compensates for a blind spot in the others, which is why defence in depth is the right architecture for agents. The practical issue is not whether one control is weaker than another, but whether the organisation has a boundary at all once the agent starts acting outside the model. Practical implication: design agent security as a stack, not a single gate.

Practical implication: Map each control to the layer it can actually observe, then close the gaps between model, runtime, and network.

Threat narrative

Attacker objective: The attacker’s objective is to move data out of the agent runtime through channels the prompt classifier cannot see.

1. Entry occurs when an attacker uses a legitimate-looking prompt or tool interaction that passes the model-layer guardrail.
2. Escalation occurs when the agent follows tool instructions, makes HTTP or MCP calls, or resolves DNS names that the classifier never inspects.
3. Impact occurs when secrets or sensitive data leave the environment through POST bodies, encoded payloads, or DNS exfiltration channels without triggering the text-layer control.

Breaches seen in the wild

• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Guardrails are a text-layer control, not an agent governance boundary. Their value is real, but it is bounded by what they can inspect: prompts and completions. Once an agent starts selecting tools and emitting network traffic, the security question changes from content moderation to runtime governance. Organisations that treat prompt classifiers as the primary agent control are assuming visibility they do not actually have. The implication is that agent identity and agent activity must be governed across multiple layers, not only at the model boundary.

Agent security fails when organisations confuse message safety with session safety. A single prompt may be clean while the session still contains dangerous HTTP calls, MCP instructions, or encoded exfiltration payloads. That is a different failure mode from ordinary prompt injection because the harmful action is distributed across tool use and protocol traffic. The practical consequence is that teams need to think in terms of observable runtime behaviour, not just conversational content.

The control gap here is not missing filtering, but missing scope. Text classifiers are being asked to cover network, protocol, and tool execution risks that sit outside their design. That is why the article’s layered model matters: it names a boundary problem, not a tuning problem. Security teams should stop asking whether guardrails are sufficient and start asking which layer owns tool calls, egress inspection, and forensics.

Runtime-boundary governance is the right named concept for this problem. The article shows that the decisive security question is where the model stops and the agent’s external action begins. When that boundary is undefined, every downstream control becomes optional by accident. Practitioners should define the boundary explicitly and govern it as part of the agent’s identity and access model, not as an afterthought.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.

What this signals

Agent security now has to be designed around a runtime boundary, not a content boundary. That shift matters for teams building governance around AI agents, because the dangerous action often happens after the model has already produced an apparently safe answer. Security programmes that stop at prompt filtering will continue to miss exfiltration paths embedded in tool use and network traffic.

Layered inspection is the practical path forward. The programme implication is to align model-layer, runtime-layer, and network-layer controls so each one owns the failure mode it can actually see. That is the difference between a chatbot control set and a real agent security programme.

For practitioners

• Keep guardrails for text safety Use prompt and completion classifiers for jailbreaks, policy violations, and PII in text, but do not expect them to govern tool calls or network traffic.
• Add runtime egress inspection Inspect HTTP, HTTPS, MCP, and WebSocket traffic before it leaves the host so the agent’s POST bodies and protocol frames are visible.
• Gate tool execution at the runtime layer Use hooks or intercept logic to stop dangerous commands and high-risk tool calls before they run, rather than only classifying the surrounding text.
• Log full request-response context Capture the request, response, policy decision, and reason at the network boundary so investigations can reconstruct what the agent actually sent.
• Treat MCP metadata as a security surface Scan tool descriptions, arguments, and responses separately from prompt text because hostile instructions can arrive through tool context.

Key takeaways

• Guardrails are useful, but they only address text-layer risk and cannot govern the full runtime behaviour of agents.
• The article’s evidence shows that HTTP bodies, MCP metadata, and DNS traffic can all carry harmful payloads outside classifier visibility.
• Security teams need layered controls that combine guardrails, runtime hooks, and egress inspection if they want a credible agent boundary.

Related NHI Mgmt Group resources: Agentic AI Security Guide · AI Security Platform Buyer's Guide · AI Guardrails and AI Firewalls Guide

Key terms

• Guardrails: Guardrails are policy controls that inspect prompts and model outputs against defined safety, privacy, and compliance rules. In AI operations, they reduce harmful language and disclosure risk, but they do not replace entitlement management, logging, or identity governance for the systems that call the model.
• Runtime boundary: The point at which an identity's permissions, execution context, and observable behaviour are contained for policy purposes. In agentic systems, runtime boundaries matter because they determine whether the organisation can explain, audit, and limit what the agent did after execution begins.
• Egress Inspection: Egress inspection is the monitoring and filtering of outbound traffic before data leaves an agent host or runtime. It can see HTTP bodies, MCP frames, DNS queries, and similar artefacts that prompt classifiers cannot inspect, making it a core control for agent exfiltration risk.
• Tool Surface: The tool surface is the set of commands, APIs and connected services an AI agent can invoke at runtime. It is a governance boundary because each tool expands what the agent can do, and therefore expands what an attacker can abuse if they gain control of the runtime.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.