Tool Permissions
Each AI agent gets its own limited set of keys — it can only use the tools its job requires, with credentials that are scoped, temporary, and tracked.
Think of a key ring. The cleaner's ring opens the offices but not the safe; the manager's opens the safe but not the server room. Tool permissions give every AI agent its own ring, so the question is never whether the building can be opened — it is whether this particular agent holds this particular key.
The problem, in plain words
You give an AI agent access to your systems so it can actually help: look up an order, update a record, send a message. The easy way to wire that up is one powerful account whose password everything shares. It works — until it doesn't. Now every agent can do everything, and when something goes wrong, you cannot tell who did what, because everything was done with the same master key. One confused agent, or one leaked credential, and the whole building is standing open.
What we set up
A registry — a central catalog of tools, built on MCP (Model Context Protocol, a standard way for AI agents to use tools) — becomes the locksmith. Each tool declares which permissions (scopes) it needs to run. The registry keeps the map of which agent, working for which client (tenant), holds which scopes. When an agent calls a tool, it does not get the master password: it gets a token — a temporary key limited to exactly that scope, which expires on its own. The real system behind the tool never sees a shared credential. A call outside an agent's scope is rejected before it ever reaches the system, and every time a key is granted or taken away, that change is logged.
How it works, step by step
- Every tool declares its needs
Each tool in the catalog states up front which permissions it requires — no vague 'give it admin and move on'.
- Every agent gets its own ring
The registry records which agent holds which scopes, and on whose behalf. Different agents, different rings.
- A call gets a temporary key
Each tool call carries a scoped, time-limited token instead of a shared password. It opens one door, for a short while.
- Wrong key? The door stays shut
A call outside the agent's scope is rejected at the registry, before it touches the real system.
- Key changes go on the record
Every grant and every revocation is logged, so 'who had what key, when' is a query — not an argument.
What changes for you
Before: any agent that misbehaved — or got tricked — could do anything the shared account could do, and the cleanup started with guesswork. After: a compromised or confused agent can only act within its ring, the blast radius is small by design, and an audit answers itself from the log. Adding a new agent means deciding which keys it gets, out loud, instead of inheriting everything by default. What it won't do: it won't judge whether a permitted action is a good idea. An agent with the refund key can still issue a refund at the wrong moment — that is what human approvals and audit trails are for.