Least-privilege tool permissions for AI agents: a design guide
Design narrow, per-tool permissions and credentials so an AI agent can only do the specific jobs you intended, even when something goes wrong.
This is for CTOs, IT heads and engineering leads wiring AI agents into ERP, CRM, ticketing or finance systems. The fastest way to build an agent is to hand it one powerful API key and a generic tool that can call anything. That works in a demo and becomes a liability in production, because any mistake or manipulated instruction runs with full access. This post shows how to design tool permissions so the blast radius of any single failure stays small and visible.
An operations team builds a helpdesk agent that can look up orders. To save time, the developer gives it the same integration user the ERP team uses for batch jobs, which can also edit prices, cancel invoices and export the customer master. The agent only needs to read order status, but nothing in the design stops it doing far more if a prompt or document steers it.
Audits then become guesswork. Logs show the integration user changed a record, but not whether a person, a batch job or the agent did it, or on whose behalf. When the security team asks what the agent can actually do, nobody can answer without reading code. Least privilege was a principle on paper, not a property of the system.
A freight forwarder in Mumbai launched an agent to answer customer questions about bookings and invoices. The first version used a shared integration login that could also amend invoices and change consignee details. Before go-live, the security lead rebuilt the tool set: four read tools for booking status, invoice copy, container events and document list, each scoped to the logged-in customer's account; and one write tool to raise an amendment request, which created a ticket rather than editing data. After the change, the agent answered the same questions, the audit log showed which customer each call served, and the internal audit review of the agent took an afternoon instead of a week.
Can we use one service account if we filter access in our own code?
It is possible, but riskier, because any bug in your filter exposes everything the account can reach. Prefer delegated user tokens or per-role accounts, and keep your own filter as a second layer, not the only one.
How many tools should an agent have?
As few as the jobs require. A smaller, well-named tool set is easier for the model to use correctly and easier for your team to audit. Add tools only when a real, approved job needs one.
What about legacy systems that only support one admin login?
Put a thin internal API in front of the legacy system that exposes only the narrow operations the agent needs, with its own authorisation checks. The agent calls that layer, never the admin login directly.
Who should approve new agent tools?
The system owner confirms the business need, and the security owner approves scopes and limits. For tools that move money or change customer data, add the finance or data protection lead as a reviewer.
Want this fixed in your business?
Send the workflow. You get a scope and a fixed price within two working days — or a straight answer that it isn't a fit.