AI agent permissions checklist: least privilege for agents

Why agent permissions need their own checklist

A human employee accumulates access gradually and is subject to ongoing judgment, hesitation, and social norms that slow down mistakes. An AI agent has none of that friction. It will use whatever access it is given, exactly as configured, at whatever speed the integration allows. That makes over-permissioning an agent a materially different risk than over-permissioning a person, even though the underlying access control concepts are the same.

Least privilege means giving an agent the minimum access required to complete its specific task, for the minimum time necessary, and nothing else. It is a well-established principle in security, and it applies to agents with even more force than to human accounts, because agents act continuously and without the pause a person naturally takes before an unfamiliar action.

Scope access by system, not by role

Avoid granting an agent a broad role like "finance system access" when it only needs to read invoice line items and write a status field. Map out, system by system, exactly which objects, fields, and operations the task requires, then grant only those. This is more setup work upfront, but it means a bug or a bad instruction has a small blast radius instead of a large one.

• List every system the agent touches: email, document storage, a database, a spreadsheet, a SaaS tool, an internal API.
• For each system, list the specific objects it needs: which folders, which tables, which record types, not the whole system.
• For each object, list the operation: read only, read and draft, read and write, or read and delete. Default to the narrowest option that still completes the task.
• Note the time window: does the agent need standing access, or only access during a defined pilot period that gets revoked or reviewed afterward?

Separate read, propose, and act

The single most useful permission boundary is the line between an agent that reads and drafts versus one that takes action directly. Reading data and proposing a change (a drafted email, a suggested categorization, a flagged exception) carries very different risk than an agent that sends the email, changes the record, or moves the money on its own.

A practical rule: any action that is hard to reverse, touches money, touches a customer directly, or touches a regulated data type should sit behind a human approval step, at least until the agent has a track record. Reversible, low-stakes, high-frequency actions are reasonable candidates for direct action once accuracy has been measured.

Build in logging before you build in autonomy

Every action an agent takes, and every decision it made along the way, should be logged in a way a person can review later without needing to ask the agent to explain itself. This includes what data it read, what it decided, what it changed, and why, in terms specific enough to reconstruct the sequence of events.

Logging is not optional infrastructure to add once something goes wrong. It is the mechanism that makes the rest of the permissions design trustworthy, because it is what lets you verify, after the fact, that the agent stayed inside its boundary.

Name a human owner for every agent

Every agent in production should have one named person accountable for its behavior, not a team or a committee. That person should be able to answer, without escalation, what the agent is allowed to do, what it is not allowed to do, and who to contact if something looks wrong. Diffuse ownership is one of the most common reasons a misbehaving agent keeps running longer than it should.

Review and revoke access on a schedule

Access that made sense during a pilot often outlives the pilot. Set a recurring review, quarterly is a reasonable default, where the named owner confirms that every permission the agent holds is still necessary. Revoke anything that is not actively used. An agent with unused, forgotten permissions is a liability even if it never exercises them, because it expands what a compromised credential or a bad instruction could do.

The checklist

Use this as a working document when you set up or review an agent.

• Every system, object, and operation the agent can touch is listed explicitly, not granted by broad role.
• Access is scoped to read only unless a write or delete is specifically required.
• Irreversible, financial, customer-facing, or regulated actions require human approval.
• Every action and decision the agent makes is logged in a reviewable format.
• One named person owns the agent and can explain its permissions on demand.
• Access is reviewed on a recurring schedule, and unused permissions are revoked.
• There is a documented way to pause or shut off the agent immediately if needed.