If you've shipped an AI agent to production in the last year, you've probably already felt the gap between "this works in the demo" and "this is safe to run unsupervised." Agentic AI systems that plan, call tools, and take actions with minimal human input breaks a lot of assumptions that traditional app security is built on. Here are five mistakes developers keep making, and what to do instead.
1. Treating the agent's credentials like a service account
It's tempting to give your agent one API key with broad scope because it's simpler to wire up. Don't. An agent's permissions should be the intersection of what the current task needs and what it's allowed to touch not a static grant that covers every possible future task.
In practice: issue short-lived, scoped tokens per task. Separate read access from write/send access by default, and require an explicit elevation path for anything destructive. If your agent can read a database and also send emails, that's two separate credentials, not one.
2. Not distinguishing user input from ingested content
Most developers harden against a user typing something malicious. Far fewer think about indirect prompt injection where a malicious instruction is hidden inside a webpage, PDF, or email the agent reads, and the agent executes it without the user ever seeing it. This is called out explicitly in the OWASP Top 10 for LLM Applications (LLM01), and it's currently one of the least-solved problems in the space.
Practical mitigation: treat all ingested content as untrusted data, not instructions. If your agent architecture doesn't clearly separate "system instructions" from "content the agent is processing," that's a design flaw worth fixing before launch.
3. Logging outputs but not decisions
Standard application logging captures requests and responses. That's not enough for an agent. You need visibility into why the agent chose a particular tool call the reasoning trace, not just the final action. Without that, incident response turns into guesswork.
Set up anomaly detection on action sequences, not just individual calls. An agent that normally only reads a calendar suddenly trying to send an external email is a signal worth flagging automatically, even if the individual API call looks legitimate in isolation.
4. Skipping adversarial testing before launch
Unit tests and integration tests won't catch prompt injection. You need actual red-teaming deliberately trying to manipulate your agent with crafted inputs and poisoned content before it ever touches production. MITRE ATLAS is a solid reference for real adversarial tactics used against ML/AI systems; it's worth structuring your test cases around it rather than improvising.
5. No kill switch for irreversible actions
This is the one that bites hardest. If your agent can execute a financial transaction, delete data, or send a mass communication, there needs to be a hard-gated human approval step and a reliable way to immediately halt the agent if something goes wrong. "We'll add a kill switch later" is a sentence that shows up in a lot of postmortems.
The takeaway
None of this is exotic security theory it's the same instincts good developers already have (least privilege, input validation, observability, testing) applied to a system that behaves less predictably than the code you're used to writing. The teams getting burned right now aren't ignoring security; they're applying a pre-agentic security mental model to a fundamentally different kind of system.
I wrote a longer breakdown of the full risk landscape and defense framework here, building on some of the themes from this piece:
If you're building agents right now, I'd genuinely like to hear what's tripped you up drop it in the comments.
Top comments (0)