Real-Time Threat Detection in AI Gateway Infrastructure

An AI gateway concentrates trust in a way almost nothing else in the enterprise stack does. Credentials, model-provider keys, data access, routing policy, and execution privileges all converge at a single choke point, so an attacker who gets past the front door gets the whole house. Traditional network security was built around thin routing layers that passed traffic through without holding much of value themselves. AI gateways invert that assumption entirely: they sit thick with secrets and authority, which is a structurally new kind of target for security teams used to defending pipes, not vaults.

Microsoft's Threat Intelligence team said in its security blog that attackers now treat AI infrastructure as a control plane, a place where credential theft, host compromise, and downstream data access all converge in one move. That makes the gateway a strategic target, not an incidental one. Three separate Microsoft investigations, spanning LiteLLM, RAGFlow, and Kestra deployments, found attackers pursuing an identical playbook despite the workloads having nothing in common on the surface: harvest credentials, establish persistence, monetize the compute they now control. The LiteLLM intrusion involved Python droppers, runtime secret harvesting, and PostgreSQL data collection, capped off with miner deployment, with initial access likely coming through a chained exploit of CVE-2026-42271 and CVE-2026-48710. RAGFlow's compromise looked different on entry, suspected SSRF-style reconnaissance followed by a Python hook planted inside the TenantLLM credential-configuration flow, positioned to intercept any new LLM provider credentials as they were set up. Kestra's attackers used workflow-origin shell execution and Docker environment discovery before dropping XMRig, likely via CVE-2026-49869. Different doors, same house, same goal.

The Model Context Protocol has only sharpened this problem. MCP gateways now sit between AI agents and every tool, API, and enterprise system those agents are permitted to touch, which makes the gateway layer simultaneously the control plane for agentic AI and the single highest-leverage target an attacker could ask for. Compromise the gateway, and an attacker doesn't need to compromise the hundred systems behind it one at a time.

The four threat categories a gateway must intercept

Prompt injection, credential harvesting, PII leakage, and supply-chain compromise are structurally distinct attack classes, and treating them as a single "AI threat" category produces detection gaps at every layer.

Prompt injection relies on neither malware nor stolen passwords: the attack surface is the content an agent is designed to read. Aikido Security's December 2025 disclosure of PromptPwnd was the first confirmed real-world case of prompt injection compromising a CI/CD pipeline, with the payload smuggled in through a GitHub issue that reached straight into pipeline secrets. Google's Threat Intelligence Group reported that the threat actor UNC6780 was using prompt injection against AI coding assistants and LLM-based security scanners as a supply-chain attack technique in its own right. No credentials stolen, no code exploited. Just words, aimed correctly.

Credential harvesting works from the opposite direction. The gateway holds model-provider keys, virtual keys, proxy master keys, database connection strings, and OAuth tokens, all reachable from inside the gateway's own runtime, which makes it a harvest target by default rather than by accident. Shadow AI compounds the exposure: teams standing up agents with hardcoded, long-lived API keys sidestep IT governance entirely, leaving behind standing credential sprawl that an attacker can harvest without ever going near a vault. February 2026's SANDWORM_MODE campaign, documented by Socket's Threat Research Team, was a family of nineteen typosquatted npm packages that deployed a rogue MCP server into hidden directories after a 48- to 96-hour delay, then instructed AI assistants to silently extract SSH keys, AWS credentials, npm tokens, and environment variables.

PII and data leakage move in two directions at once. Inbound, a user or agent sends personal data into a model the organization doesn't control. Outbound, a model's response surfaces data pulled from an internal knowledge base or database the agent had access to but the requester should never have seen. In financial services this isn't a hypothetical compliance exercise: GLBA and FFIEC examination requirements demand demonstrable control over non-public personal information moving through AI models and agent workflows, backed by a documented policy and an audit trail for every model call.

Supply-chain and rogue-server compromise round out the fourth category, and it's arguably the fastest-moving one. The MCP ecosystem shipped material spec releases in March, June, and July 2026 alone, a pace that leaves organizations consuming community MCP servers integrating code faster than their own review processes can keep up. Rogue and typosquatted MCP servers can register tools with deceptively normal-sounding names that instruct agents to take actions the user never approved, while actively hiding that activity from view. SANDWORM_MODE is the textbook case: tools dressed up to look legitimate, extraction hidden from the user interface the whole time.

Why detection bolted on after routing fails

Detection added after the gateway routes traffic fails for a simple structural reason: by the time traffic reaches a downstream inspection layer, the gateway has already made its decisions. A gateway that only routes sees requests and responses, but it doesn't hold the context that actually matters, namely who the agent is, what identity it was issued, what it's permitted to do, and what it has already done earlier in the session. Detection without that context is detection blind to intent.

Prompt injection payloads exploit this timing gap directly. A malicious instruction embedded in a retrieved document arrives already packaged inside a completed request. Detection running after routing finds the payload only once it's sitting next to the model, which is precisely the moment it's too late. Credential harvesting bypasses post-routing detection even more completely: the attacker's target is the gateway process itself, not the traffic flowing through it, so a monitoring layer watching traffic never sees the attack happen at all. In the LiteLLM incident, the gateway held model-provider keys, virtual-key records, and database connection strings, and a SIEM watching outbound network traffic would never have caught a Python dropper executing quietly inside the gateway's own process.

The gap between confidence and reality is visible in a 2026 enterprise security survey, which found the vast majority of organizations had confirmed or suspected an AI agent security incident within the past year, while a separate Beam AI survey found most executives believed their existing policies already had them covered. Ungoverned gateway traffic lives in that space between what leadership believes and what's actually happening on the wire.

Closing that gap takes more than a single filter appended downstream. Cequence's roundup of the category found that effective gateway threat detection needs rule-based heuristics, machine learning, and anomaly detection working in concert. Detection has to move inline, evaluate identity and permission alongside content, and sit at the same layer where the routing decision itself gets made. That requirement plays out differently for each of the three mechanisms that follow.

How prompt injection detection works at the gateway layer

Prompt injection detection at the gateway layer works in layers because no single technique catches the full range of the attack. Pattern recognition is the first pass, scanning inbound prompts for suspicious phrasing before they ever reach the model. Static patterns age poorly: attackers evolve their phrasing faster than any rule set gets updated. Cequence's analysis calls continuous monitoring and rule updates a requirement rather than a nice-to-have.

Context-aware filtering closes some of that gap. Instead of judging a prompt in isolation, the gateway evaluates it against the agent's declared role, its permitted tool set, and what's already happened in the session. An instruction telling the model to "ignore previous instructions" reads very differently coming through a customer-service agent than it does inside a red-team testing tool, and a gateway that can't tell the two apart will either miss real attacks or flood analysts with noise.

Indirect injection is the harder case, and it's the one that actually broke through in the wild. PromptPwnd, disclosed by Aikido Security in December 2025, entered through a GitHub issue rather than a user prompt; any gateway inspecting only user-originated input would have let it straight through. Detection has to reach into retrieved content, documents, web pages, code comments, before that content ever gets assembled into a prompt, checking more than what the user typed.

At the MCP layer, the same logic extends to tool-call instructions, not just chat turns. A rogue MCP server's tool description can carry injection content on its own, exactly as it did in the SANDWORM_MODE case. Gateway-level detection has to treat tool metadata with the same suspicion as user text. Once a gateway flags a suspicious call, the practical response looks like blocking the tool call outright, redacting the sensitive portion of the payload, or flagging the session for a human to review, all triggered inline before the tool executes rather than logged for someone to read later.

Building credential and secret protection into gateway identity and token handling

Credential protection is an architecture problem before it is a detection problem, and detection becomes reliable only once the architecture stops handing out credentials that don't need to exist.

The root cause of credential harvesting is standing sprawl: agents issued long-lived, broad API keys that outlive any single task give an attacker a window measured in days or weeks instead of minutes. Shadow AI, discussed earlier as an enabler of harvesting, is really a symptom of this same root cause, teams generating credentials outside any governance process because the gateway made it easy to skip.

The fix is short-lived token issuance at the moment of use. The agent never holds a raw credential for the MCP tools it calls; the gateway mints a short-lived token dynamically, at runtime, scoped to that specific invocation. Streamward's implementation shows the pattern in practice: all MCP traffic routes through an inline Runtime Agent Gateway acting as the policy enforcement point, with Okta serving as the policy decision point behind it. The agent gets a short-lived token instead of running under a broad, permanent service account whose standing permissions would expose the entire database layer to a prompt-injection attack. Amazon Bedrock's AgentCore Gateway handles a similar split in a single managed layer: inbound authentication verifies the agent's identity through a JWT issued by Cognito or another OIDC provider, while outbound authentication runs an OAuth client credentials flow for whatever third-party service the agent needs to reach.

Once credentials are centralized this way, detection has something real to watch. Scanning outbound responses and tool outputs for patterns matching API keys, tokens, SSH keys, and environment variables catches exactly the kind of silent exfiltration SANDWORM_MODE ran through tool call results. Okta's Agent Discovery, part of its ISPM product line, addresses the problem from the other end, identifying agents that already exist, known or not, surfacing hidden identity risks and misconfigurations, and mapping how far each agent's access could reach if compromised. The effect is converting shadow agents into governed assets with a named human owner and an enforced baseline policy. As Okta's SVP and GM of AI Security, Harish Peri, framed it: identity is the control plane for the agentic enterprise, because AI agents don't operate at the network, endpoint, or device layer. They live in the application layer, running on multiple non-human identities that too often carry broad, long-lived privileges. Network-layer monitoring was never built to watch that layer, which is the whole argument for putting credential controls inside gateway identity handling rather than bolting them on beside it.

How PII and data leakage detection operates inline

PII detection at the gateway must be aggressive enough to stop leakage and precise enough not to break the agent workflows the organization built the system to run. Blunt content filtering fails on both counts at once, producing false positives that block legitimate work and false negatives that let contextually inappropriate disclosures through anyway. The fix is inline DLP that's role-aware and directionally scoped, applied differently depending on the request.

Leakage runs in two directions, and each needs its own detection logic. Inbound, a user or agent sends personal data into a model the organization doesn't control, and the gateway has to catch and redact it before the request ever leaves the enterprise boundary. Outbound, a model's response surfaces data pulled from an internal knowledge base or database the agent had permission to query, and the gateway has to judge whether that specific content is appropriate for the specific identity that requested it.

That last judgment is where role-awareness earns its keep. A finance agent querying customer account data should be able to receive certain fields back; a general-purpose assistant asking the same question should trigger redaction or an outright block, even though the underlying data hasn't changed. Policy-as-code makes rules like "no PII to external LLMs" or "finance agents cannot modify production ledgers without approval" enforceable directly at the gateway, evaluated on every call rather than documented in a policy nobody checks in real time. Cequence's inline DLP, currently in Beta, and its behavioral containment tooling are purpose-built for this category; Kong's AI Gateway pairs PII sanitization with token quotas as part of its broader LLM and MCP governance layer.

None of this is optional in regulated industries. Under GLBA and FFIEC requirements, every model call touching customer financial data needs a documented policy governing how that data is handled and an audit record proving the policy was actually enforced. Inline detection at the gateway is the only architecture that can generate both at once, since after-the-fact logging can prove a call happened but not that a policy governed it in real time. The standard objection, that aggressive inline filtering adds latency and breaks agent workflows, holds up against a flat content policy applied to everything. It doesn't hold up against detection scoped to the agent's actual role and actual data access: a gateway scoped this way protects the organization, while a flat policy just slows it down.

What full observability requires beyond alert generation

Alerts tell a security team something happened. They don't tell it who the agent was, what identity issued the call, what the agent was permitted to do at that moment, or what it had already done earlier in the same session, and without that context an alert is a fact without a story. Full observability at the gateway layer means every request carries its identity, permission scope, and session history along with it, so that a flagged event can be traced back to a specific agent, a specific token, and a specific chain of prior actions rather than showing up as an isolated ping on a dashboard.

That's the difference between a log and a record. A log says a call was blocked. A record says which agent made it, under which credential, against which policy, and what it tried to do next. Gateways built only to route traffic can produce the first. Gateways built with identity, policy, and detection architected in from the start can produce the second, and the second is the version that holds up when a regulator or an incident responder asks what actually happened.