There's a quiet design mistake buried in most AI agent deployments: capability and scope share a key.
The agent is "the refund agent," so it can refund. The agent is logged in, so it can see customers. One identity, two jobs. Which means the moment something goes sideways — a prompt injection, a bad tool call, a confused chain — the agent's role becomes a license to roam the database.
Splitting it changes the physics:
– What the role can do (refund up to $500, send from approved templates, escalate) lives on the agent.
– What this task can touch (this customer, this case, this session) is minted per task and dies with it.
Neither side can cover for the other. A compromised role can't reach data it wasn't handed. A leaked task token can't perform actions the role doesn't have. The worst case stops being "agent went rogue across the business" and becomes "one task did the wrong thing inside its own sandbox."
This is why so many pilots stall at security review. Reviewers are being asked to trust a non-deterministic system that writes its own code at runtime. They're right to refuse. The fix isn't more trust — it's an architecture where trust isn't the control surface.
If you can't draw, on one page, where capability ends and scope begins for each of your agents, you don't have AI security. You have hope with a logo on it.
Where does that line sit in your stack today?
Learn more: https://leverageai.com.au/wp-content/media/ebooks/SiloOS.html
Discover more from Leverage AI for your business
Subscribe to get the latest posts sent to your email.