A practical permission model for non-technical teams

The four levels: read, draft, approve, act

A permission does not have to be a single yes-or-no switch. Think of agent access as four rising levels, and grant the lowest one that still finishes the job:

1. Read — the agent views information but changes nothing. A reporting agent that pulls sales figures lives here.
2. Draft — the agent prepares a proposed change and parks it for you. An email written into a folder, unsent, is a draft.
3. Approve — the agent readies the action but waits for a person to say yes before it commits.
4. Act — the agent completes the change on its own and logs what it did.

The levels matter because most real risk hides in the jump from draft to act. Reading and drafting stay inside the dashboard, where a mistake costs a glance to fix; approving and acting reach the outside world. How to judge the right level: ask what becomes true the moment the agent finishes, and whether you could undo it in under a minute. If yes, a lower level is usually enough.

The common failure is skipping straight to act because it feels finished—an agent set to send its own emails on day one, before a single draft has been reviewed. The trade-off runs the other way too: every step up the ladder buys capability with a consequence that is harder to take back, so climb it deliberately, one level at a time.

Match the level to the job, not the tool

Permissions should follow the specific workflow, not the tool it connects to. A reporting agent may need to read your CRM but never edit it. A drafting agent may prepare an email without ever sending one. The tool is the same inbox or database either way; the job is what decides how much of it the agent should touch.

This matters because broad grants are invisible risk—access you cannot see is access you will not review. How to judge it: for the workflow in front of you, can you name in one breath exactly what it reads and exactly what it changes? If the honest answer is “all of it, to be safe,” the scope is too wide.

A typical failure: giving a meeting-prep agent full write access to the whole CRM when the job only reads four fields and saves a draft. Nothing in that workflow needs to edit a record, yet the permission would let it. The trade-off is that tighter scoping means you will occasionally grant one more field when a workflow genuinely grows—a small, deliberate cost that keeps every permission explainable.

Let reversibility decide what runs automatically

Once you know the level a job needs, one question decides whether it can run at the higher levels on its own: how hard is the result to undo? Automatic action is reasonable when a mistake is low-impact and quick to reverse—re-tagging a mislabeled message, regenerating a weak draft. It is not reasonable when the action is public, financial, destructive, or identity-sensitive.

How to judge it: imagine the agent got this exact action wrong, then ask how long the cleanup would take and who would notice. A wrong label is seconds and no audience. A wrong email under your name, a wrong refund, or a deleted list is minutes-to-never—and very much an audience.

The failure to avoid is treating every action as equally cheap to undo: the setting that lets one agent both sort invoices and pay them on the same automatic permission. The trade-off is that requiring approval buys safety with your attention, so reserve “approve before” for the actions that actually leave your control, and let the reversible work run.

Scope access per workflow, not per agent

When you review permissions, change the question. Do not ask “What can the agent access?”—ask “What can the weekly-report workflow access?” The first question invites a single, ever-growing connection that every job quietly shares; the second forces each workflow to justify its own access.

This matters because shared, all-purpose connections hide their own danger. How to judge it: if you cannot point to which workflow needs a given permission, that permission has no owner—and probably no reason to exist. Per-workflow scoping makes an over-broad grant stand out instead of blending in.

A common failure is one CRM connection wired into five workflows, where a plain reporting job carries delete rights because some other workflow once needed them. The trade-off is more connections to keep track of, but each one is legible: switching a workflow off removes exactly the access it used, nothing more and nothing less.

Review access on a set cadence

Permissions accumulate. A connection added for a busy launch week outlives the launch; a workflow you retired still holds send access nobody turned off. Set a recurring review—quarterly is a reasonable default—and walk a short checklist:

• Remove connections no active workflow uses.
• Downgrade write access to read wherever the job allows it.
• Confirm who receives approval requests, and that a real person still reads them.
• Test that the pause and disconnect controls actually work.

How to judge it: a healthy review usually removes something. If three reviews in a row change nothing, either the business truly is static or—more likely—no one is looking closely. The failure this prevents is quiet drift: the retired workflow whose credentials still send mail, or the read grant that became write access during a fix and never came back down. The trade-off is twenty minutes a quarter, far cheaper than reconstructing, after an incident, why an agent could do something you never meant to allow.