AI Agent Authorization Design: Building Permission Models for Autonomous AI Features

Why Authorization Is Your Most Important Agent Product Decision

When an AI agent takes an action in the world, someone is responsible for that action. The authorization model is the document that specifies who, what, and under what conditions. Get it wrong, and you will face one of two failure modes: an agent so locked down that users bypass it, or an agent autonomous enough to take actions users never wanted it to take.

The authorization model is not a security review checklist. It is the answer to a question users ask implicitly every time they interact with your agent: "What is this thing allowed to do, and how will I know when it does it?" Users who cannot answer that question don't trust the product. Users who distrust the product don't use the agent features that justify its development cost.

The under-authorization failure

The agent must ask for confirmation on every action, including trivially safe ones. Users experience it as slower than doing the task manually. Usage drops. The team concludes 'users don't want agentic features,' which is the wrong lesson.

The over-authorization failure

The agent takes a consequential action without the user realizing it was possible. User discovers an email was sent on their behalf they did not intend. Trust collapses immediately and often permanently. 'I turned off the AI' is the outcome.

The transparency failure

The authorization model exists but users don't know what it is. They can't predict agent behavior, so they treat it as a black box. Low engagement with advanced features, high anxiety during task execution.

The scope creep failure

An agent authorized for task A begins using tools or accessing data needed for task B, because task B is in its context. The model was never told these were different scopes. Users discover unauthorized data access.

The Four Authorization Tiers

Every action an AI agent might take falls into one of four tiers. The tier determines what confirmation flow, if any, is required before the agent proceeds. Your product's authorization model is a mapping of every potential agent action to one of these tiers, defined before development begins.

Tier 1: Always autonomous

Actions the agent can take without any user confirmation. Characteristics: reversible, low consequence, contained within the agent's own state. Examples: drafting a reply the user hasn't sent, adding an item to a temporary task list, reading data the user has already explicitly shared with the agent.

Test: Would a reasonable user be surprised or upset if they discovered this action happened without being told? If no, it belongs in Tier 1.

Tier 2: Confirm before acting

Actions that are consequential or hard to reverse, but expected to be part of normal agent workflows. The agent must show the user what it is about to do and receive explicit confirmation. Examples: sending a message, modifying a record, scheduling a meeting on someone else's calendar, making an API call that incurs cost.

Test: If this action turned out to be wrong, would it take more than 30 seconds to undo? If yes, it belongs in Tier 2.

Tier 3: Require explicit capability grant

Actions the agent cannot attempt until the user has proactively granted a specific, named capability. This is not a per-action confirmation, it is a one-time authorization for a class of actions. Examples: accessing the user's contacts, reading their financial data, posting to external systems. The grant is visible in settings and revocable.

Test: Would a reasonable user expect to see this capability explicitly listed in a settings panel under 'Agent Permissions'? If yes, it belongs in Tier 3.

Tier 4: Categorically blocked

Actions the agent will never take regardless of user instruction, session context, or explicit grant. This tier is defined in product requirements and enforced at the infrastructure level, not by the model. Examples: accessing data outside the user's own account, taking any action that cannot be attributed to a specific user, contacting third parties not named by the user.

Test: Is there any scenario in which a reasonable user would want the agent to take this action autonomously? If no, it belongs in Tier 4.

Designing Permission Boundaries Users Actually Trust

An authorization tier mapping in a product spec is necessary but not sufficient. The same authorization model can produce a product users trust or one they don't, depending on how the permissions are communicated, onboarded, and surfaced during use. The goal is a model where users can always answer "what is this agent allowed to do right now" without having to read a help article.

Name permissions in user language, not technical language

"Can send email on your behalf" is better than "SMTP write access." "Can read your calendar events" is better than "calendar.events.read scope." Users grant permissions based on names. Vague or technical names produce uninformed grants that later produce betrayal.

Show the permission boundary at the moment it becomes relevant

Do not surface all permissions in onboarding. Surface each permission boundary the first time the agent approaches it during a real task. "I can draft this email, but sending it requires you to grant me send access. Here's what that means." Contextual is more trusted than exhaustive.

Make the permission state always visible and revocable

A settings panel that shows active agent permissions, with a single-click revoke for each, is not a legal obligation. It is what users check when they feel anxious about what the agent might be doing. Its existence reduces anxiety before the question is ever asked.

Distinguish between session permissions and persistent permissions

A Tier 3 permission granted for one session should not automatically persist. Prompt the user to confirm whether they want the grant to persist. Users who grant a permission for a specific task and then forget about it are your biggest source of "I didn't know it could do that" incidents.

Log and surface agent actions, not just confirmations

An activity log of what the agent did, not just what it asked to do, is the accountability primitive users need to develop long-term trust. Weekly or session-level summaries are underused and high-value.

Ship AI Features You Can Defend

The AI PM Masterclass covers agentic product design, responsible AI, and the technical concepts PMs need to make good authorization decisions. Taught live by a Salesforce Sr. Director PM.

Technical Concepts AI PMs Need to Understand

You do not need to implement an authorization system, but you need to understand the concepts well enough to specify one, review an engineering design, and identify when a proposed implementation does not match the product requirement.

Tool scope definition

In agentic frameworks, agent capabilities are defined by which tools the agent has access to. Authorization design starts with a precise list of tools, what each one can do, and which tier each falls into. This list is a PM deliverable, not an engineering assumption.

Principle of least privilege

The agent should have access to the minimum set of tools and data required to complete the task, not a broad superset. A writing assistant does not need access to billing history to draft a reply. Scope the tool list to the task.

Tool call logging

Every action an agent takes via a tool call should be logged with timestamp, user ID, action type, and outcome. This is the raw data for your activity log UI and the forensic record for any 'I didn't authorize that' incident.

Human-in-the-loop checkpoints

A Tier 2 action maps to a human-in-the-loop checkpoint in the agent execution graph. Engineering builds this as a pause state: the agent prepares the action, surfaces it to the user, and waits for confirmation before proceeding. The PM spec defines which actions trigger this pause.

Revocation latency

When a user revokes a permission, how quickly does that take effect for in-progress agent tasks? The answer should be: immediately. A revocation that does not take effect until the current task completes is not a real revocation. Specify revocation latency as a hard requirement.

Scope isolation between users

In multi-user products, an agent authorized by User A cannot take actions that affect User B's data without User B's explicit grant. This seems obvious until you have an agent that summarizes shared documents. Define the boundary precisely in your auth spec.

Authorization Pitfalls That Destroy Trust in Production

Authorization failures in production are almost never about hackers or adversarial users. They are about design gaps that allow normal users to reach states the product team did not anticipate. These are the most common ones.

The "helpful" override

The agent detects that completing the user's request would require a Tier 3 permission not yet granted. Instead of pausing and asking, it finds a workaround using tools it does have. The workaround produces a different outcome than the user expected. Solution: agents should surface permission gaps explicitly, never route around them.

Confirmation theater

The Tier 2 confirmation prompt is poorly designed: it buries the action in a long description, uses ambiguous wording, or defaults to 'confirm.' Users click through without reading. The agent acts. Users feel betrayed. Solution: confirmation prompts must be single-sentence, specific, and default to cancel, not confirm.

Persistent grant without reminder

A user granted a Tier 3 permission six months ago and has forgotten. The agent uses it for a task in a new context. The user is surprised. Solution: surface persistent grants proactively when the agent is about to use them for a materially different task than the one they were originally granted for.

Inter-agent permission inheritance

In multi-agent architectures, a subagent inherits the permissions of the orchestrator by default unless explicitly scoped. This means a broad-permission orchestrator can spawn a narrow-task subagent that carries the full permission set. Specify subagent permission inheritance explicitly in your auth design.

Logging gaps during failures

When an agent encounters an error or timeout mid-task, logging sometimes fails or captures only partial state. This means the user has no record of what actions were taken or attempted. Failed tasks must be logged at least as completely as successful ones.

Your Authorization Design Checklist

Before any agentic feature enters engineering design, the PM should be able to answer every item on this checklist. Gaps here become incidents post-launch.

Have you mapped every potential agent action to one of the four tiers?

Is every Tier 3 permission named in user language and visible in settings?

Do all Tier 2 confirmation prompts default to cancel, not confirm?

Is there an activity log showing what the agent did, accessible to the user?

Is revocation immediate, including for in-progress tasks?

Are persistent grants surfaced when used in materially new contexts?

Is subagent permission inheritance explicitly scoped?

Are Tier 4 blocks enforced at the infrastructure level, not just by the model?

Is there a defined process for escalating potential Tier 4 violations?

Have you user-tested the authorization UI with non-technical users?