Least privilege for AI agents: a practical permission map

Start with one job, not an all-purpose assistant

A small team often starts with a broad service account because it makes the first demonstration easier. Before production, describe one concrete job: “Read the current customer's support tickets and prepare a reply for a staff member.” That sentence contains useful limits. It names a customer boundary, a data type, a read operation, and a draft output. It does not require sending mail, changing billing, or deleting tickets.

OWASP's excessive agency guidance distinguishes unnecessary functions, excessive downstream permissions, and excessive autonomy. Use those three questions when reviewing a connector. A tool can expose the right function while using a backend identity with far too much access.

Write a permission map that an engineer can check

For the synthetic support workflow above, a starting map could look like this. These are proposed design choices, not a description of a tested deployment.

Add an owner and an expiry or review date to each grant. A temporary export tool should not silently become a permanent capability. Record why the workflow needs the permission so the next person can distinguish a deliberate grant from a convenient development default.

Keep identity and resource scope together

Do not let a model-supplied customer identifier establish authorization. The application should derive the authenticated user and tenant from trusted session context, then verify that the requested ticket belongs to that scope. A plausible identifier is still just an identifier.

Consider two synthetic customers, Cedar and Maple. A Cedar user asks for ticket T-104. The service finds that T-104 belongs to Maple. The correct result is a denial before ticket content enters the model context. Returning the ticket and asking the model to ignore it has already crossed the data boundary.

OWASP's authorization guidance supports default denial and permission checks on every request. Apply that rule to background jobs, retries, exports, and direct API routes as well as the visible chat interface.

Separate reading, drafting, and acting

A workflow can be useful before it has authority to cause external effects. Let the agent prepare a draft using its limited reading role. A separate executor can handle approved sends. Keep the sending credential out of the drafting process if the draft process does not need it.

This separation is especially useful when a provider offers a connector containing both read and write functions. Hiding the write button from the model is weaker than removing the write capability from its execution path. Check both the exposed tool schema and the actual backend permissions.

Read access also needs a reason. An agent that can read every document but cannot write anything can still disclose sensitive material through its output. Restrict retrieval scope before model processing, and apply the same scope to attachments and search results.

Run a small denial check before adding another tool

Use synthetic records in a test environment. For each allowed operation, define a neighboring operation that must fail. The useful question is whether the trusted service rejects it, regardless of what the model says.

1. Read a ticket in the permitted tenant: expect the permitted fixture.
2. Read a ticket from a different tenant: expect denial and no ticket body.
3. Invoke an undeclared delete operation: expect denial before any downstream call.
4. Retry after the user's access is revoked: expect denial under current policy.
5. Call the same backend route without the chat UI: expect the same authorization decision.

Capture the expected decision and the actual service result. A model refusing an operation is useful behavioral evidence, but it does not establish that the backend would reject the same operation.

Review grants when the workflow changes

New features often widen old permissions indirectly. An attachment feature may add storage access; a scheduled run may introduce a long-lived identity; a troubleshooting endpoint may expose a bypass. Review the permission map whenever these paths change, and remove unused connectors and credentials after experiments.

This map is a starting method, not a complete security architecture. It does not resolve compromised accounts, unsafe provider defaults, malicious tool implementations, or every data disclosure channel. Boundary is a prelaunch commercial model router; planned request-path checks for defined sensitive patterns, provider policies, and usage limits would not by themselves enforce the ticket, messaging, or filesystem controls described here.