How to Design AI Agent Permissions That Users Actually Trust: The 5-Rung Ladder
Read, Suggest, Draft, Act with confirmation, Autonomous — the five permission levels that move users from skeptical to trusting AI agents. Build this in a day.
You Can Design This Permission System in a Day
A real production system was deleted because an agent couldn’t tell the difference between staging and production. Not a demo environment. Not a sandbox. A live system, gone, because the agent had write access and no semantic understanding of what “production” meant versus “staging.” That failure wasn’t a model problem. It was a permissions design problem.
If you’re building AI agents that touch real data, real calendars, real money, or real communications, you need a trust framework before you need anything else. The five-rung permission ladder — Read → Suggest → Draft → Act with confirmation → Autonomous — is that framework. You can design it into your agent architecture in a day. Getting it right will save you from the kind of incident that ends a product’s credibility with users before it ever gets a chance to earn it.
This post is about how to build that ladder deliberately, rung by rung, with concrete decisions at each level.
Why Permission Design Determines Whether Users Come Back
Most agent builders think about permissions as a security concern. It’s actually a trust concern, and the distinction matters.
Security is about preventing unauthorized access. Trust is about whether a user will hand the agent more authority after the first interaction. These are different problems with different solutions.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
Users are risk-averse in a specific way: a single bad outcome — an email sent to the wrong person, a meeting rescheduled without understanding the politics behind it, a purchase made at the wrong moment — doesn’t just create a support ticket. It creates a mental model. “This agent can’t be trusted.” And once that model is set, it’s nearly impossible to dislodge. The user won’t try again. They’ll tell others not to try.
The permission ladder exists to prevent that outcome. Each rung earns the next. You don’t ask users to trust an autonomous agent on day one. You show them the agent reading correctly, then suggesting correctly, then drafting correctly — and only then do you ask them to let it act.
This also maps to a real product insight: the agents that have succeeded fastest are the ones where the feedback loop is tightest. Coding agents arrived before every other category of knowledge work agent not just because code is text, but because software development has unusually rich semantic feedback — tests pass or fail, compilers throw errors, linters flag issues, git history shows what changed. The agent can perceive state, act, observe feedback, and revise. Most knowledge work has none of that. A calendar invite doesn’t have a test suite. A customer email doesn’t have a linter. Your permission architecture has to compensate for that missing feedback by keeping humans in the loop at the right moments.
What You Need Before You Start
You don’t need a specific stack to implement this framework, but you do need to make a few decisions before you start assigning permission levels.
Define your action surface. List every action your agent can take. Not categories — specific actions. “Send email” is too broad. “Send email to external recipient from primary account” is specific enough to assign a permission level. “Read calendar events” and “modify calendar events” are different rungs.
Identify your irreversible actions. Some actions can be undone. A draft can be discarded. A suggestion can be ignored. A sent email cannot be unsent. A deleted file may not be recoverable. A payment authorization may trigger downstream processes. Mark every irreversible action before you assign it a rung — irreversible actions should almost never sit below rung 4.
Know your user’s risk tolerance by domain. A user might be comfortable with rung 5 (fully autonomous) for “add items to grocery list” and rung 2 (suggest only) for “respond to client emails.” Permission levels aren’t global. They’re per-domain, per-action type, and sometimes per-relationship.
Decide how you’ll surface confirmations. Rung 4 requires a confirmation mechanism. That mechanism needs to be low-friction enough that users don’t abandon the workflow, but high-signal enough that they actually read what they’re confirming. A modal that says “Are you sure?” is not a confirmation mechanism. A preview that shows exactly what will be sent, to whom, and when — that’s a confirmation mechanism.
The Five Rungs, Built Out
Rung 1: Read
The agent can see. It can read your files, your email, your screen, your calendar. It cannot surface anything to you unprompted. It cannot take any action.
This is where you start with every new user and every new domain. It’s also where you stay until you have evidence the agent is reading correctly.
How Remy works. You talk. Remy ships.
The implementation question here is scope, not permission level. “Read” sounds harmless until you realize you’ve given an agent access to every email in a 10-year inbox, including emails the user has forgotten exist. Define read scope explicitly: which folders, which date ranges, which calendars, which files. Codex Chronicle’s memory feature is instructive here — it enables proactive suggestions based on observed work patterns, but it only works well when the observation scope is bounded and the user understands what’s being observed.
Check: After rung 1 is implemented, can you show the user exactly what the agent has read? If you can’t answer that question, your read scope is too broad.
Rung 2: Suggest
The agent surfaces something proactively. “This email looks like it needs a follow-up — you said you’d respond by Thursday.” “This meeting conflicts with a commitment you made to a client.” The agent makes a proposal. The user remains in charge.
This is the rung where most consumer agent products are currently stuck, and it’s harder than it looks. The failure mode isn’t agents that suggest nothing — it’s agents that suggest too much, or suggest things based on bad data. An agent that sends you proactive nudges about meetings you don’t actually have, or follow-ups on emails you’ve already handled through a different channel, trains users to ignore its suggestions. Once users start ignoring suggestions, you’ve lost the trust you needed to earn rung 3.
The quality bar for rung 2 is: does this suggestion reduce the user’s cognitive load, or add to it? If the user has to evaluate whether the suggestion is relevant before they can dismiss it, you’ve added work. Suggestions should be so obviously relevant that the user’s first reaction is “yes, I needed that.”
Poke — the messaging-based consumer agent that lives in iMessage, SMS, and Telegram — is betting that the messaging interface lowers the cognitive cost of receiving suggestions. The bet is reasonable. The risk is that salience is still a model and personalization problem, not just an interface problem.
Rung 3: Draft
The agent prepares the action but doesn’t execute it. It writes the email. It builds the schedule. It fills the form. The work is done; the user approves before anything leaves the system.
This is the rung where agents start to feel genuinely useful, and also where the semantic gap becomes most visible. An agent that drafts a meeting reschedule without understanding that the meeting involves a client relationship, a prior commitment, and three people who need advance notice will produce a draft that’s technically correct and contextually wrong. The user will fix it, but they’ll also start to wonder whether the agent is actually saving them time.
The fix isn’t a better model — it’s better semantic context. The agent needs to know not just “this is a calendar event” but “this event has these attendees, this history, this level of importance.” That’s what a semantic work primitive is: a refund, a reschedule, a payment authorization, a compliance exception, a meeting brief — units of work that carry their own context and constraints, not just field values.
For builders using MindStudio, the visual workflow builder lets you chain context-gathering steps before a draft action — pulling CRM history, checking prior communications, flagging relationship signals — so the draft arrives with the right semantic load already attached.
Rung 4: Act with Confirmation
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
The agent goes into the world. It navigates, fills forms, assembles options, prepares bookings. But it asks before consequential moments.
The key design decision here is what counts as “consequential.” You need a definition that’s specific enough to implement, not a vague “when it matters.” Some heuristics that work:
- Irreversibility: If the action can’t be undone in under 60 seconds, require confirmation.
- External recipients: If the action reaches someone outside the system (sends an email, makes a call, submits a form to a third party), require confirmation.
- Financial materiality: If the action involves money — even small amounts — require confirmation. Stripe’s agent wallets are real infrastructure now; agents can make purchases. That capability is useful precisely because it requires explicit permission design around it.
- Scope creep: If the agent is about to do something that wasn’t in the original request, require confirmation.
The confirmation UI matters as much as the trigger. Show the user a preview of exactly what will happen. Not “I’m about to send an email” — show the email. Not “I’m about to reschedule the meeting” — show the new time, the attendees who will be notified, and the message they’ll receive.
Codex’s auto review feature is worth understanding here. It functions as a guardrail — it prevents the agent from doing something it shouldn’t. That’s valuable, but it’s different from a positive confirmation mechanism. A guardrail stops bad actions. A confirmation preview gives users the information they need to authorize good ones. You need both.
For teams building agents that touch sensitive workflows, the Claude Code Auto Mode approach to permission handling is worth studying — it blocks risky actions automatically while allowing safe ones, which is a useful complement to explicit confirmation prompts.
Rung 5: Autonomous
The agent buys, books, sends, and signs without asking. This is the rung most people want to jump to immediately, and the rung that destroys trust fastest when it goes wrong.
Rung 5 is not a destination you design toward from the start. It’s a rung you earn through demonstrated reliability on rungs 1–4. The user needs to have seen the agent read correctly, suggest relevantly, draft accurately, and act with confirmation before they’ll trust it to act without asking.
Even at rung 5, you need escape hatches. Audit logs that show every action taken. Rollback mechanisms where they exist. Notification-only mode where the agent acts but immediately tells the user what it did. The goal isn’t to make the agent invisible — it’s to make its actions feel predictable enough that the user doesn’t need to supervise every step.
Symphony, the open-source protocol from OpenAI developers, is an interesting model here. It moves agent task management into an issue tracker: agents pick up work, humans review outcomes. That’s rung 5 with a structured audit trail. The issue tracker becomes the semantic layer that makes autonomous actions reviewable.
The Failure Modes You’ll Actually Hit
Hire a contractor. Not another power tool.
Cursor, Bolt, Lovable, v0 are tools. You still run the project.
With Remy, the project runs itself.
Assigning the same rung globally. “This agent has read access” means nothing if read access to email is different from read access to financial documents. Permission levels are per-domain and per-action-type. Build your permission model as a matrix, not a single setting.
Treating confirmation as friction to minimize. Some builders try to make rung 4 feel like rung 5 by making confirmations so easy to dismiss that users stop reading them. This is worse than no confirmation at all — it creates the illusion of oversight without the substance. If your confirmation rate is above 95%, users are rubber-stamping. That’s a signal your confirmation UI needs more friction, not less.
Skipping the semantic layer. The production system deletion happened because the agent had write access but no understanding of what “production” meant. Access without meaning is dangerous. Before you assign any rung above 2, make sure the agent has the semantic context to understand what it’s touching. This is why OpenClaw best practices for power users emphasize scoping agent access carefully — not because the agent can’t act, but because acting without context produces exactly these failures.
Letting users set their own permission levels without guidance. Users will often choose rung 5 immediately because it sounds like the most useful option. Your onboarding needs to walk them through the lower rungs first, not because you’re withholding capability, but because trust has to be earned in sequence. An agent that earns rung 5 through demonstrated reliability is an agent users will defend when it occasionally makes a mistake. An agent that starts at rung 5 and makes one bad call is an agent users will uninstall.
Not having a permission ladder per domain. A user might be comfortable with full autonomy for scheduling low-stakes internal meetings but want confirmation for anything touching external clients. Build domain-specific permission profiles, not a single global setting. If you’re building multi-agent workflows, the Paperclip vs OpenClaw comparison on multi-agent systems covers how different architectures handle permission scoping across agent boundaries.
Where to Take This Further
The permission ladder is a framework for earning trust. The next layer is making that trust durable.
Durable trust requires memory. An agent that has to re-earn trust every session — that doesn’t remember what it’s been authorized to do, what domains it’s been given access to, what the user’s preferences are — will always feel like it’s starting over. Codex Chronicle’s memory feature is an early version of this: it observes work patterns and enables proactive suggestions based on what it’s seen. The Claude Code source leak’s three-layer memory architecture is worth reading for a more detailed look at how persistent agent memory can be structured.
Durable trust also requires transparency. Users need to be able to see what the agent has done, what it has access to, and what it’s planning to do next. That’s not just a UX feature — it’s the mechanism by which users decide to move an agent up the permission ladder.
If you’re building agents that need to span multiple tools and workflows, the permission model has to extend across integrations. Remy takes a related approach to the spec-as-source-of-truth problem: you write annotated markdown describing your application’s behavior and constraints, and the full-stack app — TypeScript backend, database, auth, deployment — gets compiled from it. The permission rules live in the spec, not scattered across implementation files. That’s a useful mental model for agent permission design too: the permission contract should be explicit and readable, not implicit in code paths.
The five rungs aren’t a checklist you complete once. They’re a continuous negotiation between what the agent can do and what the user is willing to authorize. Get that negotiation right, and you have an agent users trust. Get it wrong, and you have a very capable system that nobody uses.
The production deletion was preventable. Most trust failures are.
