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.
Why prompt-only guardrails miss the real agent control surface
Prompt and completion filters are useful for text safety, but they do not govern what an agent actually does outside the model. Once an agent can call tools, open network connections, or move data through connectors, the practical control point shifts to runtime enforcement on those actions, not just the conversation.
The gap is that a model can produce harmless-looking language while still being allowed to send an HTTP request, open a WebSocket session, resolve a DNS name, or invoke an MCP tool. That is why teams need to treat the model as one decision source, not the enforcement boundary, and pair it with external policy checks on the agent’s real requests.
For the same reason, the right question is not only “was the prompt safe?” but “was the action safe, authorised, and observable?” A control stack that cannot inspect outbound traffic or tool execution can miss data exfiltration, covert command paths, and malicious tool instructions that never look suspicious in natural language.
What runtime controls need to cover besides the model
Effective agent security needs control points around tool invocation, network egress, and session context. That means checking what the agent is trying to access, where it is trying to send data, and whether that request is consistent with the agent’s approved scope and current task.
Tool hooks matter because they let you enforce policy at the moment of action, before a connector or plugin performs work on the agent’s behalf. Egress inspection matters because many failures show up as ordinary outbound traffic rather than as obviously malicious text, especially when the agent is induced to leak secrets or pass data to an attacker-controlled endpoint.
This is also where protocol detail matters. HTTP is only one path, and mature deployments should consider DNS tunnelling, WebSocket channels, and MCP traffic as part of the same enforcement problem. If these paths are not governed outside the model, prompt safety can give a false sense of protection.
When teams build this layer well, they get a narrower blast radius, clearer attribution, and a place to stop an unsafe action even if the model was manipulated. NHIMG’s AI Agent Authorisation Guide is useful here because it frames least privilege, per-action policy, and human approval as runtime decisions rather than static policy statements, and MCP Security Guide is a practical reference for governing tool-facing traffic and token passthrough risks.
Why this is really an authorization and egress problem
The main failure mode is boundary confusion: teams assume the LLM’s response is the control decision, when the real security decision happens at the tool, connector, or network layer. That creates a path for prompt injection, data leakage, and over-broad action execution even when the visible chat transcript looks benign.
In practice, that means a safe completion does not prove safe behaviour. If the agent can still reach sensitive systems, forward secrets, or execute instructions from untrusted content, then the model has become a policy oracle while the operational guardrail is missing.
For this reason, teams should also think about identity and privilege at the agent layer. Zero Trust for AI Agents and Agentic AI Security Guide both reinforce the same operational point: verify the principal, reduce standing access, and assume that prompt content alone is not a trustworthy proxy for intent.
Risk and Threat Considerations
Prompt-only guardrails create a blind spot because attackers can target the agent’s actions rather than its wording. A model can be steered into calling a tool, making an outbound request, or passing along sensitive context while still producing text that appears compliant.
Failure mechanism: The environment trusts prompt inspection more than runtime enforcement, so malicious instructions survive inside approved-looking output and become dangerous only when the agent executes a tool call or egresses data.
Impact: This can lead to secret exposure, unauthorised system interaction, covert exfiltration, and weak incident visibility because the transcript looks normal even when the underlying action path is not.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent actions can exceed visible prompt safety through abused authority. |
| ASI02 — Tool Misuse | The question is about unsafe tool execution despite safe-looking text. | |
| ASI07 — Insecure Inter-Agent Communication | MCP and WebSocket paths create untrusted communication channels needing control. | |
| Recommendation — Enforce per-action authorisation for every agent tool call and external request. Restrict and validate each tool invocation before the agent can execute it. Apply policy and monitoring to agent communication channels outside the model. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agents need constrained permissions so safe prompts cannot trigger broad access. |
| IA-5 — Authenticator Management | Runtime access to tools and services depends on controlled credential use and rotation. | |
| Recommendation — Limit each agent to the minimum permissions needed for its current task. Manage and rotate agent credentials so tool access stays bounded and accountable. | ||
Practitioner Guidance
What to prioritise: Put the first control boundary on the action path, not the chat path. If an agent can invoke tools or leave the network, require policy checks at those choke points before any external side effect occurs.
What to verify: Confirm that your controls cover non-text channels, including HTTP, DNS, WebSocket, and MCP flows, and that denied actions are logged with enough context to reconstruct the request path and the calling principal.
Decision rule: If a control only inspects prompts and completions, treat it as a safety aid, not a security boundary. If the agent can affect production systems, sensitive data, or external endpoints, require runtime enforcement and egress inspection before deployment.
Practitioner takeaway: The safest agent is not the one that says the right thing, it is the one whose real permissions, tool use, and outbound traffic are constrained outside the model.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org