Kong AI Gateway integration shifts AI traffic security to the edge

At a glance

What this is: This is an analysis of Kong's AI Gateway integration with Prisma AIRS, which moves AI security checks to the gateway edge for prompts, responses, and MCP tool calls.

Why it matters: It matters because IAM, PAM, and AI governance teams now have to treat gateway policy as part of identity control for AI traffic, not just a network or application concern.

Context

AI gateway security is the practice of enforcing policy on AI traffic as it moves between applications, models, and tools. In this article, Kong frames the gateway as the control point where prompt injection, data leakage, and unsafe output filtering can be applied before or during model interaction.

The governance issue is broader than content filtering. Once Model Context Protocol traffic, AI prompts, and tool calls all traverse the same edge, identity, authorisation, and inspection controls have to operate at runtime speed and across both inbound and outbound AI flows.

This is a product integration article, not a breach story. The operational question is how to place security controls so that AI systems can be governed without forcing each application team to build its own bespoke policy layer.

Key questions

Q: How should security teams handle prompt injection in AI systems?

A: Treat prompt injection as an authorisation problem, not only a content problem. Validate user input, monitor for override patterns, and block any prompt that tries to change model policy, exfiltrate data, or trigger sensitive actions. The safest design is one where untrusted prompts cannot directly reach code execution, production data, or privileged tools without policy checks.

Q: Why do MCP tools need explicit authorisation controls?

A: Because MCP turns tools into callable capabilities, and capability exposure is a privilege problem, not just an integration pattern. Teams need scope-based authorisation, per-tool policy, and audit records so a model cannot invoke functions outside its intended role.

Q: What breaks when AI security only inspects user inputs?

A: The response path remains uncontrolled, which means unsafe output, malicious code, or sensitive data can leave the trust boundary even when the inbound prompt looked safe. Bidirectional inspection is necessary because the model can create the risk after the request is accepted.

Q: How should teams decide whether to secure AI traffic in the gateway or in each application?

A: Use the gateway when multiple applications, models, or tools share the same AI traffic patterns and policy decisions need to stay consistent. Use per-application controls only for narrowly scoped exceptions. A central gateway is the better fit when identity, safety, and audit requirements must apply everywhere.

Technical breakdown

Why the AI gateway becomes the enforcement point

An AI gateway sits between applications and models, so it can see requests before they reach an LLM and responses before they reach users or downstream systems. That position matters because prompt injection, unsafe outputs, and sensitive data leakage are not isolated events. They are traffic problems that emerge from how prompts, responses, and tool calls move through the stack. Kong also extends this model to MCP, where tool exposure and tool invocation become part of the same inspection path. The core technical shift is that policy is no longer tied only to the application or the model. It is enforced at the traffic layer where AI decisions become visible.

Practical implication: treat the gateway as a policy enforcement layer for AI traffic, not just a routing tier.

How bidirectional inspection changes AI security

Bidirectional inspection means examining both the prompt going into the model and the response coming back out. That matters because threats do not only arrive at the front door. A compromised or manipulated model can emit harmful content, malicious code, or phishing-style instructions that become security liabilities downstream. By scanning both directions, gateway controls can block or redact sensitive material before it leaves the trust boundary. This is especially relevant when the same session carries customer data, proprietary information, and tool invocation. In practice, bidirectional inspection narrows the blast radius of a bad prompt or unsafe model output, but only if policy execution is fast enough to keep pace with runtime traffic.

Practical implication: enforce controls on both ingress and egress AI traffic so the response path is not an unchecked exfiltration channel.

MCP proxying and OAuth2 for tool access

MCP changes the security problem because the model can reach tools, not just text completions. Kong describes an AI MCP Proxy that converts APIs into MCP tools, plus an AI MCP OAuth2 capability for authenticating MCP servers. That means tool access can be mediated through familiar identity patterns rather than left as implicit capability exposure. The technical concern is not only whether a tool exists, but whether the agent or model is authorised to invoke it, under what policy, and with what scope. For IAM practitioners, that turns MCP from a protocol question into a delegated access-control question that has to be governed like any other privileged integration.

Practical implication: map MCP tool access to explicit authorisation and session policy instead of assuming tool availability is safe by default.

NHI Mgmt Group analysis

Edge enforcement is becoming the new AI governance boundary: once prompts, responses, and tool calls all flow through a gateway, policy has to operate where traffic is still inspectable. That shifts AI security away from application-by-application controls and toward centralised runtime governance. The practical consequence is that identity and data protections become part of the same enforcement plane for AI systems.

MCP makes capability exposure a governance problem, not just a protocol problem: the moment a model can invoke tools, the question is no longer only whether the tool exists, but whether the caller is authorised for that specific action. Kong's proxy and OAuth2 pattern shows why AI tooling now intersects with access governance, delegated authority, and auditability. Practitioners should treat MCP tool access as privileged interaction, not informal integration.

Prompt injection and unsafe output filtering expose a runtime trust gap: traditional controls assume the application can trust the model boundary, but AI traffic can carry adversarial instructions in and harmful content out. Runtime trust gap: the boundary itself has become dynamic, so security must evaluate each exchange, not just the model deployment. IAM and security teams should align policy enforcement with the traffic path, not the development lifecycle alone.

Centralised policy is useful only if it matches the speed of AI execution: the article's core implication is that governance no longer fails only from missing policy, but from controls that cannot inspect and decide quickly enough. That is a material change for AI security programmes because latency, not just coverage, becomes a governance constraint. Teams need a control model that can keep pace with the runtime behaviour of AI systems.

AI gateway security is converging with identity governance: the more AI systems call models and tools through shared gateways, the more identity, authorisation, and content safety depend on one another. That convergence will push practitioners to unify AI policy, API policy, and identity controls instead of managing them as separate problem spaces. The governance model is moving toward one edge, one policy plane, and one audit path.

What this signals

Runtime inspection is becoming the governing principle for AI traffic: once prompt injection, unsafe outputs, and tool invocation are handled at the edge, the policy problem moves from model selection to runtime control. That is a different operating model for IAM and security teams because the control point sits in the traffic path rather than in a downstream review process.

AI and API governance are starting to merge: the same edge that manages API traffic is increasingly expected to manage AI prompts, responses, and MCP tools. For practitioners, that means policy design has to account for identity, content safety, and auditability in one place instead of across disconnected controls.

For practitioners

• Define the gateway as an AI policy boundary Map prompt inspection, response inspection, and tool-call control to one enforcement point so security decisions happen before model execution and before downstream exposure.
• Classify MCP tools as governed capabilities Inventory which tools an agent or model can reach through MCP and require explicit authorisation rules for each capability, not a blanket assumption of access.
• Add bidirectional content controls Block or redact sensitive data and unsafe outputs on both ingress and egress so the response path cannot become an unmonitored leak channel.
• Align AI traffic policy with IAM roles and scopes Tie model and tool usage to the same entitlement logic used for other privileged access paths, including audit trails that show who or what invoked each action.

Key takeaways

• AI gateway enforcement is shifting AI security from application-specific checks to a central control point for prompts, responses, and tool calls.
• The article shows that prompt injection, data leakage, and unsafe outputs are now treated as runtime traffic risks rather than isolated model issues.
• Practitioners should align AI gateway policy with IAM and audit controls so model access, tool access, and content safety are governed together.

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.
• 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.
• MCP Tool Access: MCP Tool Access is the permission an AI agent uses to reach external tools, data sources, or services through the Model Context Protocol. It defines what the agent can call, read, or change, and under what conditions. In practice, it is a control point for limiting agent actions, auditing usage, and reducing unsafe tool exposure.
• Bidirectional Inspection: Bidirectional inspection means examining both prompts sent to an AI system and the responses it produces. This is essential when outputs can trigger follow-on actions, leak sensitive data, or carry instructions that affect downstream systems, users, or automated workflows.

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.