---
title: "Prompt Injection Isn't the Problem With AI Agents. Blast Radius Is."
description: "You can't filter your way out of prompt injection, it's an open problem. What you can control is what happens after an agent gets manipulated. Most teams design for the wrong half."
author: Subhadip Saha
published: 2026-09-27
updated: 2026-09-27
canonical: https://thatdevguy.in/blogs/ai-agent-blast-radius-not-guardrails
tags: ["AI", "Security", "Backend", "Agents"]
---
# Prompt Injection Isn't the Problem With AI Agents. Blast Radius Is.
I gave an agent shell access, file system access, and a database connection last month, "just to get the demo working." It worked great, for the demo. Then I sat there afterward staring at the permissions and realized I'd have to explain to someone, with a straight face, why a chatbot could run `DROP TABLE` if the wrong string showed up in a webpage it happened to read.
That's the part of agent security most teams skip past. Everyone's racing to stop prompt injection. Almost nobody's asking what happens when it doesn't work.
## Prompt Injection Isn't Going Away
Direct injection, "ignore your previous instructions", is the easy case, and even that isn't fully solved. Indirect injection is the real problem: an agent reads a webpage, a PDF, a support ticket, an email, a tool's output, and buried in that content is an instruction that looks exactly like the ones you gave it on purpose. The model has no reliable way to distinguish "the user told me to do this" from "some text I ingested told me to do this," because by the time it's all tokens in a context window, it's just tokens in a context window.
A UN science panel looked at recent AI agent breakouts this year and, notably, didn't frame them as a bug to patch. They framed it as a control problem. That's the right frame. You don't "fix" prompt injection the way you fix a SQL injection vulnerability, with parameterized queries and a linter rule. There's no equivalent structural fix yet, and there might not be one, because the thing you're trying to filter is natural language, and natural language doesn't have a clean boundary between data and instructions the way a query string does.
If your security plan for an agent is "we have good prompts that tell it not to do bad things," you don't have a security plan. You have a suggestion.
## The Question That Actually Matters
Stop asking "how do I stop this agent from being manipulated." Start asking: "if this agent does exactly what an attacker wants, right now, what's the worst thing that happens?"
That's blast radius. It's the same question we've asked for decades about any process running with elevated permissions, we just stopped asking it the moment "AI" showed up in the architecture diagram, because it felt like a new category of problem instead of an old one wearing a new coat.
An agent that can read your codebase, browse the web, and also push to your production database is not three separate capabilities. It's one capability: "do anything an attacker wants, using your production database, triggered by content the agent reads off the open internet." Design accordingly.
## What Bounding Blast Radius Actually Looks Like
**Scope credentials per agent, not per team.** An agent doing code review doesn't need write access to anything. An agent triaging support tickets doesn't need your Stripe key. If an agent has one job, it should have exactly the permissions that job requires and nothing left over "in case it's useful later."
**No agent gets direct production database access.** Put a service in between that only exposes the specific operations the agent actually needs, read-only where possible, parameterized and allow-listed where it isn't. If the agent's compromised, the attacker inherits the service's narrow interface, not your schema.
**Destructive operations get a human in the loop.** Deleting data, sending money, sending external communications on your behalf, anything you'd want a second opinion on if a junior engineer did it manually, should require the same second opinion when an agent does it. This is the single highest-leverage control and the one teams skip first because it slows down the demo.
**Sandbox execution, don't trust it.** If an agent runs code, that code runs in an environment that assumes it's hostile, not one that assumes it's fine because you wrote the prompt. Ephemeral, isolated, no access to anything outside what that specific task needs. Firecracker microVMs, containers with dropped capabilities, whatever your stack supports, the point is the same: assume breakout, and make breakout boring.
**Log everything the agent does, not just what it says.** The model's response is not the audit trail. The actual tool calls, actual API requests, actual file writes, those are the audit trail. If you can't reconstruct exactly what an agent did after the fact, you can't investigate an incident, you can only speculate about one.
A useful test: if you replaced your agent's model with a malicious human contractor who had exactly the same credentials and tool access, what's the worst week they could have? If the answer scares you, the model isn't your exposure. The permissions are.
## This Isn't Pessimism, It's Just Ordinary Engineering
None of this is agent-specific wisdom. It's the same least-privilege, defense-in-depth thinking that's applied to every other system with a large attack surface and an untrusted input stream. The reason it feels new is that agent demos get built fast, permissions get granted generously to avoid friction, and by the time something's in production nobody wants to be the one who slows it down to ask uncomfortable questions.
Prompt injection is going to keep happening. Treat that as a given, not a risk you're trying to drive to zero. The teams that get burned aren't the ones whose agents got manipulated, that's going to happen to everyone eventually. It's the ones who never asked what the manipulated agent was actually capable of doing.