Every agent tutorial ends in the same place. You wire up a model, give it a couple of tools, watch it query a database or book a meeting, and it feels like magic. Then you ship it. What almost none of those tutorials mention is what you just did from a security standpoint: you handed an autonomous process your credentials and pointed it at production.
I want to talk about that gap, because it's the part that turns a slick demo into an incident.
An agent is a new identity, so treat it like one
When you build an agent, you're not really adding a feature. You're adding a user. One that authenticates once, never sleeps, and does whatever the model decides in a loop. If you hand it your own token to "just get it working," every action it takes is now indistinguishable from you in the logs, with all of your access behind it.
Give each agent its own identity from day one. Its own service account, its own scoped token, its own name in the audit trail. When something goes sideways at 2am, you want the log to say it was the invoice-agent and show you exactly what it could reach, not leave you squinting at a line that looks like you did it yourself.
Scope the tools, not just the prompt
The dangerous permissions live in the tools you give the agent, not in the wording of the system prompt. A model with a read-only database tool scoped to a single table is a completely different risk from the same model holding a tool that runs arbitrary SQL. Same agent, wildly different blast radius.
So before you connect a tool, ask what the worst possible call to it looks like. If your send-email tool can email anyone, a confused or manipulated agent can spam your entire customer list. If your database tool can drop tables, one bad decision is catastrophic instead of annoying. Give each tool the narrowest capability the job needs. Read-only by default. One resource, not the whole account.
One number makes this concrete: IBM's 2025 breach report found that 97 percent of organisations that suffered an AI-related breach lacked proper AI access controls. The failure mode is almost always over-permissioned access, not a genius attacker.
Assume the model will get talked into something
This is the one developers underrate. Your agent reads external content: a web page, an email, a support ticket, a user message. Anyone who controls that content can bury instructions in it, and the model can't reliably tell your instructions apart from the ones hiding in the data it's processing. That's prompt injection, and it has sat at the top of the OWASP list of LLM risks since the list existed.
You can't fully prevent it, so build as if it will happen. The rule that saves you: never let the same agent both ingest untrusted input and hold powerful, irreversible capabilities. If an agent reads arbitrary web pages, it should not also be able to move money or delete records. Split those into separate agents with separate access, so a hijack in the one that reads can't reach the tools that do damage.
Put a human in front of the one-way doors
Autonomy is fine for reversible actions. Let the agent draft, sort, summarise, query, retry all day. For the things you can't undo, sending, paying, deleting, publishing, deploying, add a human approval step. Yes, it's less magical. It's also the whole difference between an agent that makes a mistake and an agent that makes a mistake you can't take back.
A cheap pattern that works: the agent proposes the irreversible action, a human approves it in Slack or a small dashboard, then it proceeds. You keep almost all of the speed and cap the downside.
The short version
If you're building agents, most of the security work isn't AI-specific and isn't glamorous. Give the agent its own identity. Scope every tool to the minimum. Keep untrusted-input agents away from your dangerous capabilities. Gate the irreversible actions behind a human. Do those four and you've covered the majority of what actually goes wrong in production.
The demo is the easy part. The access model is the product.
Top comments (0)