Building prompt injection detection into Kong AI Gateway: build vs buy

Where detection fits in the request path

NIST defines prompt injection as an attack that exploits the concatenation of untrusted input with a prompt constructed by a higher-trust party, such as the application designer. OWASP adds the underlying problem: an LLM does not enforce a boundary between instructions and data in a prompt. Because the model cannot be relied on to separate the two, inspection has to happen outside it.

A gateway is a natural place for that inspection. Every request to a model passes through it, so a plugin can examine the assembled prompt, reach a decision and either forward the request or stop it. This gives platform teams one consistent enforcement point instead of detection logic scattered across applications.

It helps to name the three control points a gateway deployment can use. Input detection evaluates the prompt before the model call. Output monitoring looks at responses for signs that an injection succeeded, and OWASP treats this as a distinct control from input detection. Action control applies when the model's output triggers a tool call, an agent step or a write to another system. A gateway sees the first two directly. The third often happens elsewhere.

No mitigation eliminates prompt injection. OWASP's guidance is to reduce impact, reduce attack surface and increase detection. Detection in the gateway is one layer in that approach, alongside privilege minimization, segregation of untrusted content and prompt hardening.

What a custom detection plugin involves

Building detection into the gateway is more than writing a filter. The work divides into components that each need an owner, and most of the cost sits in the last three.

• Detector selection: Choose between pattern matching, semantic similarity, a trained classifier or an LLM-based judge. NIST documents detection schemes and LLM-based defenses for both direct and indirect injection. Each option shifts effort between development, hosting and runtime cost.
• Plugin integration: Write a custom gateway plugin that extracts the prompt, calls the detector, handles timeouts and returns a decision. Decide whether a detector failure fails open or fails closed.
• Latency budget: Detection runs in the synchronous request path. A model-based detector adds a network hop or inference step, so set a budget per route and measure it under production load.
• Tuning for false positives and negatives: Blocking legitimate requests frustrates users, and missing attacks defeats the purpose. Review decisions regularly and keep a test set of paraphrased, multilingual, encoded and indirect payloads.
• Enforcement logic: Map detector output to an action: allow, redact, block or escalate. The mapping usually needs to vary by route, application and data sensitivity.
• Ongoing maintenance: Attack techniques change, so patterns, models and test sets need scheduled updates and penetration testing that treats the model as an untrusted user.

Limits of pattern-based and gateway-native filtering

Built-in gateway plugins that filter on patterns are quick to deploy and predictable to operate. They are a reasonable first layer, and for some low-risk routes they may be enough. The limits are well documented, though.

OWASP lists missed injections as a core limit of pattern screening. A paraphrase such as "disregard prior directions" contains none of the listed patterns, and neither do payloads written in another language or encoded. An attacker can rephrase an instruction in many ways that a deny list will not match. Screening also does not stop an injection it fails to detect.

Keyword logic has a second weakness. A study cited by OWASP examined 196,682 resumes from one hiring platform and found that more than 90% of hidden prompts contained no explicit instruction. Detection built around instruction keywords may miss that kind of content entirely.

The third limit is scope. Input screening at the gateway does not cover content that arrives through other channels. Indirect injection through retrieved documents, third-party content and tool paths needs separate controls. A semantic or model-based detector can narrow the paraphrase gap, but it does not change this boundary, and it brings the tuning and latency work described above.

Whichever route you choose, test the detector against paraphrased, multilingual and encoded payloads and against indirect content before relying on it.

A decision framework for build versus buy

Both options are legitimate. The right answer depends on how much detection engineering your team wants to own and how far the control needs to reach. Evaluate each criterion against your own routes and risk tolerance.

• Detection coverage: Build: you choose and extend detectors, and you own testing against paraphrased, multilingual, encoded and indirect payloads. Buy: ask what goes beyond pattern matching and how the vendor tests it.
• Latency: Build: you set and measure the budget for each detector. Buy: confirm where inspection runs and what it adds to the request path.
• Tuning and maintenance ownership: Build: your team reviews false positives and negatives and updates detection as techniques change. Buy: clarify what the vendor updates and what remains your responsibility.
• Enforcement actions: Build: you implement allow, redact, block and escalate yourself. Buy: check that actions can be set by operation, target, arguments and caller authority, not only prompt content.
• Evidence output: Build: you design the decision records and redaction. Buy: check what is produced, in what form, and how prompt content is minimized before storage.
• Deployment model: Build: runs where you deploy it. Buy: confirm whether the product runs in your cloud, how data residency and retention are configured, and what leaves your boundary.

Enforcement actions and evidence

Detection only matters if it leads to a defined action. Four outcomes cover most cases. Allow passes the request, usually with a record. Redact removes sensitive or suspect content and forwards the rest. Block stops the request. Escalate holds the request for human approval. OWASP notes that an agent that asks before sending, deleting or modifying creates a checkpoint that injection alone cannot bypass, which is why escalation matters for consequential actions.

OWASP also advises deciding on agent actions by the proposed operation, target, arguments and the caller's authority. Keyword counts in the user's prompt do not establish the risk of an action. A detector score is therefore one input to the decision, not the decision itself.

For auditors, each decision needs durable evidence. OWASP Cornucopia recommends logging only the minimum AI interaction metadata needed for security monitoring, with any prompt or output content redacted or anonymized before storage. It also recommends enriching security events with AI-specific context for downstream detection and response systems. In practice, record the policy that applied, the decision, the caller and the target, and keep raw prompt text out of long-term storage unless you have a reason to retain it. Governance records should also state residual risk and the compensating controls, such as privilege limits and approval checkpoints.

Where an execution-path enforcement layer complements the gateway

A gateway controls traffic at its own boundary. Agents and tools extend past it. When an agent calls a tool or an MCP server, the consequential event is the action itself, and the risk depends on the operation, target, arguments and caller authority. That points to enforcement where actions are executed, in addition to inspection at the gateway.

Trussed operates in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It enforces policy at runtime, not after the fact, on individual interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. That enforcement generates audit-ready evidence continuously, mapped to HIPAA, NAIC, NYDFS, EU AI Act and NIST. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency.

For context on operating maturity, Trussed has run continuously in production at a regulated enterprise for more than 18 months, with 99.95% uptime on live production traffic, 100+ models under one policy plane and more than 30 GB of audit evidence generated per day.

This is a complement, not a replacement. Gateway-level detection handles prompt inspection at the boundary. Execution-path enforcement covers what happens when the model's output turns into an action. Teams that build their own detector can still place enforcement and evidence collection at the point of execution.