Indirect Prompt Injection: Why AI Agents Need a Sandbox, Not a Better Prompt

A modern AI agent doesn't always need to be hacked the way we picture hacking. Sometimes it just needs to read the wrong text. No malware, no zero-day, no access to the victim's device — just a few words placed where the agent will later read them. That's the uncomfortable reality behind indirect prompt injection, and it's why securing AI agents is becoming an architecture problem, not a prompt-engineering one.

This article is a security analysis, not an attack guide. It describes the risk pattern and defenses; it deliberately includes no working payloads or exfiltration recipes.

The hook: a breach that started with a €0.02 transfer

In a case study by the security firm Blue41 — describing a "leading European bank," and publicly associated with the European neobank bunq — researchers tested a bank's AI assistant. The attacker didn't need an exploit. They sent a tiny bank transfer (the study cites €0.02) and hid a prompt-injection payload in the transaction description.

Later, when a user asked the assistant to summarize recent transactions, the assistant loaded the transaction history — including the attacker's description — into its context. In the controlled demonstration, the model treated that description as an instruction and was steered into producing a spear-phishing message inside the bank's own app.

The dangerous part isn't the trick; it's the channel. The message arrived in a trusted place — the banking app, in the voice of the bank's own AI assistant. That's far more convincing than any phishing email.

What indirect prompt injection actually is

There are two flavors:

• Direct prompt injection: the attacker types instructions straight to the chatbot.
• Indirect prompt injection: the attacker plants instructions inside data the agent will later read on its own — a web page, a PDF, an email, a GitHub issue, a calendar note, a CRM record, a transaction description, or a document in a knowledge base.

The user never types anything suspicious. The agent ingests the malicious text itself, as "data." The problem appears the moment an app blends system instructions, the user request, and untrusted data into one model context. The model has no reliable way to tell which is which.

Why this is worse for agents than for chatbots

A chatbot mostly answers. An agent acts: it can read files, call APIs, open tickets, send emails, work with GitHub, query databases, analyze transactions, or run code.

So for a vulnerable agent, the impact of prompt injection equals the worst thing its permissions allow — the worst thing a person or process with those rights could do. If the agent holds permanent API keys, can read .env files, or has production tokens, prompt injection stops being a red-team party trick and becomes credential theft.

It's not just banks: "Comment and Control" in your CI/CD

The same pattern showed up in software pipelines. Research by Aonan Guan and collaborators (Johns Hopkins) described a "Comment and Control" technique: a PR title, an issue body, or an HTML comment became input for an AI agent running in GitHub Actions. The agents could be manipulated into leaking secrets from the runner — typically API keys or access tokens.

Three major agent integrations were affected: Anthropic's Claude Code Security Review, Google's Gemini CLI Action, and the GitHub Copilot Agent. Per the researcher's timeline, bounties were paid by Anthropic ($100) and Google ($1,337); the GitHub report was closed as informative after pushback. At least some of those bounties were low relative to the potential impact. The lesson: to a human, a PR comment is metadata; to an agent, it's prompt context.

The runtime matters too: OpenClaw and Hermes

The risk isn't only the model — it's the agent runtime. The Cloud Security Alliance and Cyera described "Claw Chain," four chained CVEs in OpenClaw; the most critical (CVE-2026-44112, CVSS 9.6) allowed writes outside the sandbox, configuration changes, and a persistent backdoor. Shodan and ZoomEye scans in May 2026 reportedly found roughly 245,000 publicly exposed OpenClaw instances. Notably, the exploit steps looked like normal agent behavior — which is exactly why classic monitoring misses them.

Separately, publicly reported GitHub issues for Hermes Agent describe credential leakage in agent output and a Telegram adapter that could process messages from a removed user into the agent's context before an authorization check. (These are public issue reports, not a confirmed mass incident — but they illustrate the point: for agents wired to Telegram, Slack, or email, the attack surface is every message, attachment, and thread.)

Why you can't fix this with a better prompt

It's tempting to think a smarter model or a clever system prompt solves it. The UK's NCSC warns against that comfort. They argue prompt injection is not like SQL injection: with SQL you can technically separate data from instructions (parameterized queries). With an LLM, everything is tokens in the same context — there's no hard technical boundary between "this is the developer's command" and "this is text from an attacker."

Guardrails like "block ignore previous instructions" are brittle: an attacker can rephrase, split, encode, or hide the instruction in metadata. Blue41 noted the banking app had guardrails — the risk survived because it came not from one isolated string but from the combination: a transaction field + retrieval + the model + a trusted UI + a possible action. OWASP ranks prompt injection as LLM01 and stresses that RAG, fine-tuning, and simple safeguards don't fully solve it.

The only realistic defense is architecture

You can't reliably stop the model from being fooled, so you design a system where a fooled agent can't cause a catastrophe:

• Sandbox and isolation. The agent must not run with the same rights as your app or developer. Separate runtimes for reading the web, working with files, and taking production actions. Containers/VMs, egress restrictions, read-only filesystems, no access to sensitive directories. Coding agents get a workspace with no production secrets.
• Least privilege. Give the agent only the rights one task needs. NCSC's practical rule: when an agent processes data from an untrusted party, its privileges should drop to that party's level. An agent reading an external email shouldn't simultaneously be able to send payments or read secrets.
• A credential broker instead of keys in the agent. Don't put STRIPE_SECRET, GITHUB_TOKEN, or DB_PASSWORD into the agent's environment. Keep the real secret outside the runtime; give the agent a short-lived, scoped token; let a broker/proxy/vault attach the credential only on an allowed outbound request, with logging and host/path/rate limits. (Public examples of this direction include credential-proxy/vault patterns and short-lived workload tokens.)
• Deterministic policy gates. The model may propose an action, but high-risk steps — sending money, changing a password, creating an API key, changing DNS, deploying code, emailing an external recipient, putting a URL into a bank message — must pass a rule outside the LLM, via human approval or a fixed rule engine.
• Context hygiene. Don't dump everything into the model "just in case." Minimize fields, mark external data as untrusted and keep it structurally separate, limit retrieved documents by source and trust, and never feed in raw secrets or whole .env files.
• Output constraints. A bank assistant shouldn't freely generate re-authentication links; a support bot shouldn't mint login URLs without a whitelist; a coding agent shouldn't print env vars. Validate outputs containing URLs, payment instructions, code, or credential-looking strings outside the model.
• Monitoring and incident response. Log what the agent read, where the data came from, what the user asked, which tool calls ran with which scope, and what it answered. Alert on unusual links, attempts to read secrets, overly broad file reads, large exports, or tool calls outside the normal workflow.

A practical checklist for teams

Before you trust an agent in production, answer these:

• What untrusted sources does the agent read?
• What tools can it call?
• Can it see permanent API keys? Can it read .env?
• Can it send emails, change data, create links, or run code?
• Is there an egress allowlist?
• Is there human approval for sensitive actions?
• Do we log tool calls and the retrieved context?
• Can we kill the agent without taking down production?

Bottom line

AI agents aren't bad, and automation isn't the enemy. The danger is deploying an agent as a trusted internal process while letting it read the untrusted outside world and hold production keys. Prompt injection may never be fully eliminated — but you can design a system where a compromised agent simply can't reach anything that matters. The model won't save you. The architecture will.

Sources and further reading