Agent Permission Design: Least Privilege + Human-in-the-Loop

This article has three layers:

1. Layer 1: The Intuition: Giving permissions to a new employee
2. Layer 2: Real-World Use: Permission models for coding Agents, browser Agents, and enterprise Agents
3. Layer 3: Risk classification of actions, approval interface design, short-lived credentials, and proxies

Layer 1: The Intuition

1.1 Giving permissions to a new employee

A reasonable company grants permissions to a new employee like this:

• Day one: Can read documentation and code, but cannot modify the production environment and cannot touch finances;
• When sensitive operations are required: Submit an application, get supervisor approval, and revoke access once the task is finished;
• All operations are logged.

An Agent should be treated the same way. The difference is: Agents are much easier to trick (see "prompt injection") and can perform dozens of actions in a single second.

1.2 Three Principles

Layer 2: Real-World Use

• Permission models for AI coding tools: Mainstream coding Agents usually offer several tiers of modes: ask for permission for every command, ask only for file writes and command executions, automatically allow commands on a certain "allowlist," or run fully automatically within a sandbox. Users can configure allowed and forbidden commands per project.
• Browser Agents: Pause at critical steps such as making payments, submitting forms, or sending messages, waiting for user takeover or confirmation.
• Enterprise Agents: Obtain scoped access via OAuth (e.g., "read-only calendar" instead of "full access to Google Account") and support revocation at any time.
• OWASP "Excessive Agency": The OWASP LLM Top 10 lists "giving an Agent too much functionality, permission, or autonomy" as a distinct category of risk (see "AI Red Teaming").

Layer 3: Principles and Engineering

3.1 Action Risk Classification

Dimensions for judging risk: Reversibility, Impact scope (affects only self vs. affects others/public), Involvement of money or credentials, and Whether it sends data externally.

3.2 How to design the approval interface

A good confirmation interface should allow a user to understand the context within seconds:

• What is being done: The full command, the target address, or the content to be sent, rather than a summary written by the Agent itself (summaries can be tampered with via injection);
• Why it is being done: The Agent's reasoning, but clearly labeled as "Agent's statement";
• Impact: Which files will be modified, who it will be sent to;
• Options: Allow once, allow similar actions for this session, deny, deny and provide a reason.

Ways to avoid confirmation fatigue (see "Risk Control Scoring and Friction Design"):

• Do not disturb for low-risk actions;
• Allow "allow similar commands for this session," but do not provide an "always allow" option for high-risk categories;
• Add a bit of friction to high-risk action confirmations (e.g., requiring the user to type the target repository name) to break unconscious clicking.

3.3 The trap of command allowlists

"Allowing git commands" might seem safe, but git can push to any remote repository; "Allowing npm" means allowing npm install arbitrary packages, and an installation script can execute arbitrary code (see "Dependency Poisoning"). Allowlists should be as specific as possible down to subcommands and parameters, and must consider command combinations (pipes, &&, $(...)).

3.4 Credentials: Short-lived, narrow scope, and not in context

3.5 Log everything

Every action (including rejected ones) must be logged: time, action, parameters, and who approved it. This serves both as a basis for post-incident investigation and as a signal for detecting anomalies: if an Agent suddenly attempts a large number of rejected actions, it has likely been subject to prompt injection.

Summary