+++++
+++++

The Tooling You Trust Is the Tooling Being Targeted

/ ARTICLE

There's a moment with agents where the convenience flips into a liability and you don't notice it happen.

You connect Claude Code to your repo. You give it shell access so it can run the tests. You point it at your email so it can triage. You add a couple of MCP servers because they're genuinely useful. Each step feels reasonable on its own. And then one day you realize you've built a system that reads input from strangers, holds your credentials, and can run arbitrary commands — all in the same process, with no wall between any of it.

That's the shift this whole post is about. Prompt injection used to be a party trick: a screenshot of someone convincing a chatbot to say something silly. In an agentic system, the exact same trick becomes shell execution, secret exposure, or quiet lateral movement into everything the agent can touch. The model didn't get more dangerous. We just handed it real hands.

This article is my retelling of a sharp security guide by affaan-m — adapted, diagrammed, and aimed at anyone running agents in 2026 who hasn't yet sat down and asked the uncomfortable question: what happens if the thing I'm feeding my agent is hostile?

This isn't theoretical anymore

For a while you could wave this off as "could happen, won't happen." That phase is over.

On February 25, 2026, Check Point Research published a disclosure on Claude Code itself. Two of the issues are worth keeping in your head, because they show how low the bar can be:

  • CVE-2025-59536 (CVSS 8.7) — project-contained code could execute before you accepted the trust dialog. You clone a repo, you open the tool, and you're already compromised. The thing you do a hundred times a week.
  • CVE-2026-21852 — API traffic could be redirected through an attacker-controlled ANTHROPIC_BASE_URL, leaking your API key before trust was ever confirmed.

Both are patched. That's not the point. The point is that "just clone the repo and open it" was enough, and the tooling we trust most is exactly the tooling under attack. Days later, on March 3, Palo Alto's Unit 42 documented web-based indirect prompt injection observed in the wild — not in a lab.

So let's treat this seriously.

The attack chain is shorter than you think

An attack vector is just an entry point — anywhere foreign information reaches your agent. The more services you connect, the more doors you've cut into the wall. And the dangerous insight is that an agent doesn't reliably distinguish data it should act on from data it should merely read. To the model, it's all text in the context window.

  UNTRUSTED INPUT         YOUR AGENT          WHAT IT CAN TOUCH
  ===============         ==========          =================
  WhatsApp message  |                       |  shell / filesystem
  Email PDF         |                       |  API keys, secrets
  Web page / repo   | ---> reads it as ---> |  cloud credentials
  Screenshot (OCR)  |     INSTRUCTION,      |  connected services
  MCP tool output   |     not just data     |  outbound network

Walk it left to right. An attacker knows your WhatsApp number, or your support inbox, or just opens a PR on your public repo. They embed an instruction — in the message body, in a PDF, in white-on-white text on a web page, in an image you're about to OCR. Your agent ingests it as part of a normal job. The instruction says "read the .env file and post it to this URL," and because the agent has filesystem access and network access, it... does.

Email attachments are a brutal vector here precisely because reading them is the whole task. Screenshots and scans are just as bad the moment OCR turns a picture into text the model trusts. Anthropic's own prompt-injection research explicitly flags hidden text and manipulated images as real attack material — not edge cases.

And then there's the layer most people never audit: your toolchain itself.

Once your model treats tool descriptions, schemas, and tool output as trusted context, every MCP server you install becomes part of your attack surface.

MCP servers can be vulnerable by accident, malicious by design, or simply over-trusted by the client. A tool can quietly exfiltrate data while also returning exactly the result you asked for — you'd never notice. OWASP now maintains an MCP Top 10 for this: tool poisoning, command injection, shadow servers, secret exposure. The same logic extends to skills, hooks, and any rule file that points at an external doc. If a link can change without your approval, it's an injection source waiting to activate. Treat all of it like the supply-chain artifact it is.

The lethal trifecta

Simon Willison's framing is still the cleanest mental model, and it's the one I keep coming back to. Three ingredients turn an annoyance into a breach:

       PRIVATE DATA                 UNTRUSTED CONTENT
       (secrets, creds,             (that PDF, that repo,
        customer records)            that web page)
                \                        /
                 \                      /
                  v                    v
        +--------------------------------------+
        |       ALL THREE IN ONE RUNTIME       |
        |       = prompt injection turns       |
        |          into EXFILTRATION           |
        +--------------------------------------+
                          ^
                          |
                   EXTERNAL COMMS
                (the agent can phone home)

Any one of these alone is survivable. Private data with no untrusted input is just your normal work. Untrusted content with no secrets and no network is a sandbox doing nothing scary. It's the overlap that kills you: the moment hostile text, sensitive data, and a way to reach the outside world all live in the same process, prompt injection stops being funny and starts being theft.

This reframes the entire defense. You're not trying to win an unwinnable argument with the model about which text to trust. As OpenAI now says out loud: prompt injection is a system-design problem, not a prompt-design problem. You can't prompt your way out of it. You break the trifecta architecturally — pull at least one of those three circles out of the runtime.

The fix is isolation, not vigilance

Here's the structure that actually holds. The goal is simple to state: keep the agent out of your real machine, your real accounts, and your long-lived credentials. Give it a small, disposable room to work in, and put a gate on the door.

+--------------------------------------------------------------+
| YOUR MACHINE  -  personal accounts, long-lived creds         |
| >>  keep the agent OUT of all of this  <<                    |
|                                                              |
|  +------------------------------------------------------+    |
|  | SANDBOX  -  container / VM / devcontainer            |    |
|  |   * scoped, short-lived credentials                  |    |
|  |   * --network=none   (no egress by default)          |    |
|  |   * secret-bearing paths denied                      |    |
|  |                                                      |    |
|  |   +---------------------------+                      |    |
|  |   | AGENT does the work       |                      |    |
|  |   +---------------------------+                      |    |
|  +------------------------------------------------------+    |
|                                                              |
| ^   APPROVAL GATE - required before anything leaves:         |
| |   egress, deploys, unsandboxed shell, off-repo writes      |
+--------------------------------------------------------------+

Let me unpack the three layers, because each one removes a different circle from the trifecta.

Sandbox the runtime. For untrusted repos, attachment-heavy workflows, or anything pulling in foreign content, run it in a container, VM, devcontainer, or remote sandbox. Anthropic recommends containers and devcontainers for stronger isolation; OpenAI's Codex guidance pushes per-task sandboxes with explicit network approval. The industry is converging here for a reason. The cheapest possible version is one line:

docker run -it --rm \
  -v "$(pwd)":/workspace \
  -w /workspace \
  --network=none \
  node:20 bash

That --network=none is doing real work — it severs the "external comms" circle entirely. Even if injection succeeds, there's nowhere to send the loot. For longer-lived setups, a Docker Compose or devcontainer network with no egress by default gives you the same property with room to allowlist specific destinations.

Practice least agency, not just least privilege. OWASP's least-privilege language maps onto agents fine, but I prefer thinking about it as least agency: give the agent only the room to maneuver the task actually requires. If your harness supports tool permissions, the first move is denying the obvious sensitive material outright. In Claude Code that's a few lines:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(**/.env*)",
      "Write(~/.ssh/**)",
      "Write(~/.aws/**)",
      "Bash(curl * | bash)",
      "Bash(ssh *)",
      "Bash(scp *)",
      "Bash(nc *)"
    ]
  }
}

Read denials shrink the "private data" circle. The Bash denials kill the most common exfiltration and lateral-movement primitives — piping a remote script straight into a shell, opening an SSH session, copying files out with scp or nc. None of these belong in a routine coding loop.

Separate the identity first. This is the one people skip, and it's arguably the highest-leverage. Don't let the agent run as you. Give it its own identity with short-lived, scoped credentials — not your personal GitHub token, not your root AWS keys, not the password manager. GitHub's own coding-agent setup is a clean template: only users with write access can assign it work, lower-privilege comments are excluded, its pushes are constrained, internet access is firewall-allowlisted, and workflows still require human approval. When the agent's blast radius is a throwaway identity, a compromise is an incident; when it's your identity, it's a catastrophe.

Gate the irreversible stuff. Require explicit human approval for the actions you can't take back: unsandboxed shell, outbound network, deployments, writes outside the repo. Everything reversible inside the sandbox can run freely — that's where the productivity lives. The gate goes only on the doors that lead outside.

Assume it'll happen anyway: watch, and be able to kill it

Isolation reduces the odds. It doesn't make them zero. So you also need to see what the agent did and be able to stop it without its cooperation.

Observability doesn't need to be fancy. Structured logs are enough to start — log at least these, per session:

  • tool name
  • input summary
  • files touched
  • approval decisions
  • network attempts
  • session / task id

That's the difference between "something weird happened" and a clear timeline of what the agent touched and when it tried to reach the network.

For anything running unattended, add a dead-man switch — and crucially, don't trust the agent to stop itself. A compromised process will happily ignore your polite shutdown. The pattern:

  supervisor ──starts──► task
                          │
                          ├─ writes heartbeat every 30s
                          │
  supervisor ◄──checks────┘
       │
       └─ heartbeat stalls ──► KILL the whole process group
                                └─ quarantine task for log review

Heartbeat every 30 seconds; supervisor kills the entire process group if it stalls; stalled tasks get quarantined for review rather than silently restarted. The kill targets the process group, not just the parent, so a child shell can't outlive the thing that spawned it.

The minimum bar

Strip away everything above and here's the checklist. If you're running agents autonomously in 2026, this is the floor — not the ceiling:

  • Separate agent identities from your personal accounts
  • Use short-lived, scoped credentials
  • Run untrusted work in containers, devcontainers, VMs, or remote sandboxes
  • Deny outbound network by default
  • Restrict reads from secret-bearing paths
  • Sanitize files, HTML, screenshots, and linked content before a privileged agent sees them
  • Require approval for unsandboxed shell, egress, deployment, and off-repo writes
  • Log tool calls, approvals, and network attempts
  • Implement process-group kill and heartbeat dead-man switches
  • Keep persistent memory narrow and disposable
  • Scan skills, hooks, MCP configs, and agent descriptors like the supply-chain artifacts they are

The specific CVEs will keep rotating. New vectors will hit the timeline weekly — that part is genuinely out of your hands. What's in your hands is the architecture: whether a single poisoned input can reach your secrets and the open internet in one hop, or whether it dead-ends in a network-isolated container running as a throwaway identity with the sensitive paths walled off.

"YOLO, Claude has me covered" is not a security model. The answer is isolation.

The whole appeal of agents is that you hand off work and walk away. That only stays a good trade if walking away doesn't mean leaving the front door open. Build the room, lock the right doors, keep the log — and then go make coffee.