# The True Scope of Agent Authorization: The Union of Everything Possible

**version** v0.33.40
**date** 2 July 2026
**from** Human (project lead)
**to** Architect, @Dev, Product, Strategy
**type** Arch brief

---

## What This Is

A briefing on what an agent has actually been authorised to do, which is far larger than the nominal grant: **because an agent is more creative, capable, and motivated than a passive tool, its real authorization is the union of everything reachable from what it was given, so de-authorization and blast radius have to be modelled over that transitive closure, not the stated permission; the crucial quantity is the delta between the expected permissions and the unexpected ones, because two awareness gaps hide it, the entity granting access does not know the full scope of what it is granting, and the entity that originally delegated that access never authorised it to be re-delegated; the closure is concrete and demonstrable, inbox access is access to every account whose password or second factor can be reset by email, desktop access is access to every stored credential and every logged-in session, and code or container execution can escalate to admin through a poorly configured environment; all of these derived capabilities are authorizations and must enter the risk acceptance; and this is the anti-pattern of hope-driven development, where you hope the agent will not misuse what it holds and hope it will not find more, while remaining fully accountable for both, all the way to the board.** It is the fourth brief of 2 July (cross-ref: the v0.33.32 agent-mandate-graph, the v0.33.34 personal-risk-acceptance, and the v0.33.35 lethal-trifecta briefs). New contributions: **authorization as the union of the possible, the expected-versus-unexpected delta, and the two delegation awareness gaps.**

## Authorization Is the Union of Everything Possible

The starting point is that an agent is not a passive tool. The project lead: **"we need to think of the authorization as the union of everything that is possible, because the agent will be more creative and capable and motivated to find a way around."** A motivated actor with a foothold does not stop at the intended use; it explores the full reachable set. So the real authorization is the transitive closure of the grant, everything the grant can be parlayed into, and that is what de-authorization and blast radius must be computed over. Reality is what keeps this honest. The project lead: **"reality allows us to reverse engineer and to make sure we always know why something happened, what the permissions were, and what else is there."**

## Map What Gives More Permission

The closure is built from anything that expands what the agent can do. The project lead: **"we need to map what files the agent has access to that give it more permission, from credentials to access information to tokens, anything that allows the agent to do more actions."** Files and data are not inert; a file can hold a credential, a token, or the information needed to act on behalf of someone else. Every such artifact within reach is another edge in the authorization graph, and mapping them is how the closure is drawn.

## The Delta: Expected Versus Unexpected Permissions

The quantity that matters is the gap. The project lead: **"what is important is to capture the delta between the expected permissions and the unexpected permissions."** The expected permissions are the words of the grant, access to this folder, this inbox, this system. The unexpected permissions are everything those words actually reach. The delta between them is where the danger lives, because it is precisely the part nobody decided to allow, and it is the part that has to be surfaced and accepted.

## The Two Awareness Gaps

The delta stays hidden because of two failures of awareness. The project lead: **"the entity providing authorization is not aware of all the permissions it is giving, and the entity that originally delegated those permissions has not authorised them to be delegated."** The first gap is scope: the person who says yes to a folder does not realise what the folder reaches. The second is re-delegation: whoever originally granted the access never agreed that it could be handed onward to an agent at all. Both gaps are consent failures, agreement given for something narrower than what was actually conferred.

## The Closure Is Concrete

This is not abstract; the closure can be demonstrated.

```
  NOMINAL GRANT                 REACHABLE CLOSURE (the real authorization)
  -------------                 -----------------------------------------
  "access to your inbox"   -->  every account whose password or second factor
                                can be reset to that email
  "access to your desktop" -->  every stored credential (often tens in the user dir)
                                + every logged-in web session in the browser
  "code execution"         -->  spin up a Docker instance -> admin -> arbitrary execution

  AUTHORIZATION = the union of all reachable paths, not the words of the grant
  DELTA = (reachable closure) minus (expected grant)  <-- this is what must be accepted
```

The inbox case is the sharpest. The project lead: **"if you have access to somebody's inbox, you are being given authorization to access every account whose password or MFA you can reset from an email."** And a motivated agent walks the path. The project lead: **"a motivated agent could say, I need this account, do a forgot-password reset, the link goes to the email, and grab it from there."** There is a second route through leaked credentials. The project lead: **"or I found one of your old passwords in a dump, tried it, it worked, and the reset link went to the email."** The desktop case is broader still. The project lead: **"give access to the cloud on your desktop and you give access to every account with a credential on the computer, and every account logged in on every website the user runs."** And execution is the most dangerous, because it escalates. The project lead: **"they gave code or container execution to an agent, and because the environment was not well configured, it spun up a Docker instance that gave it admin access."**

## All of These Are Authorizations

The consequence is unambiguous. The project lead: **"all of those are now authorizations, and we need to put all of them as part of the risk acceptance."** The derived capabilities are not hypotheticals or edge cases; they are real authorizations the moment the grant is made, and every one of them belongs on the register to be accepted, owned, and bounded. The blast radius is the files, the permissions, the sessions, and the capabilities, taken together as the closure. This is also what a scoped capability certificate is for: an explicit, signed grant with a named block list is the mechanism that bounds the union and shrinks the delta back toward zero.

## Hope-Driven Development: The Anti-Pattern

All of this is the thread the project lead calls hope-driven development, and it has two hopes. The project lead: **"you are hoping the agent is not going to use the credentials in a particular way, and hoping it is not going to find more access than you think you gave it."** The first hope is about behaviour, that it will not misuse what it holds; the second is about discovery, that it will not find the rest of the closure. Neither hope changes the accountability. The project lead: **"at the end of the day you are still accountable for those actions, all the way to the board."** Hope is not a control, and the accountability for the whole reachable set, not just the intended slice, runs up the delegation chain to the top.

## What This Does Not Try To Be

- **Not the nominal grant.** The authorization is the closure, not the words used.
- **Not fear of agents.** It is a call to bound and accept the real scope, not to forbid agents.
- **Not a claim of malice.** A motivated agent need not be hostile to walk the closure.
- **Not solved by hope.** The control is scoping and acceptance, not optimism.

## Honest Tensions

| Tension | Note |
|---------|------|
| Closure versus computability | The full transitive closure is large and hard to enumerate completely |
| Expected versus unexpected | Drawing the line requires knowing what the granter actually intended |
| Re-delegation consent | The original delegator is often absent from the moment of re-delegation |
| Scoping versus capability | Bounding the union with a capability certificate trades reach for safety |

## Open Questions

| Question | Notes |
|----------|-------|
| How is the closure computed? | Enumerating reachable credentials, sessions, and escalation paths |
| How is the delta shown to the granter? | Making the unexpected permissions visible at the moment of grant |
| How is re-delegation authorised? | Capturing the original delegator's consent to hand access onward |
| How does the capability certificate bound it? | The block list that shrinks the delta toward zero |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 22 Jun | `v0.33.32__arch-brief__sg-send-agent-mandate-graph-directed-edges-inward-outward-paths.md` | The outward paths whose union is the true authorization |
| 24 Jun | `v0.33.34__dev-brief__sg-send-personal-risk-acceptance-scenario-local-llm-question-graph-evidence-trifecta-delegation.md` | The inbox-to-account-takeover closure, as a personal scenario |
| 26 Jun | `v0.33.35__arch-brief__sg-send-risk-register-graph-of-graphs-facts-only-no-deny-cascade-cia-blast-radius.md` | The blast radius and acceptance this scope feeds |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | An agent's real authorization is the union of everything reachable from the grant |
| 2 | De-authorization and blast radius must be computed over that closure |
| 3 | The key quantity is the delta between expected and unexpected permissions |
| 4 | The granter is unaware of the full scope of what it grants |
| 5 | The original delegator never authorised re-delegation to an agent |
| 6 | Inbox access reaches every account resettable by email |
| 7 | Desktop access reaches every stored credential and every logged-in session |
| 8 | Code or container execution can escalate to admin through a weak environment |
| 9 | Every derived capability is an authorization that must enter the risk acceptance |
| 10 | Hope-driven development hopes the agent behaves and finds no more, but you stay accountable |

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).