The permission ladder: why AI employees should earn autonomy

When you hire a person, you do not hand them the company card on day one. You let them read, then draft, then handle small things alone, and at some point you notice you have stopped checking. Software agents mostly skip this. They launch with whatever access their API key carries, and the only dial is on and off. We think that is the single biggest reason teams do not trust agents with real tools, and it is the first thing we designed around.

A Pagerox employee works under a permission ladder instead. Every tool grant is set per operation, not per integration: reading an issue and creating an issue are different rows in the matrix, and each row sits at one of five positions.

Off means the operation does not exist for the employee. It is not refused by a prompt or hidden behind a policy sentence; it is never in the model's tool list at all. There is nothing to talk the employee into, because there is nothing to call.

Observe is where most reads live. The employee may run the operation, and every call lands in the audit log: what ran, when, and how it went. Pulling a CI config, checking a branch protection rule, looking up an invoice. Quiet, but never invisible.

Notify is observe plus a message. The employee acts and tells its manager it did. This is the right level for operations you want visibility on without building a queue of rubber stamps: you find out every time, and you can demote the operation the moment something looks wrong.

Suggest is where trust gets interesting. The employee drafts the exact call it wants to make, and the draft parks as an approval request with the arguments frozen at that moment. A digest of those arguments is recorded; when a manager approves, the digest is verified again and the parked call executes exactly once. Not a re-run, not a fresh interpretation of what you probably meant: the thing you approved is the thing that happens. Reject it and nothing ran, and nothing retries.

Act means the employee executes reversible operations directly, with the full audit trail. The manager's explicit grant in the matrix is the standing authorization, and every call still records what ran and what came back. Irreversible operations are a different story: they are not grantable at all until autonomy is earned. Deleting things, moving money, anything you cannot take back stays off the menu for a new hire, full stop.

Earned is the operative word, and it is a threshold, not a vibe. Autonomy on an operation relaxes only after a sustained useful rate on that specific operation over weeks, plus a manager sign-off. The approval history makes the case for you: twelve identical approvals in a row on the same operation is not busywork, it is evidence, and the employee will surface it as a promotion request. That is exactly how it works with people. You stop reviewing someone's work when their track record says you can, and you can always start again.

The matrix itself is exportable, which matters more than it sounds. When a security review asks what your AI employee is allowed to do, the answer is not a paragraph about prompt engineering. It is a table: this employee, this tool, this operation, this level, set by this admin, changed on this date. The permission model is the audit artifact.

Autonomy you cannot inspect or revoke is not autonomy, it is exposure. The ladder means the question 'what can it do' always has a precise answer, and 'what should it do next' is a decision you make with evidence in front of you. We would rather ship an employee that starts slower and earns its way up than one that starts impressive and cannot be trusted alone.