Ask most business owners what makes an AI agent risky and they’ll talk about the model. Will it hallucinate? Will it say something wrong to a customer? Fair questions, but they miss the bigger one. The security agencies of five countries put it plainly in their May 2026 guidance on agentic AI: “Privileges assigned to agents directly determine the level of risk they can introduce.”
Not the model. The permissions.
The difference between a chatbot and an agent
A chatbot answers questions. An agent takes actions: it can move money, grant system access, send data to other services, or delete things. That difference changes the security question entirely. A wrong answer from a chatbot is a model risk. A wrong action from an agent is an operational and cyber risk, and it happens with your systems, your data, and your customers.
The Australian Signals Directorate’s Cyber Security Centre, together with CISA, the NSA, and the cyber centres of Canada, New Zealand, and the UK, published Careful Adoption of Agentic AI Services in May 2026. Their core message fits in one line: an agent’s privileges directly determine what an attacker can do through it.
The confused deputy problem
The guidance describes a pattern worth knowing by name: the confused deputy. In their scenario, an attacker compromises a low-risk tool connected to an agent’s workflow. Because the agent holds more privileges than any single task needs, the attacker inherits them. The agent then modifies contracts and approves payments without triggering a single alert.
The worst part is what the audit log looks like afterward. Every action was performed by the agent, under its legitimate identity, using permissions someone granted on purpose. To your logging system, the attack looks like normal work. That’s what makes detection slow and the damage expensive.
What actually controls the risk
The fix isn’t a better prompt. The Five Eyes agencies are explicit that controls belong in infrastructure, not in instructions. In practice:
- Give each agent its own identity. Not a shared service account, not a borrowed user login. When every agent is “admin@yourcompany,” you can’t tell which one did what, and revoking one means revoking all.
- Least privilege per agent and per tool call. An agent that summarizes invoices doesn’t need payment approval rights. Scope every tool grant to what that specific job requires, nothing more.
- Short-lived credentials. Long-lived API keys are the worst case. Use ephemeral, task-scoped credentials that expire when the task does.
- Deny by default. The Five Eyes guidance says to set configurations to fail-safe by default: agents stop and escalate to a human reviewer in uncertain scenarios, and new capabilities stay blocked until someone deliberately allows them.
Start here
If you have one agent in production or you’re evaluating a vendor’s, ask three questions: what identity does it use, what can those credentials reach, and how fast do they expire? If nobody can answer all three, the agent is running on trust instead of controls.
We build AI agents for a living, and every deployment we do starts with the permission map, not the demo. If you want that same discipline applied to your project, that’s the conversation to have before launch, not after the first incident.