How to stop prompt injection from cascading across AI agents
The short answer
With agents, the model's output triggers actions — tool calls, API calls, even payments — so a single poisoned input can cascade into real-world effects. Senthex sits in front of every model and tool boundary, detecting injection before the agent acts and recording one audit trail across the agent's calls. In our ATLAS experiment, an enforcing firewall triggered the fraudulent transfer in 0 of 17 runs, versus 17 of 18 without it.
Why is prompt injection worse for AI agents?
A chatbot that gets jailbroken says something it shouldn't. An agent that gets injected does something it shouldn't — because it has tools. The classic danger pattern is the "lethal trifecta" (a term from Simon Willison): untrusted input + access to private data or tools + a way to exfiltrate or act. Put all three in one agent loop and an attacker who controls a document, an email, or a support ticket can steer the agent's actions. Multi-agent and MCP setups widen this: one poisoned message can propagate from agent to agent.
What did the ATLAS experiment actually show?
We ran a controlled study (ATLAS Lab #1) on a support-agent workflow. A single poisoned support ticket instructed the agent to issue a refund-style transfer. With no enforcing control, the agent followed the injected instruction and moved €48,500 in 17 of 18 runs. With an enforcing firewall that blocked on detection, the fraudulent transfer fired in 0 of 17 runs. That is one scenario, not a universal guarantee — but it shows why detecting in shadow mode is not the same as stopping the action. Read the full method and caveats.
How does a proxy help secure agents and MCP tools?
Because Senthex is in the call path, it gives an agent stack one consistent control point:
- Detect before the act — shields run on the input that would drive the next tool call, and enforcing mode blocks instead of merely logging.
- One audit trail across every model and tool the agent touches, so you can reconstruct the chain after the fact.
- Defence-in-depth signals — secret-leak, unicode-steganography and behavioural checks that target the integration layer agents expose.
The thesis, in full, is our manifesto: agents make the proxy load-bearing.
The honest limits
A firewall in front of your agents reduces risk; it does not eliminate it.
- Best-effort detection. The same LLM01 limits apply — pattern-based shields have gaps.
- Agent design still matters. Least-privilege tools, human approval for high-impact actions (like moving money), and tight tool scopes are not optional because you added a proxy.
- The verifiable audit trail is a pilot. The cascade-reconstruction record is metadata logging today; the SHA-256 + RFC 3161 + offline verifier proof is the v1.1.7 pilot.
ATLAS Lab #1 — one poisoned support ticket, repeated runs
| Configuration | Fraudulent transfer triggered | What happened |
|---|---|---|
| No enforcing control (detect-only / shadow) | 17 of 18 runs | the agent followed the injected instruction and moved €48,500 |
| Enforcing firewall (block on detection) | 0 of 17 runs | the injected instruction was blocked before the agent acted |
| Takeaway | Detection ≠ prevention | shadow mode tells you; enforcing mode stops it — in this scenario |
Frequently asked questions
How do I stop prompt injection from cascading across my AI agents?
Put an enforcing control in front of every model and tool boundary. Senthex proxies the agent's calls, runs injection and integration-layer shields on the input that would drive the next tool call, and in enforcing mode blocks instead of just logging — while keeping one audit trail across the whole chain so you can reconstruct what happened.
Why are agents more dangerous than a chatbot when injected?
A chatbot says something wrong; an agent does something wrong, because it has tools. The lethal trifecta — untrusted input plus tool or data access plus an exfiltration or action path — lets an attacker who controls a document, email or ticket steer the agent's actions. Multi-agent and MCP setups let one poisoned message propagate between agents.
Does the ATLAS result mean Senthex blocks 100% of attacks?
No. ATLAS Lab #1 is one controlled scenario: a single poisoned ticket where the enforcing firewall triggered the fraudulent transfer in 0 of 17 runs, versus 17 of 18 without it. It shows detection isn't the same as prevention. It is not a claim of universal protection — detection is best-effort (OWASP LLM01).
Does it work with MCP and multi-agent frameworks?
Senthex is a transparent proxy you reach by changing the base_url, so it sits in front of the model calls your agents make regardless of framework. It gives you one control point and one audit trail across the agents and tools in the loop. Tight tool scopes and human approval for high-impact actions remain your responsibility.
Can I reconstruct an agent cascade after it happens?
Yes — the per-call record lets you walk the chain of calls an agent made and see which shields fired. Proving that record wasn't edited is the v1.1.7 pilot (SHA-256 chain + RFC 3161 + offline verifier). See the replay-an-AI-decision and prove-what-your-AI-did pages.
Put a control in front of your agents
Read the ATLAS Lab #1 study for the full method, then start on the Free plan and run your agent traffic through Senthex in shadow mode first. For an enforcing, self-hosted deployment, talk to us.