Who Can Your Agents Act As? A Guide to Agent RBAC

An agent acting on behalf of a specific user should inherit that user's permissions, not the broader permissions of the service account running the agent process. This means every tool call needs to carry the acting user's identity through to whatever system it touches, and that system needs to enforce its own access rules against that identity, not just trust the agent.

A tool built to answer "what's my order status" doesn't need access to every other customer's orders, even if the underlying database client it was built on top of has that access by default. Review each tool's actual query or API scope and narrow it to exactly what its stated purpose requires, the same principle of least privilege that applies to human accounts.

A quick way to find over-broad scope is to ask each tool's owner what would happen if the model passed the wrong identifier. If the answer is that it would return another customer's record, the tool is scoped to the table instead of the user. The fix is usually to push the acting user's identifier into the query itself, so the database or API refuses rows the user could not see directly, instead of relying on the model to ask only for the right ones. Repeat the question for write tools, where the wrong identifier changes data instead of exposing it.

Give agents read access more freely than write access, and require an extra layer, a confirmation step, a lower-privilege token, or a separate approval, before an agent can take an action that changes state. This separation is the single biggest lever for limiting how bad a mistake or a manipulated instruction can get.

When an agent is denied access to something, log that as clearly as when it succeeds. A pattern of repeated denials for the same tool is often the first sign that either a user's expectations don't match their actual permissions, or that something is probing for access it shouldn't have.

This log also doubles as useful product feedback: if a specific permission denial shows up constantly for a specific role, that's often a sign the role's permissions are set wrong, not that every one of those users is trying to do something they shouldn't. Reviewing the denial log alongside the access log, rather than only the successes, is usually where a mismatched role definition actually gets found, and it's a cheap habit to build into a regular weekly check.

Say a single "look up account details" tool is used by three different roles through the same agent: a customer checking their own account, a support agent helping a customer, and a finance analyst pulling account data for a report. If the tool's permissions are wired to the service account instead of the acting user, all three get exactly the same access, which is usually wrong for at least two of them: the customer shouldn't see internal notes the support agent can see, and the finance analyst shouldn't be able to trigger the kind of individual-account actions a support agent can.

Scoping the tool to check the acting user's actual role on every call, rather than granting one broad permission set to the tool itself, means the same tool code can safely serve all three roles with the correct, different access for each one.

The most common early mistake isn't malicious misuse, it's a single shared service account created to get the first version of an agent working quickly, with the intention of tightening it up later. Later tends to arrive only after a specific incident forces the issue, at which point the fix has to happen under pressure rather than as a deliberate design choice. Building the acting-user check in from the first version, even in a simple form, costs less than retrofitting it once several tools already assume broad access, and it avoids the awkward conversation about how long the broader access had quietly been in place.

Use this checklist before an agent reaches production:

• Every tool call carries the acting user's identity, and the downstream system enforces its own access rules against that identity.
• Each tool is scoped to the narrowest query or API access its stated purpose requires.
• Write actions need an extra layer, such as a confirmation step, a lower-privilege token or a separate approval.
• Permission denials are logged as clearly as successes and reviewed alongside the access log on a regular schedule.
• No shared service account is left in place with the plan to tighten it later.