By NHI Mgmt Group Editorial TeamBased on Pillar Security: “Pillar + TrueFoundry: Runtime AI Protection, Built Into the Gateway” (April 24, 2026)

TL;DR: Its runtime AI protection is now integrated into TrueFoundry’s AI Gateway, letting every request and response be inspected in real time for prompt injection, jailbreaks, sensitive data, and evasion across model calls, according to Pillar Security. For agentic workflows, session-aware enforcement matters because single-turn scanning misses multi-step abuse and tool-chained exfiltration.


At a glance

What this is: This is a product integration that brings runtime AI guardrails into the gateway layer, with session-aware inspection of requests and responses for prompt injection, jailbreaks, sensitive data, and evasion.

Why it matters: It matters because IAM and security teams need enforcement that follows the AI session, not just the individual prompt, when agents chain tools, carry state, and expose sensitive data across models.


Context

AI gateway security is the control point that sits between applications and the models they call, while runtime guardrails inspect prompts and outputs before unsafe content reaches users or downstream systems. That combination is increasingly important because production AI now spans multiple models, providers, and execution paths, and the risk no longer lives in a single prompt.

For agentic AI, the governance problem changes again. Agents retrieve content, call tools, and maintain state across many turns, which means the dangerous instruction is often embedded somewhere other than the current message. Session-aware inspection is therefore a governance requirement for autonomous or semi-autonomous workflows, not a nice-to-have extra layer.


Key questions

Q: How should security teams implement runtime guardrails for AI agents and MCP traffic in production?

A: Security teams should place guardrails at the gateway or control plane where model, tool, and MCP traffic already converges. That lets them inspect prompts, responses, tool calls, and tool output before action is taken. The goal is to block unsafe execution in real time, not after the fact, while keeping policy centralized and consistent across teams, models, and agent workflows.

Q: Why do agentic AI security workflows need identity and access controls?

A: Because the model itself is not the whole system. The surrounding harness uses service accounts, API keys, tokens, and tool permissions to act, and those identities can expand risk if they are over-privileged or poorly scoped. Identity controls decide what the system can touch, while validation decides what its output means.

Q: What breaks when AI protection only scans one message at a time?

A: Single-message scanning breaks when the attack is distributed across the conversation or hidden inside retrieved content. The result is false confidence: the current prompt looks safe while the session as a whole is being steered toward sensitive data exposure or unsafe model behaviour.

Q: How do security teams govern prompt injection, data leakage, and unsafe output together?

A: They should treat these as one runtime enforcement problem, not three disconnected controls. A practical programme inspects inputs and outputs, blocks policy violations before they reach users, and retains logs for audit and incident response across the same control boundary.


How it works in practice

Why gateway-layer inspection changes the control boundary

An AI gateway centralises routing, policy enforcement, and telemetry for requests sent to multiple models and providers. When runtime guardrails are attached at that layer, the control boundary moves from the application code path to the shared traffic path, which makes enforcement more consistent across teams and workloads. That matters because security logic buried in app code fragments quickly, especially when different teams call different models or host them in different environments. Gateway-layer inspection also creates a common audit point for both inbound prompts and outbound completions.

Practical implication: place policy enforcement where all model traffic converges, not inside each application integration.

How session-aware detection differs from single-turn scanning

Single-turn scanning evaluates each message in isolation. That works for simple chat use cases, but it fails when the attack is distributed across a conversation, a retrieved document, or a tool response. Session-aware detection keeps the conversation context open long enough to spot indirect prompt injection, obfuscated jailbreaks, or data exfiltration attempts that only become obvious when earlier turns are included. In production AI, the adversary often hides in context rather than in the current input.

Practical implication: assess runtime controls for full-session context handling, not just per-message classification.

Why output scanning is part of the identity and data control plane

Runtime protection is not only about blocking malicious prompts. It also has to inspect model output before it reaches a user or an application because sensitive data, credentials, and unsafe instructions can be generated or repeated on the way out. In practice, that makes the gateway part of the control plane for data loss prevention, policy enforcement, and auditability. Logging both verdicts and decisions supports incident response and helps teams tune policies without losing visibility into what was blocked or allowed.

Practical implication: treat model output scanning as a governance control for sensitive data exposure, not just a moderation feature.


NHI Mgmt Group analysis

Runtime guardrails belong at the shared control plane, not only in application code: When AI workloads span multiple models, providers, and teams, distributed application-level checks fragment too quickly to be relied on. A gateway-mediated policy layer gives security teams one enforcement point for both inbound prompts and outbound responses. The practitioner conclusion is simple: centralise the inspection point where model traffic already converges.

Session context is now the real unit of trust: Single-turn moderation assumes the risk is visible in one message, but agentic workflows carry state across turns and tools. That assumption fails as soon as a malicious instruction is split across retrieval, prompt, and response flow. The implication is that AI governance has to evaluate conversation state, not just individual text events.

AI data protection and model safety are the same operational problem at runtime: Prompt injection, jailbreaks, secrets exposure, and content moderation are not separate silos once the model is in production. They are different manifestations of the same need to control what enters, what is generated, and what is logged. The named concept here is session-aware AI enforcement: policy that follows the entire exchange rather than one prompt. Practitioners should treat it as a baseline control for production AI.

Auditability is part of enforcement, not a separate afterthought: Logging scan decisions, blocked events, and policy outcomes creates the evidence needed for incident response and tuning. Without that record, teams cannot tell whether a guardrail blocked a true threat or merely masked a control gap. The practitioner conclusion is to tie runtime enforcement to traceable decision logging from day one.

Agentic AI breaks the assumptions behind single-message moderation: The control assumption was designed for discrete interactions. That assumption fails when the actor carries state, calls tools, and can be manipulated over multiple turns before any harmful output appears. The implication is that security teams must redesign policy around session continuity, not message isolation.

From our research library:

What this signals

Session-aware AI enforcement: Production AI controls are moving from prompt-level moderation to conversation-level governance because agentic systems carry state across turns and tools. That shift matters for any team that has already centralised model routing in an AI gateway, because the gateway is becoming the most practical place to make policy stick.

The governance test is no longer whether a model can be scanned, but whether the control can see enough context to detect injection, evasion, and leakage before an application consumes the output. Teams that still treat scanning as a point-in-time check will miss the operational difference between chat and agentic workflows.


For practitioners

  • Define a gateway enforcement boundary Route AI traffic through a shared gateway so policy checks happen before prompts reach a model and before completions return to the application.
  • Require session-aware inspection Verify that runtime controls can evaluate the full conversation and tool context, not just the current turn or a single completion.
  • Block sensitive data at both edges Scan prompts and outputs for secrets, API keys, credentials, PCI data, and PII so leakage is stopped whether it enters or leaves the model path.
  • Separate policies by risk tier Use stricter rules for production agents and looser rules for internal prototyping so experimentation does not inherit the same policy profile as customer-facing workloads.
  • Log verdicts with request traces Keep allow and block decisions alongside request tracing so incident response can reconstruct how a model call was handled.

Key takeaways

  • Runtime AI guardrails are shifting into the gateway layer because production model traffic needs one enforcement point across models, providers, and applications.
  • Agentic workflows make single-turn scanning insufficient because the real risk emerges across session context, tool calls, and multi-turn manipulation.
  • Security teams should align inspection, logging, and policy enforcement so prompt injection, data leakage, and unsafe output are handled in one operational control.

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 and OWASP API Security Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI02 — Tool MisuseGateway guardrails are meant to stop agent workflows from abusing tools and downstream actions.
ASI06 — Memory & Context PoisoningThe article focuses on session-aware detection of injected context across turns and retrieved content.
Recommendation — Apply ASI02 controls to inspect agent tool calls and block unsafe actions at the gateway boundary. Guard against ASI06 by validating conversation context before it can steer model decisions.
NIST AI RMFMANAGE — AI Risk ManagementRuntime guardrails and audit logging map to operational AI risk controls and ongoing oversight.
Recommendation — Use MANAGE to tie runtime policy enforcement to logging, audit, and continuous oversight.
NIST CSF 2.0PR.DS-10 — Data in Transit Is ProtectedPrompts and outputs are protected as they move through the gateway and model path.
Recommendation — Apply PR.DS-10 to protect sensitive AI traffic as it traverses the gateway and model boundary.
OWASP API Security Top 10API8 — Security MisconfigurationMisconfigured gateway policies can leave model routes insufficiently protected.
Recommendation — Review API8-style misconfiguration risk across gateway routes, scopes, and policy profiles.

Key terms

  • AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
  • Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
  • Session-aware detection: Session-aware detection evaluates the full conversation or interaction sequence instead of judging each prompt in isolation. It is essential for agentic and multi-turn workflows because malicious intent can be spread across turns, retrieved content, or tool responses that look harmless on their own.
  • Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

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 identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org