Notifications
Clear all
Topic starter
10/06/2026 12:04 am
TL;DR: Pillar says its runtime AI protection can be wired into TrueFoundry’s AI Gateway so every request and response is inspected in real time for prompt injection, jailbreaks, sensitive data, and evasion, with verdicts logged for audit and incident response. The control matters because agentic workflows break single-turn scanning assumptions and need session-aware enforcement.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should security teams govern AI requests at the gateway level?
A: Security teams should enforce prompt and response checks at a shared gateway so policy is applied before model output reaches applications.
Q: Why do agentic AI workflows need session-aware guardrails?
A: Agentic workflows chain tool calls, retrieval, and state across multiple turns, so a single prompt rarely captures the full risk.
Q: What do security teams get wrong about prompt injection controls?
A: They often treat prompt injection as a message-level content problem, when the real issue is governance across the whole interaction.
Practitioner guidance
- Place guardrails at the gateway boundary Route model traffic through a shared control point so prompts and responses are inspected before they reach the application or user.
- Require full-session inspection for agentic workflows Treat multi-turn conversation state, retrieved content, and tool outputs as one governed session.
- Log scans, verdicts, and responses for audit Preserve the request path, policy decision, and blocked or allowed outcome so security and compliance teams can reconstruct what happened after an incident.
What's in the full announcement
Pillar's full blog post covers the operational detail this post intentionally leaves for the source:
- How to configure the Guardrails Group in TrueFoundry for specific models, routes, teams, and environments
- The exact request and response flow used to allow, block, or redacted AI traffic at runtime
- How the integration logs scans and verdicts for audit, incident response, and policy tuning
- What teams can switch on on day one without changing application code
👉 Read Pillar Security's post on runtime AI protection in the TrueFoundry gateway →
Runtime AI guardrails in the gateway: what changes for teams?
Explore further
12/06/2026 3:16 am
Runtime AI protection is becoming a gateway function, not an application afterthought. The integration pattern matters because it places inspection at the traffic layer where model access is mediated, rather than asking each development team to recreate the same guardrails. That shifts AI security from scattered code controls to a policy boundary that can be governed consistently. For practitioners, the implication is that gateway placement is now part of the identity and access design, not just an AI tooling decision.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How can teams balance AI protection with rollout speed?
A: Use scoped policy profiles so production routes receive strict controls while internal prototypes can start with lighter guardrails. That lets teams deploy protection without forcing every environment into the same risk posture or slowing initial adoption.
👉 Read our full editorial: Pillar and TrueFoundry tie runtime guardrails to the AI gateway
