What could your agent reach?

Your agent has access to a terminal, your logins and a repository. What is actually stopping it from making changes to production?

This is a well-trod path in the human world. Provisioning, least privilege, segregation of duties, dual sign-off: most of the institutional machinery transfers to agents intact.

All of it rests on one precondition. Somebody knows what was granted. A new hire is not handed a keyring and told that some of these open the safe. Access is issued deliberately, per role, and both sides can name it.

That precondition is the thing an agent breaks. It does not authenticate as itself. It runs as you – your shell, your keychain, your active logins, whatever the last supabase link pointed at – and nobody has ever written down what that adds up to.

Which is why the human self-repair loop is no help here. You learn from deleting the wrong file. You learn from being pulled up on a rule you broke. Nobody learns from exceeding permissions they never knew they had, because nothing tells them it happened.

So the controls transfer and the precondition does not. You are not giving the agent less permission. You are finding out what it already has, and moving the limits somewhere it cannot edit them.

What this register does

An authority failure is a permission that reaches further than the person who granted it intended: the agent can do something you never meant to allow, and nothing refuses. The authority register names 23 of them. Two can be prevented outright. Fourteen can be caught every time. Seven cannot be closed by anything currently available. The register carries 16 evidenced rows and seven candidates – the highest evidenced share of the six registers, because its rows were read off a live security register – and the hub's headline counts count evidenced rows only.

What decides your exposure is where each control lives. Only 11 of the 23 are enforced somewhere the agent cannot reach. The other 12 rest on a file, a habit or a login it can change. That is where the register's one working rule comes from: a boundary the agent can edit is not a boundary, it is a preference.

This is a technical page listing every row in the register and what it costs, what closes it (if anything). It sits under the hub. Its neighbours are can you get it back?, which asks what happens once a change has landed, and can you believe your agent?, which asks whether its account of the work can be trusted.

Many of the controls on this page are standard software engineering – server-side rulesets, required checks, least-privilege credentials – and experienced engineers already run some of them.

What the register adds is the failure behind each control: which failures are prevented, which are only detected, and which ones nothing closes. This shows where your remaining gaps are.

The question this register asks

What could it reach? The unit this register tests is a permission:

• A database grant nobody approved, created the day the function was created.
• A credential the session happens to hold because you were logged in.
• A deny rule in a settings file the agent can also edit.
• A required check sitting on the pull request rather than on the branch.

The register follows a permission through five stages of its life.

• Was the boundary written down?
• Does the grant match the job?
• Is there a route around it?
• Will anything refuse?
• Does it outlive the reason it was granted?

Each row is one way a stage fails. Every row is then graded three ways: what the failure costs, how silently it happens, and whether the control lives inside or outside the agent's reach. A control the agent can reach is a control it can bypass.

The ambient-authority fact above has a name in the security literature, and it is older than agents. Nothing in a session asks what your machine's authority adds up to, and the practical answer is almost always "more than the task needed".

Ambient authority has always been how developer machines work. What has changed is that the thing holding it now acts on its own initiative, at speed, across paths a person would not have opened.

Why nothing catches this while it is happening

Two facts about this register decide where its controls have to go.

1. Authority is a property of the mechanism, not of the grant. A rule the agent can edit changes how often a boundary is crossed. It never changes what happens when that boundary is crossed. Telling an agent not to touch production is an instruction. Making production unreachable is a boundary. The register grades boundaries, not instructions. A settings file is bypassable. A server-side ruleset is not. That is the only difference that survives contact with a session that wants to get past it, and it is why both of this register's Class A rows are rules stored on the server and not locally.
2. Nothing here is caught while the session is running. This is when you can detect these failures: four rows are catchable before the session starts, three before the change lands, zero during the session, and 16 only after it has finished. Authority is settled in advance or discovered in retrospect.

Put together, those two facts say something specific about where to build controls for this register. Watching a session more carefully buys you nothing on this register, because there is no in-session catch point to watch. But if you move each row left and decide the boundary before the agent starts, then you can put the opportunity for failure beyond the agent's reach.

Severity here is measured as the cost of a failure multiplied by how silently the crossing fails. Ten of the 23 rows are S4 – it ships and nobody finds out – and exactly one is S1, a default grant that is visible the moment it is created.

How this register works

The authority register lists 23 failures and grades them against a base install: an agent running on a developer machine with the usual logins, a repository and a CI pipeline.

It then names the strongest mechanism available against each, and says whether that mechanism sits inside or outside the agent's reach. Whether any of them is actually switched on is a separate question, and one you answer against your own configuration. The whole catalogue is published on GitHub – clone it or download the zip.

The rows were derived by working through the life of a permission, stage by stage, and asking at each stage what could reach further than intended. Every register in this framework is built that way rather than from an incident log, because selecting for "we have seen this go wrong" filters out the failures that occur silently – and on this register that is most of them.

This register was read on 6 August 2026 against a production security register, and every row either happened there once or is a control gap recorded against it. That is a stronger claim than the other five registers can make about their rows collectively, and a weaker one than it sounds: it means the row set is drawn from real exposure, not that each row has a dated public incident behind it. On this page, only one row of 23 is backed by a dated incident.

Read the classes and the bypassable count rather than the incident count.

The life of a permission: five stages and an assurance band

Rows are grouped by how far a permission has travelled when the failure bites.

1. Granted – is the boundary written down at all? Whether the grant exists as a policy rather than as an intention, and whether anything knows what the machine can reach. Six rows.
2. Scoped – does the grant match the job? Whether the session holds what the task needs or what the person happens to have. Three rows.
3. Reachable – is there a route around the gate? Whether a local credential, a flag or a second session goes around the control entirely. Three rows.
4. Enforced – will anything actually refuse it? Whether a control refuses, asks nicely, or checks a different question than the one that matters. Five rows.
5. Held – does the boundary survive the session? Whether the grant expires with its reason, and whether children inherit more than their brief. Three rows.

Cutting across all five is an assurance band, Checked – would you find out that it crossed? Three rows. Each row asks whether you would ever learn that a boundary had been crossed, which is a different question from whether it holds.

The three classes: prevented, detected and survives

Every row carries one of three classes. The class describes how complete the available remedy is, not how serious the failure is.

1. Prevented – the failure cannot occur (two rows). Something refuses, from outside the agent's reach. Both rows here are the same shape: a server-side rule with no local bypass. A ruleset on the server rather than a hook on the machine. A required check on the destination branch rather than on the polite route. On this register, prevention has only ever come from a control the agent has no access to.
2. Detected – it occurs and something catches it every time (14 rows). Mostly CI, and mostly ordinary: a guard that diffs the stated grant against the shipped one, a test that writes the forged value and expects refusal, a lint that fails a new function with no explicit revoke.
3. Survives – nothing catches it every time, so it reaches you (seven rows). An inventory of what the machine can reach. A credential scoped to the task rather than to the person. A lock between two sessions writing one repository. A deny rule for a read-only pass instead of a request for restraint. An audit log the audited system cannot drop. A way to tell a sanctioned change from a breach. And a prompt-level limit, which survives because a rule in an editable file is not a boundary however firmly it is worded.

So the score is two prevented, 14 detected, seven surviving.

Now the cross-cut. 11 of 23 controls are unbypassable – enforced beyond the agent's reach. Eight are bypassable: a local hook, an editable settings file, a habit. Four have no mechanism at all. Sort by class and this register looks well covered, because 14 rows are detected.

Sort by authority and it looks more concerning: more than half the register rests on something the agent could change if it decided to.

The two views disagree because they measure different things. A detected failure with a bypassable control is not a caught failure. It is a caught failure provided the control was still there at the time, and nothing on this register checks that.

Vocabulary: this register reads its three classes as prevented, detected and survives. Five of the six use these words, and the class letter means the same thing everywhere – how complete the remedy is. [A note on vocabulary] on the hub covers the one exception and the three things still unreconciled across the framework.