AI Gateway Guardrail Coverage Gaps Across LiteLLM and Kong

AI gateway guardrails in LiteLLM and Kong provide useful inspection at the routing layer, but they do not govern the full execution of an agent. Their shared limitation is architectural. Production agent security requires intent enforcement, runtime tool-argument inspection, and adversarial verification beyond the API boundary where gateway controls operate.

Why AI gateways became the de facto security layer for agent traffic

LiteLLM and Kong originated as routing and cost-management infrastructure, providing provider abstraction, credential centralization, rate limiting, and usage tracking. Guardrails, PII masking, and prompt injection scanning were layered onto that infrastructure after adoption. The operational appeal was clear from the start. Teams that already routed model traffic through a gateway could add security checks there without adding another control point.

Check Point Research describes LiteLLM as a system that “sits between applications and model providers and often handles credentials, configuration, and request routing”. A gateway may hold provider credentials, give out virtual API keys, run guardrail logic, and route calls to external tools or MCP servers. Compromise can therefore reach both the credential plane and the agent control plane. As teams extended gateways to govern multi-step workflows, infrastructure built to route requests became infrastructure expected to constrain execution.

What the agentic attack surface looks like compared to what a gateway can see

A traditional LLM application presents a bounded interaction, with one user prompt entering and one model response leaving. The gateway can inspect both edges of that exchange. Agents break that simple model of interaction. They retrieve material from multiple sources, maintain state across turns, and invoke tools with less user oversight. What agents can do blurs the trust boundary between instructions, retrieved data, and the environment where actions run.

Indirect content injection exploits that blurred boundary. Malicious instructions embedded in web pages, files, emails, or RAG results can enter the agent’s context as data and redirect its subsequent tool use. A gateway may see the next outbound LLM request without seeing the retrieval that preceded it or the tool action that follows. Even when retrieved text appears in a model request, inspecting that request does not establish control over its downstream effects. The inspection window remains the API boundary.

Chained actions make the visibility gap consequential. An instruction accepted at one step can shape later tool calls and sub-agent decisions before another inspection hook can check them. Detecting suspicious content on a later request does not contain actions already taken through an uninspected path.

LiteLLM's guardrail architecture and where its inspection hooks do not reach

LiteLLM integrates with more than 40 third-party guardrail providers for prompt injection detection, PII masking, and content filtering. Its guardrails run in pre_call, during_call, or post_call mode and can be scoped per request, API key, or team. These hooks let teams check for known patterns. They expose a plugin surface with limited coverage of agent security. Coverage depends on the configured provider, route, and execution mode.

LiteLLM’s built-in detection callback runs on all unified route types, including /v1/messages and /v1/responses. Some third-party integrations have narrower support. Lakera v2, for example, is limited to /v1/chat/completions, so configuring it there does not establish coverage elsewhere. Applicable pre_call guardrails must be explicitly configured for the routes in use. Treating the primary route’s configuration as universal protection leaves other traffic uninspected.

Streaming adds a separate problem of timing. A first chunk can reach the client in roughly a second, ahead of a check’s roughly twelve-second window, allowing a secret or PII value to arrive before a redaction decision. Streaming protection is available and on by default, with stream_scope defaulting to both. The opt-in incremental_diff rewrite mode has narrower coverage, applying only to OpenAI chat completions streaming.

A signature scanner does not establish whether apparently innocuous turns collectively extract a system prompt. When an orchestrator invokes sub-agents or chains tools outside the inspected boundary, native hooks see only the outer API call. Adding providers cannot give the gateway intent-based enforcement or chain-level visibility.

Kong's guardrail architecture, its MCP additions, and the gaps those additions leave

Kong’s AI Prompt Guard has allow and deny lists that use regular expressions. AI Semantic Prompt Guard adds topic-level classification, allowing restricted subjects to be recognized even when a request is paraphrased. That extends coverage beyond literal attack patterns. Both controls still evaluate content at the prompt boundary rather than governing decisions inside an agent’s execution chain.

Kong version 3.13 introduced MCP Tool ACLs, a substantive improvement in consumer-level authorization. Before that addition, organizations faced a server-level choice between full tool access and no access. When an MCP client executes tools/list, Kong now intercepts the response and filters the available tools according to the authenticated user’s permissions. This narrows the tool-discovery surface for each consumer. It does not establish purpose-based persona governance, which would restrict an agent to the intersection of user permissions and the tools required for its task.

Tool authorization also leaves a separate payload boundary. Policy can determine which tool an agent may invoke without inspecting the semantic content of its arguments by default. Those checks therefore leave data exfiltration and injected instructions inside the arguments unchecked. Authentication establishes who is calling, while tool authorization establishes what they may call. Neither establishes whether the proposed payload is permitted.

Kong requires custom logic for session-aware behavior, and its audit logging captures MCP traffic as generic API calls without agentic semantics. That makes reconstruction of an agent incident harder.

How the gateway's security surface became an attack surface in its own right

Insufficient field-level authorization allowed users able to reach the affected functionality to modify user_role, elevate to proxy_admin, and gain administrative access to users, teams, keys, models, and prompt history. The affected field was an authority boundary. Its modification exposed much more than an individual model request.

Check Point Research found that a missing authorization check on /config/update let authenticated users change the runtime configuration. This opened paths to arbitrary file read, administrative account takeover, and remote code execution through malicious Python modules loaded from cloud storage. The same research identified SSRF in “Clientside LLM Credentials” that allowed API-call redirection and provider-key exfiltration. LiteLLM’s security hardening post acknowledged the configuration gap and documented unsalted password hashes, sometimes plaintext passwords, and endpoints returning hashes to authenticated users. Because /v2/login accepted those hashes directly, a stolen hash served as a credential.

Advisory X41-2026-001 describes a failure in the guardrail testing surface itself. Authenticated users could submit Python to /guardrails/test_custom_code, where bytecode rewriting bypassed regex-based source filtering and achieved arbitrary code execution. The default Docker image ran that code as root. Wiz Research also found CVE-2026-59822, an MCP authentication bypass in which a garbage Bearer token triggered a faulty OAuth2 passthrough fallback. Instead of rejecting the request, the handler substituted an empty UserAPIKeyAuth() object and created a valid session.

These findings concern the platform that executes the checks. Weaknesses in authorization, configuration, and code execution can break the guardrails before it matters how well they detect attacks. The October 21, 2026 supply chain incident reaches deeper into that trust model because even artifact signing failed as a trust anchor. Inspection coverage cannot establish safety when the executing platform or its release path is compromised.

The specific categories of agent risk that neither gateway addresses

Intent enforcement is the first missing control category. Pattern matching and topic classification evaluate recognizable content. Slow system-prompt extraction, gradual privilege escalation, and cross-session manipulation can leave no clear signature in any one turn. A production assessment therefore needs to distinguish prompt classification from enforcement of the agent’s permitted purpose.

Argument inspection is a separate missing boundary. Checks on tool names cannot tell whether payloads contain prohibited data, injected instructions, or compliance violations. Logging does not close that gap either. Kong keeps tool-argument payload logging off by default, while LiteLLM logs message content by default and requires explicit opt-out. Recorded content may support investigation, but recording it is not semantic enforcement before execution.

An outer API call does not expose all instructions passed from an orchestrator to sub-agents or every tool invocation those sub-agents make. More verbose gateway logs cannot change that topology. Likewise, authenticating the person who starts a session does not by itself propagate human attribution through each subsequent action. Without that continuity, incident responders may know that a tool ran without being able to connect it to a specific user and execution step.

Adversarial verification is the remaining pre-deployment gap. The OWASP LLM Top 10 names attack categories that configuration-based guardrails cover only partially. Neither gateway provides a mechanism to demonstrate that a specific attack against a specific agent workflow was tested and blocked. This makes the taxonomy actionable as a coverage assessment, separating configured checks from execution controls and tested outcomes.

Why the detection-versus-containment distinction changes how practitioners should respond

Adding guardrail providers can improve detection without changing what an attacker can accomplish through an uninspected path. Detection remains valuable at the API boundary. It blocks requests known to be bad, checks responses, and keeps a record of flagged traffic. But indirect injection, cross-agent manipulation, and argument-level exfiltration can operate before or inside that boundary. Better classification there does not substitute for control over actions elsewhere.

Containment starts from the possibility that detection fails. A coerced agent would still have access only to permitted tools, would pass arguments through an inspection plane, and would act only within its pre-authorized purpose. Kong’s 3.13 MCP Tool ACLs illustrate this shift at the discovery layer by narrowing the tools exposed to a consumer. The next boundaries are runtime argument enforcement and task-specific persona scoping.

Containment does add latency and operational complexity. A detection-only posture can be acceptable for low-stakes workflows, but that decision depends on correctly identifying the tools, credentials, and data an agent can reach. The gateway incidents show why teams must check what infrastructure an agent can reach as part of that assessment. The practical question for teams is what a coerced agent can actually do when the guardrail does not fire.

What a security standard for agentic systems would actually require that gateways do not provide

A security standard for agents needs evidence from the workflow that teams plan to release. It requires a specific attack to be attempted and blocked before deployment, rather than assuming a configured detector covers the relevant path. The OWASP DevSecOps Guideline explicitly includes indirect injection via tool output in agent testing. Its advanced maturity tier also uses production telemetry, including blocked injections and anomalous tool calls, to add to the regression corpus.

The LiteLLM findings show the danger of broad configuration and execution surfaces, supporting the principle of making the smallest change that stops an attack. More providers or more aggressive scanning can disrupt legitimate workflows. Teams therefore need to verify that approved workflows still pass, with a human approver able to reproduce the tested outcome independently of the tool that produced the change.

For teams shipping agents, the practical response begins with gateway guardrails as the first layer. Route coverage needs an audit that includes streaming, alternate route types, and MCP payload inspection. MCP Tool ACLs should constrain access at both the server and individual-tool levels. Teams should also map the actions available to a coerced agent and add evidence-based testing for attacks beyond gateway reach.

The next enforcement layer belongs where actions are authorized. Runtime tool-argument inspection, identity propagation, and pre-action policy enforcement link what the human asks for to what the agent actually does. A gateway can inspect traffic on the way there. A complete security posture must also constrain and verify the resulting execution.