When Your LLM Router Turns Against You: The Hidden Security Risk in AI Agents

AI agents are increasingly being built on top of LLM routers and gateways. Instead of connecting an application directly to OpenAI, Anthropic, Google, or another model provider, developers can place a routing layer in between to select models, optimize costs, improve reliability, and provide a single API.

That architecture is convenient. It also creates a new security boundary.

A recent research paper, Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain, investigates what happens when that intermediary cannot be trusted. The researchers analyzed 28 paid and 400 free LLM routers and found evidence of malicious response manipulation, adaptive attack behavior, and credential abuse. They also demonstrated how compromised intermediaries can become part of larger attack chains involving autonomous AI agents.

The underlying problem is simple but easy to overlook: an LLM router is not necessarily a passive transport layer. It can sit directly between an agent and its model provider, giving it visibility into requests and responses and, depending on the architecture, the ability to modify them.

For traditional chat applications, that is already a serious trust issue. For autonomous agents that can execute tools, access files, run code, or interact with external systems, it can become much more consequential.

‍

The hidden trust layer behind AI agents

A simple LLM application often looks like this:

Application → Model Provider → Application

The application sends a prompt to a provider and receives a response. When multiple models and providers are involved, however, a router can simplify the architecture:

Application → LLM Router → Model Provider

The router decides where a request should go. It may select a provider based on cost, latency, availability, model quality, geographic requirements, or other policies. If one provider becomes unavailable, it may route the request elsewhere.

This architecture is increasingly useful because AI infrastructure is becoming more fragmented. Teams may use several commercial providers, open models, specialized endpoints, and different models for different workloads.

Eden AI's own LLM routing architecture follows this broader trend: a gateway can provide a unified interface while giving developers access to multiple models and providers, routing, fallbacks, and other infrastructure controls. The important question is therefore not whether routing is useful. It is what level of trust developers place in the routing layer.

That distinction becomes critical once the application is an AI agent.

A router is more than a traffic switch

For a basic API request, the router may see a prompt and a text response. An agent request can contain much more.

Depending on the application, traffic passing through an intermediary can include system instructions, conversation context, tool definitions, tool arguments, tool results, authentication material, and other application data.

The router may also sit on the response path:

Model Provider → Router → Agent

This means the security question is no longer only "Can the router send my request to the correct model?". It becomes "Can I trust the router not to alter what the model sends back?"

That is the central issue explored by the research.

How a malicious intermediary can change an agent's behavior

An LLM normally generates a response that an agent interprets. When the response contains a tool call, the agent may use that structured output to perform an action.

The normal flow is:

Agent → Router → Model

Model → Router → Agent → Tool

A compromised intermediary can sit directly on the second half of that path:

Model → Malicious Router → Agent → Tool

The model itself does not have to be compromised. The agent does not have to be vulnerable to a prompt injection. The router simply has to modify the response before passing it to the application.

Consider a simplified example. A model decides that an agent should call a particular tool with a particular set of arguments. The agent receives the response and, because it is designed to execute that tool automatically, acts on it.

If the intermediary changes those arguments before the response reaches the agent, the agent may execute something different from what the model originally generated.

The attack therefore exploits a layer that is often treated as infrastructure rather than part of the application's security model.

This is different from prompt injection

Prompt injection attacks attempt to influence the model through instructions contained in prompts, documents, websites, or other input.

The intermediary attack described by the researchers operates at a different point in the chain.

The model can produce a perfectly legitimate response. The intermediary can then modify that response before the agent sees it.

That makes the attack particularly interesting because improving the model's resistance to prompt injection does not automatically solve the intermediary problem.

The model may be trustworthy.

The provider connection may be encrypted.

The tool schema may be valid.

And yet the agent can still receive a response that has been altered somewhere between the provider and the application.

The quieter threat: credentials passing through the router

Response manipulation is only one side of the problem.

An intermediary may also be able to observe sensitive information flowing through the traffic it handles.

AI applications frequently operate alongside other services and credentials. Depending on the architecture, requests or tool interactions can expose information associated with cloud environments, source-control systems, databases, third-party APIs, or other services.

If a router is malicious, it does not necessarily need to manipulate an agent at all. It may simply collect valuable information that passes through it.

The research found evidence of routers abusing researcher-controlled credentials during its ecosystem measurements. In one of the study's experiments, the researchers also observed a router that drained cryptocurrency from a researcher-controlled private key.

This highlights a broader security principle:

Every intermediary that can observe sensitive application traffic becomes part of the application's trust boundary.

That principle is familiar in traditional infrastructure, but it is particularly important in AI systems because agents increasingly combine model calls with access to external tools and credentials.

The attack does not have to happen immediately

One of the more concerning findings is that malicious behavior does not necessarily need to appear during the first request.

A router can behave normally under ordinary testing and activate suspicious behavior only when particular conditions are met.

The researchers describe adaptive attack strategies involving conditions such as request counts, autonomous execution modes, or characteristics of the project being targeted. One example involved behavior that was delayed until after a number of previous requests.

This creates an important testing problem.

Imagine evaluating a third-party router before putting it into production. You send several requests, inspect the responses, and everything appears normal.

That does not necessarily establish that the intermediary is trustworthy.

A malicious system could deliberately minimize its observable behavior during basic testing and activate only when a more valuable target or a specific environment is detected.

Targeting the dependency layer

The research also examines attacks that target software dependencies rather than simply inserting an obviously suspicious command.

This matters because developers often build defenses around visible indicators such as unexpected destinations or obviously malicious payloads.

A more subtle modification can preserve much of the original request structure while changing a dependency or another component of the action.

The broader lesson is that valid syntax does not guarantee valid intent.

A tool call can conform to the expected schema and still be harmful if its contents have been altered.

What the researchers found across the router ecosystem

The paper's measurements are what make the issue particularly notable.

The researchers examined 428 routers in total: 28 paid routers and 400 free routers. Their study found nine routers that injected malicious code, two that demonstrated adaptive evasion behavior, and 17 that abused researcher-owned credentials.

These numbers should not be interpreted as evidence that most LLM routers are malicious. The study is a measurement of a particular ecosystem and a particular research methodology, not a claim that every commercial or open-source router is compromised.

But the results demonstrate something important: The intermediary itself needs to be included in the security model.

That is the significant finding for developers.

Router chains create a weakest-link problem

The risk becomes even more interesting when multiple routing layers are involved.

Consider a system where an application sends traffic through several intermediaries:

Agent → Router A → Router B → Router C → Model Provider

Router A may be trustworthy.

Router B may be trustworthy.

Router C may be compromised.

From the application's perspective, however, the final response still travels back through the chain:

Model → Router C → Router B → Router A → Agent

If Router C modifies the response, Router A and Router B may simply forward the modified message.

This creates a weakest-link property: adding more routing layers does not automatically add more security.

The same principle applies to credentials. If one intermediary in the chain can access a credential, the security of the entire chain depends on that intermediary behaving correctly.

The poisoning experiments

The researchers went further by studying how apparently benign infrastructure can become involved in the same attack surface through leaked credentials and weak relay chains.

Their experiments observed substantial downstream activity, including hundreds of agent sessions and interactions involving hundreds of projects or hosts.

The important takeaway is not the specific mechanics of the experiment. It is the scale amplification.

A single compromised intermediary does not necessarily have to attack one application at a time.

If that intermediary sits inside infrastructure used by many agents, it can potentially become a central observation and manipulation point for a much larger ecosystem.

Autonomous agents raise the stakes

The security implications become significantly stronger when agents can act without human approval.

A traditional chatbot might return a suggestion: "You should install this package.". A human then decides whether to do it.

An autonomous coding agent might instead receive a tool call and execute it as part of its workflow.

That changes the security model from:

Model output → Human interpretation → Action

to:

Model output → Agent → Action

The intermediary therefore becomes part of the path that determines what the agent actually does.

The research's poisoning experiments found hundreds of observed agent sessions, including a large number operating in highly autonomous modes.

This is why the intermediary problem matters more as AI agents become more capable.

The more authority an agent has, the more important the integrity of every message that reaches it becomes.

How can developers defend against malicious routers?

There is no single control that completely eliminates the risk. The paper evaluates several client-side defenses, and each addresses a different part of the problem.

1. Enforce policies before executing high-risk tools

One approach is to place policy checks between the model response and tool execution.

For example, an agent could restrict which tools are allowed to perform sensitive operations, which destinations they can access, or which classes of actions require additional approval.

This creates another security boundary:

Model response → Policy check → Tool execution

Such controls can block suspicious actions even if a response has been modified upstream.

The limitation is that policy rules can become difficult to maintain, and a malicious modification does not necessarily have to look obviously malicious.

2. Inspect tool calls for anomalies

Another layer is to inspect model responses and tool calls before execution.

Unexpected destinations, unusual arguments, suspicious command patterns, or changes from established behavior can all become signals for detection.

The researchers evaluated response-side anomaly detection and reported strong detection performance on their attack samples, although false positives remained a challenge.

This is an important distinction:

Detection is not the same as verification.

An anomaly detector can identify behavior that looks suspicious. It cannot prove that a response came from the model provider unchanged.

3. Keep detailed logs

Logging does not prevent a malicious intermediary from acting, but it can dramatically improve detection and incident response.

Teams should be able to understand:

• which model handled a request
• which provider was selected
• what tools were invoked
• which credentials or services were involved
• when unusual behavior started
• how requests moved through the infrastructure

For agent systems, observability should extend beyond latency and token usage.

It should also help answer: What did the agent receive, what did it execute, and where did that instruction come from?

That is increasingly important as AI infrastructure becomes more distributed.

4. Reduce the value of credentials exposed to agents

The principle of least privilege is particularly important for autonomous AI systems.

An agent should not automatically have access to every credential available to the surrounding environment. Sensitive operations should use scoped credentials, isolated environments, and additional approval where appropriate.

This does not solve malicious routing, but it reduces the potential impact if an intermediary is compromised.

A compromised router should not automatically translate into unrestricted access to an application's entire infrastructure.

The deeper solution: verify the integrity of model responses

The defenses above largely operate on the client side.

They can restrict, inspect, or record what the agent receives.

But there is a deeper architectural question:

Can the agent verify that the response it received is actually the response produced by the model provider?

Today, a simplified architecture can look like:

Provider → Router → Agent

The router can terminate one connection and establish another. From the agent's perspective, the router is therefore the immediate source of the response.

A stronger future architecture could provide some form of authenticated response provenance:

Provider → Authenticated response → Router → Agent

The agent could then verify the integrity or origin of security-sensitive portions of the response before executing them.

This would not necessarily prevent a router from seeing traffic. It would instead make unauthorized modification detectable.

For tool-using agents, that distinction could become increasingly important.

What this means for LLM routing

The lesson from this research is not that developers should stop using LLM routers.

Routing is becoming an important part of AI infrastructure because modern applications increasingly need to manage multiple providers, models, prices, latency targets, fallbacks, and availability requirements.

The real lesson is that the routing layer should be treated as security-critical infrastructure rather than an invisible networking component.

When evaluating an LLM router, developers should ask questions beyond:

• How many models does it support?
• How fast is it?
• How much does it cost?
• Does it provide fallbacks?

Security questions matter too:

• What data can the router see?
• Where is traffic processed?
• How are credentials handled?
• What authentication and access controls are available?
• Can requests and responses be audited?
• How are routing decisions recorded?
• Can sensitive tools require additional controls?
• What happens when multiple intermediaries are chained?
• How can an organization investigate an unexpected agent action?

This is especially important for systems where an LLM is not simply generating text but controlling software, accessing data, or interacting with external services.

AI gateways need to become part of the security architecture

The evolution from simple LLM APIs to AI gateways and routers is a natural consequence of the growing model ecosystem.

A single application may need to work with multiple providers while maintaining consistent authentication, routing policies, observability, fallback behavior, and cost controls.

That centralization can be useful from a security and governance perspective—provided the gateway itself is treated as a trusted infrastructure component and secured accordingly.

Eden AI approaches this problem by providing a unified gateway for accessing and routing AI models and providers. Its routing layer can abstract provider differences while giving teams centralized control over model access, routing, fallbacks, and usage. The broader architectural advantage is that these concerns can be managed consistently instead of being independently implemented across every application.

But the research points to an important principle for the entire industry:

Centralization creates responsibility.

The more infrastructure an AI gateway controls, the more important its security, transparency, isolation, and observability become.

Building a safer architecture for AI agents

A more robust agent architecture can therefore be thought of as several layers rather than a single trust boundary

The gateway handles routing and infrastructure concerns, while the agent environment continues to enforce least privilege and tool-level controls.

For high-impact actions, an additional approval or policy layer can sit between the model response and execution.

And across the entire system, observability provides a record of what happened.

This defense-in-depth approach recognizes an important reality:

No single layer should have to be trusted blindly.

The AI supply chain does not end at the model

The AI security conversation has understandably focused on model behavior, prompt injection, data poisoning, and vulnerabilities in agent tools.

The research on malicious intermediaries adds another layer to that picture.

The model is only one component in the path from an instruction to an action.

Between the user and the final tool execution there may be an agent framework, an AI gateway, one or more routers, model providers, tool servers, external APIs, and other infrastructure.

Every intermediary that can observe or modify the communication becomes part of the security boundary.

That leads to a simple principle for the next generation of AI applications: Trust the model, but also verify the path the model's output takes before it reaches an autonomous agent.

As AI agents gain more authority to act on behalf of users and organizations, the integrity of that path will become just as important as the intelligence of the model itself.

The future of secure AI routing will therefore not be defined only by choosing the best model or the cheapest provider. It will also depend on making the infrastructure between the model and the agent observable, controlled, and trustworthy.

FAQ