How do you right-size an AI agent's permissions?

Agents use whatever you give them, often in ways that aren’t obvious when the task is vague. So before granting them access to sensitive systems, you should ask yourself a few questions and get satisfying answers. 

You might be tempted to go the RBAC route (and make your life easier) by asking something along the lines of: “What access does an agent like this usually have?” Unfortunately, agents are ill-suited for this kind of access control. They do what’s necessary to accomplish the task they’re given, and look for paths not bounded by traditional roles. 

Your reality checks should be conducted against the stated intent of the agent (i.e., “what’s required for the agent’s specific task”). And they should be conducted periodically, as drift is the norm with agentic flows. 

In this checklist, each item has an artifact you should be able to point to. If no artifact exists, drift is much more likely. 

Phase 1: Takeoff

There’s a written intent statement for the agent

• One or two sentences stored with the agent’s config or registration, saying what the agent does and for whom
• The agent’s purpose lives in its builder’s head, or reads “general-purpose assistant”

Data classes / sensitivity are named

• Which data the agent may touch (PII, secrets, customer, financial) is listed with the systems
• "Whatever the connector returns"

We know which systems the agent needs to access

• A list of named systems, each mapping to a step the agent performs
• “Same access as its owner” instead of a requirements list

There’s a split between read and write access

• In the systems list, we know where write access is required, and why
• Write access requested “to be safe”

Each access grant has a lifespan declaration

• Every standing grant has a reason behind it. All others are time-limited.
• No grants expire.

We use the narrowest available scope

• Stated reasons for not using the next-narrower option
• Top-level scope without explanation

The agent has its own identities

• Credentials resolve to exactly one agent; revoking it would affect nothing else
• A service account used by others

Credentials expire

• There’s an expiry date on the credentials, short-lived tokens, or known refresh token policy on OAuth
• A non-expiring API key without a very good reason

There’s a human owner

• The owner is recorded where whoever finds the credential will look, and the owner knows about it
• Ownership assigned to a team, or not assigned at all

The approval chain is visible

• It’s possible to see who approved the access, when, and at what scope
• The approval is just a consent-screen click

Phase 2: In-flight

Agent is distinguishable from its owner

• A recent agent action attributes to the agent or “user via app” in the log
• The logs show a human for what is an agent action

Activity is logged in a monitored system

• Agent activity flows into the same place human activity is monitored
• Activity exists only in a separate, unmonitored vendor console

Drift detection is continuous

• A diff of systems touched over the last window against the Phase 1 list
• Touches outside the list treated as a curiosity rather than a signal

Activity volume is bounded

• Rate, row, or result limits set, with the task’s expected volume as the ceiling
• An agent that can spend its monthly budget in a single day

Phase 3: Maintenance

We know the next review date

• A dated entry for the next review already exists
• “Quarterly” as a policy with no date attached

We looked at drift and right-sizing

• Scopes granted, scopes exercised during the window, and the never-used ones removed
• Unused scopes kept “in case”

We know what happens when the owner leaves, project ends, or vendor cancelled

• Documented steps to revoke, delete registration, and confirm no orphaned tokens
• Ownerless agent

We can revoke access

• The credential was revoked once in a controlled window; the agent verifiably lost access
• The kill switch exists as a diagram