Least Privilege for AI Agents: Tools, Data and Tenants

A useful agent should feel like a colleague who knows their job, not like someone carrying every key in the building. Giving a broad service account to an agent and asking it to “be careful” is not a security boundary. If the agent is confused or manipulated, the permissions around it are what limit the damage.

Start with the person and the job

Every tool call should carry the authenticated user, tenant, purpose, and workflow. The server must check those values before returning a record or changing one. Never rely on a tenant ID that the model has typed into a request. Resolve it from the authenticated session and compare it with the object being requested.

Separate a suggestion from an action

Reading a customer record, drafting a reply, sending the reply, approving a change, and deleting data are not one capability. Give the agent narrow operations with fixed fields rather than a generic database tool or an unrestricted HTTP client. Begin with read-only access. Add a write only when the workflow needs it, and keep its destination, batch size, and time window small.

Keep the keys behind the counter

Provider credentials belong in a protected server environment or secrets manager. The agent should receive the safe result of a tool call, not the key used to make it. Short-lived credentials, rotation, and easy revocation matter more than a clever instruction telling the model not to reveal a secret.

Try the uncomfortable request

Ask what happens when a user requests another tenant’s record, a document tries to change the task’s purpose, a tool receives an unexpected destination, or access is revoked while a job is waiting. Review the permission graph when a new tool is added. Least privilege does not make an agent timid; it gives the agent room to help without giving a mistake room to become a breach.