Hey there,
I keep seeing prompt injection described as a clever string someone types into a chat box. That is too small a frame for the systems we are building. An agent can encounter instructions anywhere it can read, and the dangerous moment is when untrusted data becomes a command.
Chris’s Take
Imagine you type a prompt, your agent goes off to work on it, and performs an action that falls outside the prompt's scope. The agent may have encountered this instruction in a tool result, a README file, an email (we’re all using agents to monitor our inboxes now, right?), or package metadata. End result — the agent takes an action unauthorized by you, but on your behalf.
For more context on prompt injection, look at OWASP LLM01:2025 Prompt Injection and the OWASP LLM Prompt Injection Prevention Cheat Sheet.
There is a nuance here worth understanding: direct vs. indirect injection. Direct injection enters via the user, while indirect injection arrives through external content. Prompt injection is broader than jailbreaking, and it could be intentional or accidental. The weakness is that instructions and data share the same channel, and the models do not preserve the distinction among data, suggestions, policy, and commands.
A system prompt can guide behavior, but it’s not the trust boundary. The trust boundary that we need isn’t there. We cannot rely upon the system prompt and the model to enforce authorization. (OWASP LLM07:2025 System Prompt Leakage)
This isn’t a new pattern that we’ve never seen before. We’re talking about the confused deputy pattern again, as what’s old is often seen as new again. In this case, either the attacker or an unintentional piece of content provides instructions for the agent to follow, and the agent uses its inherited authority to attempt to carry out the action. These are pieces of the OWASP Agentic Top 10, specifically ASI01: Agent Goal Hijack, ASI02: Tool Misuse and Exploitation, and ASI03: Identity and Privilege Abuse. At the tool layer, OWASP MCP Tool Poisoning provides a deeper explanation of this problem. OWASP LLM06:2025 Excessive Agency is a nice category that summarizes the macro-level problem we’re facing.
How do we mitigate indirect prompt injection? (Caveat: separating and labeling untrusted data helps, but it’s not foolproof.)
Minimize available tools and their functionality: the CLI tools (claude, codex, grok) can control which tools the agent can access. Anecdotally, I’ve heard that most people are running these things with the defaults, without task-specific security settings. Claude and Grok do per-tool allow/deny rules, while Codex leans on sandbox and approval modes rather than per-tool allow lists. For WebFetch, Claude and Grok scope domains per-tool; Codex does it at the network layer. The actual gap is that defaults expose the full tool surface gated only by approval prompts — approval fatigue and opt-in bypass modes are what erode it.
Use narrowly scoped identities and user-context authorization: a good security principle to separate the agent by identity and authorization context, but not very practical when coding via a CLI. Requires separate CLI definitions for different tasking.
Avoid open-ended shell or URL-fetching tools: tie this to minimizing the tooling available to the agent, and watch closely as the agent operates. Not the answer you want if you’re scaling a software factory, but in my not-so-humble opinion, we aren’t there yet on software factories.
Enforce deterministic authorization and complete mediation in downstream systems: authorization is often preconfigured at agent startup, so we need to break that pattern and perform an authorization check on what the agent is doing when it tries to act, rather than having it baked in at startup. We need a gateway.
Validate proposed actions against the user’s original intent: this requires integration into the planning loop the agent goes through and is not easily accessible with existing tooling. You need a plan-loop checker that can detect when the model has drifted outside the scope of the original prompt.
Record instruction provenance and tool activity; an audit log of agent activities should be kept locally at a minimum, and ideally off-box and stored somewhere it can’t be changed.
Require human approval for consequential actions: human-in-the-loop is something I keep coming back to — we have to be in the loop when agents start to drift. This could be paired with the gateway to give us visibility into drift in tool calls and, in the planning phase, to match a bad idea to a recorded access request.
Permissions constrain what an agent can do, review catches unsafe output, telemetry shows what actually happened, and interpretation influences what the agent believes. The model remains an untrusted decision-maker; the enforceable boundary belongs in the surrounding application, tools, identities, and downstream systems.
Worthwhile Security Reads
Five reads on how agents interpret untrusted material, evade evaluation boundaries, and turn minor instruction failures into major security incidents.
Prompt Injection Through Tool Output — Tool results can carry instructions an agent treats as authoritative. Chris’s take: Prompt injection has moved far beyond the chatbot. A trust boundary must exist between the agent and the tools that it relies upon.
Anthropic’s Cybersecurity Evaluation Incidents — Misconfigured evaluations gave models access to real systems. Chris’s take: “Claude was told it was operating in a simulation without internet access, but, due to a misconfiguration, it was mistakenly connected to the open internet.” This screams for a containment layer that exists outside the frontier model providers. If they can’t get containment right when playing with super weapons, how can the average Enterprise?
Don’t Like LLMs? You’re Not Alone. — A skeptical look at what LLMs change in software work and what they do not. Chris’s take: Fowler is opinionated and argues for using LLMs; he just doesn’t like the way they respond to humans.
Hacking OpenAI: What the Attack Surface Looks Like — A case study in unexpected paths through tools, identities, and infrastructure. Chris’s take: I was listening to a member of staff at OpenAI on a podcast describing how they had so many folks working on cybersecurity that they were close to finding all their vulns. Then a gang of bug bounty hunters enters the chat room.
Microsoft’s AI Code of Conduct — A governance response to increasingly capable systems. Chris’s take: I’d like to see more of these types of stands from big companies influencing AI. We have a chance to influence the standard, as this draft is now open for comment over the next six weeks.
Podcast Corner
Application Security Podcast
AI Pen Testing Killed Traditional DAST
James Berthoty returns to examine contextual payloads, autonomous testers, token economics, and the safety limits of AI-native penetration testing.
Security Table
Why AI Cheats To Win
The Security Table examines reward hacking after an Anthropic model published a malicious package to the real PyPI registry during what it believed was an isolated test.
Where to Find Chris
I’ll be at OWASP Global AppSec USA in San Francisco, November 5–6. I’m moderating a keynote debate and recording a live episode of The Application Security Podcast from the conference. If you’re there, come say hello—and join us for the debate and live recording.
What did I miss this week? Hit reply and tell me.
— Chris
