By NHI Mgmt Group Editorial TeamPublished 2026-02-09Domain: Agentic AI & NHIsSource: Kong

TL;DR: Inline inspection, prompt-injection blocking, and data-loss controls are now being applied at the API gateway layer for AI and MCP traffic, according to Kong. The governance question is no longer whether AI needs protection, but which identity and policy controls can operate fast enough to keep model inputs, outputs, and tool calls within acceptable bounds.


At a glance

What this is: This is Kong's analysis of integrating Prisma AIRS with Kong AI Gateway to enforce inline security controls for prompts, responses, and tool calls.

Why it matters: It matters because IAM and security teams need a control point that can govern AI traffic, MCP access, and data leakage without breaking application flow.

👉 Read Kong's analysis of Prisma AIRS integration with Kong AI Gateway


Context

AI gateway security is the problem space here: AI traffic is no longer just user input and API responses, it now includes model prompts, model outputs, and tool invocation paths that can carry sensitive data or unsafe instructions. When those flows cross shared gateways, the identity question becomes how to enforce policy at runtime without turning AI delivery into a manual exception process.

For IAM and security programmes, the operational gap is that traditional API controls were built for bounded request and response patterns, not for model-mediated interactions that can amplify an unsafe input into downstream action. Kong's integration sits in that gap, but the underlying issue is broader than one vendor stack: organisations need a repeatable way to govern AI requests as first-class identity-bearing traffic.

That makes this an AI gateway and agent governance topic, not just a content-safety topic. The same enforcement logic that blocks prompt injection also has to account for tool access, redaction, and response hygiene across applications, agents, and MCP flows.


Key questions

Q: How should security teams control AI gateway traffic without slowing down applications?

A: Use central policy enforcement at the gateway, then apply narrow controls for prompts, responses, and tool calls based on sensitivity. That lets teams standardise inspection and logging while avoiding per-application security rewrites. The practical aim is to preserve application flow while ensuring model-mediated traffic still passes through a consistent decision point.

Q: Why do AI agents and MCP tools create new governance problems for IAM teams?

A: Because they expand the number of identity-bearing actions that happen at runtime. Once models can call tools, IAM must govern not only authentication but also tool scope, approval boundaries, and auditability. Without those controls, the organisation loses visibility into what the model was allowed to access and what it actually used.

Q: What do organisations get wrong about prompt injection prevention?

A: They often focus only on blocking malicious input and ignore unsafe output and downstream tool use. Prompt injection is a control failure, but the broader issue is that the model can be steered into actions that escape the original security intent. Effective governance has to cover ingress, egress, and tool mediation together.

Q: Which governance frameworks should teams use for AI gateway policy?

A: Use identity and zero-trust frameworks for access scope, and pair them with AI risk governance where model behaviour is involved. For gateway policy, the relevant question is whether the control can prove who approved access, what was inspected, and how exceptions are tracked. That is what makes the control auditable.


Technical breakdown

How AI gateway policy enforcement works at runtime

An AI gateway sits between applications and model endpoints, intercepting prompts before they reach the model and responses before they reach the caller. That position matters because it gives the gateway a place to inspect, block, redact, or rate-limit traffic without changing every application individually. In this architecture, policy can be applied centrally while still supporting multiple models, multiple apps, and multiple tool paths. The Kong article describes plugins for prompt templating, semantic guards, caching, rate limiting, and MCP proxying, which together show how gateway policy shifts AI security from point controls to traffic controls.

Practical implication: treat the gateway as a policy enforcement plane, not just a transport layer.

Prompt injection, data leakage, and unsafe output filtering

Prompt injection is the manipulation of model behaviour through crafted input, often to override system instructions or induce unsafe actions. Data leakage happens when sensitive content appears in prompts or model outputs and escapes into logs, downstream systems, or user-facing responses. Unsafe output filtering adds a final control to catch harmful text or malicious code before it reaches users. The key architectural point is that these threats are bidirectional. You need controls that inspect both inbound prompts and outbound responses because either direction can carry the security failure.

Practical implication: design controls for both ingress and egress, not only for user-submitted prompts.

MCP proxying and OAuth2 for tool access control

Model Context Protocol expands model reach by letting agents call tools through a standardised interface. That increases utility, but it also increases the blast radius if tool access is unrestricted or poorly authenticated. Kong's article highlights an MCP proxy and MCP OAuth2, which signals the need to authenticate and mediate tool access rather than exposing tools directly to every model or agent session. In practice, this means gateways can become the control point for tool brokering, scope restriction, and policy checks before a model is allowed to invoke external systems.

Practical implication: place authentication and authorisation in front of MCP tools, not inside each downstream tool.


NHI Mgmt Group analysis

AI gateway security is becoming an identity control plane, not a content filter. The important shift in this article is that prompts, responses, and tool calls are being governed as runtime traffic that can carry identity risk. That puts the gateway into the same strategic category as IAM policy enforcement, because it decides which AI interactions are allowed to continue. Practitioners should treat this as a control-plane problem, not a model-safety add-on.

Prompt injection is only part of the issue, because the real exposure is AI-mediated privilege use. Once an AI system can call tools, redact data, or return executable output, the control objective is no longer simply blocking bad text. It becomes governing what the model is permitted to see, say, and do across applications and agents. That means AI security has to align with identity scope, tool scope, and output trust at the same time.

Tool access without gateway-mediated policy creates a fragmented trust model. MCP expands capability by standardising how models reach tools, but it also makes unaudited tool exposure easier to repeat across systems. When those paths are not brokered centrally, security teams inherit inconsistent authentication, inconsistent authorisation, and inconsistent logging. Practitioners should view MCP as a governance multiplier, not just an integration convenience.

Centralised inspection only works if it is tied to lifecycle and accountability controls. A gateway can block bad traffic, but it cannot by itself answer who approved a model's access, who owns its policy scope, or when that access should be revoked. That leaves a governance gap unless gateway rules are connected to identity lifecycle processes and review ownership. The implication is that AI traffic control must sit inside a broader identity operating model.

AI gateway policy will increasingly converge with workload identity and NHI governance. The article's architecture points toward a future where models, agents, and tool proxies are governed like other non-human identities: with scoped access, explicit policy, and auditability. That convergence matters because security teams cannot maintain separate rulebooks for apps, service identities, and AI agents forever. Practitioners should align AI gateway design with their broader NHI and workload identity strategy.

From our research:

  • 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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.
  • For a broader control model, see OWASP Agentic AI Top 10 for the runtime risks that gateway policy has to absorb.

What this signals

Prompt and tool mediation will become the default boundary for AI governance. As organisations move AI traffic through shared gateways, the practical control surface shifts from application code into runtime policy. That means teams should expect more investment in inspection, redaction, and brokered tool access, especially where model actions can trigger downstream business processes.

With 98% of companies planning to deploy even more AI agents within the next 12 months, the governance gap is heading the wrong way unless policy ownership is formalised now. Teams that already use NHI lifecycle thinking can adapt faster because the same questions apply: who owns access, what is in scope, and when does it get removed?

The broader signal is that AI security and identity governance are converging around policy enforcement points. Organisations that can connect gateway rules to lifecycle review, audit evidence, and privilege boundaries will be better positioned to manage agent traffic without creating a new blind spot.


For practitioners

  • Define gateway-level policy for AI prompts and responses Classify which inputs, outputs, and tool calls must be inspected, redacted, blocked, or rate-limited before they reach model endpoints or users.
  • Broker MCP tool access through central authorisation Require authentication, scope checks, and audit logging before any agent or model can invoke external tools through MCP.
  • Map AI traffic controls to identity ownership Assign policy ownership, approval responsibility, and review cadence for each AI application, agent, and model route so enforcement is traceable.
  • Separate prompt filtering from output governance Use different checks for inbound prompts and outbound responses so harmful content, redaction failures, and unsafe code paths are handled independently.

Key takeaways

  • AI gateway integration is really about moving policy enforcement closer to where model risk actually appears: at prompts, outputs, and tool calls.
  • The main governance challenge is not only prompt injection but also scope, auditability, and tool mediation across AI-driven traffic.
  • Security teams should connect gateway controls to identity ownership and lifecycle review, or they will create another unmanaged control layer.

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 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Prompt injection and tool abuse are central to this AI gateway integration.
NIST AI RMFThe article is about governing AI risk, accountability, and runtime controls.
NIST Zero Trust (SP 800-207)PR.AC-4Gateway enforcement aligns with least-privilege access to tools and services.

Use gateway controls to constrain prompts, tool calls, and agent behaviour before they reach production.


Key terms

  • AI Gateway: An AI gateway is a policy enforcement layer that sits between applications and model endpoints. It inspects prompts, responses, and tool calls so organisations can apply access rules, data controls, and logging consistently across AI traffic.
  • Prompt Injection: Prompt injection is a technique that manipulates a model through crafted input so it ignores intended instructions or performs unsafe actions. In enterprise settings, it matters because the model may follow attacker-supplied direction as if it were legitimate user intent.
  • Model Context Protocol: Model Context Protocol is a standard for connecting models and agents to tools and data sources. It increases interoperability, but it also expands the governance burden because tool access, authentication, and logging must be controlled wherever MCP is exposed.
  • Bidirectional Inspection: Bidirectional inspection means checking both inbound prompts and outbound responses. It is useful in AI security because threats can enter through user input and sensitive data or malicious output can leave through the same session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: Secure AI at Scale, Prisma AIRS and Kong AI Gateway Now Integrated. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-02-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org