AI Agent Security: Limit the Blast Radius

An AI agent that can only answer questions has a small security problem. An AI agent that can send email, update records, refund a customer, or open a pull request has a much larger one — and most teams are still defending it with the same tool: a filter on the prompt.

That filter is the weakest layer in the stack. It is the one everybody builds first.

We’ve shipped agentic features into production for SaaS, fintech, and B2B products, and the pattern that keeps failing isn’t a model problem. It’s an architecture problem. The agent was given more access than the task required, and nothing sat between the model’s decision and the action.

Prompt Filtering Is the Weakest Layer You Can Build

The instruction doesn’t have to come from your user

Everyone pictures prompt injection as a user typing “ignore your previous instructions.” That’s the easy case. The real case is indirect: the agent reads a support ticket, a scraped page, a shared document, a calendar invite — and that text contains instructions. The model has no mechanism for separating your instructions from content it retrieved. Both arrive as tokens.

So any content your agent reads is untrusted input, including content from inside your own company. A ticket submitted by a customer is attacker-controlled text that your agent will read with your permissions.

Blast radius scales with access, not with model quality

A better model does not shrink the damage. If an agent holds a credential that can write to your production database, one manipulated instruction reaches everything that credential reaches. Prompt injection has sat at the top of OWASP’s LLM risk list since 2025, and the incidents disclosed through 2026 share one shape: the agent had broad permissions, and nothing checked the action before it ran.

The useful question isn’t “can this be injected?” Assume yes. The question is what an attacker gets when it works.

Scope Permissions Before You Write a Single Filter

Give each agent its own identity

Reusing your application’s service account is the single most common mistake we see. Every agent should have its own credential, scoped to the specific tables, endpoints, and buckets its task needs. When something goes wrong, you want to revoke one identity — not rotate the key your whole platform runs on.

This is boring infrastructure work, and it is worth more than any filter you will write.

Split the read path from the write path

Grant read access by default. Make every write, delete, send, or spend an explicit grant that somebody signed off on. In practice this means the agent that summarises tickets cannot close them, and the agent that drafts replies cannot send them. Two narrow agents beat one capable one, and they’re easier to reason about when you’re scoping the AI features in your product.

Gate the Actions You Can’t Undo

Sort tools by reversibility

Take your tool list and put every entry in one of two columns: cheap to undo, or not. Tagging, drafting, searching, summarising — reversible, run them unattended. Issuing a refund, emailing a customer, deleting a record, merging code, calling a paid API in a loop — not reversible, or not cheaply.

That split, not a confidence score, is what should decide where a human sits in the loop.

Make the approval specific

A dialog that says “the agent wants to update a record — approve?” trains people to click yes. Show the actual payload: this record, these fields, these values, this recipient. If the approval screen doesn’t contain enough detail for a reviewer to catch a bad action, it isn’t a control. It’s a formality that transfers blame.

Log Decisions, Not Just Outputs

Capture the whole chain on every tool call

Store the tool name, the arguments, the identity used, the retrieved context that informed the decision, and the result. Outputs alone tell you what the agent said. Arguments and context tell you why it acted — which is the only thing that helps at 2am when a customer reports something strange. This is the same observability discipline any production AI feature needs, applied to actions instead of text.

Watch for permission drift

Agent permissions grow. A scope gets widened for a demo, a tool gets added during a sprint, and nobody removes either. Put a recurring review on the calendar — quarterly is enough — and check every agent’s grants against what it actually calls in the logs. Anything unused gets revoked.

A Baseline for Your First Agent in Production

The five things to have in place before you ship

• A dedicated service identity per agent, scoped to the minimum resources its task touches
• Read and write paths separated, with writes granted explicitly rather than inherited
• A reversibility map of every tool, and a human checkpoint on everything in the irreversible column
• Approval screens that show the exact payload, not a generic prompt
• Full logging of tool calls, arguments, and retrieved context, with a quarterly permission review

None of this depends on which model you’re using, and none of it breaks when the next one ships. Filters and classifiers sit on top of this foundation — they’re a good addition and a terrible substitute.

If you’re moving an agent from prototype to production and want the permission architecture reviewed before it touches real data, our team does this work as part of every AI build. We’ve also written about what checks AI-generated code and the guardrails that keep LLM output safe, which cover the layers above this one.

Yaniv Amrami is founder of quickdev. He has helped Israeli startups design and ship agentic AI features across SaaS, fintech, and B2B products since 2017.