# The End To End Flow Is The August Worked Example With An Agent Installation As The Twin: The Grant Is A Tree Whose Nodes Need Control Labels Rather Than Just Names, Grants Are Artefacts Rather Than Principals, And Counting Acceptances Is The One Metric That Can Be Gamed

**version** v0.33.61
**date** 20 August 2026
**from** Human (project lead)
**to** Architecture, the RiskMandate team, the pki.sgit.ai site agent, Product

**type** Architecture brief

*Eleventh of 20 August. The hosted grant tree in this brief was measured inside a running agent container rather than described, including a network boundary that was tested by making requests. The local enumeration is taken from a published read-only audit tool rather than invented. The prior worked example and the fact-to-risk chain are quoted from the repository clone. Limitation: no local desktop install was measured, so the local tree is derived from what running under a user account means plus a third party's published module list, and the strength of any specific vendor's containment is not assessed here.*

---

## What This Is

The end-to-end flow the memo says is now within reach, the model it already belongs to, and four corrections that change what gets built: **the memo proposes taking two concrete scenarios, an agent running on your own machine and one running on the web, mapping their grants and mandates as facts, publishing that on the registry site with the evidence and incidents behind it, deriving risks from it on the risk product, and treating the number of risks accepted as the measure of success; the flow does not need designing, because it is the worked example of 2 August with a different twin, where reality was a running system, facts about it were evidenced or explicitly marked unevidenced, findings were derived from a fact plus an obligation rather than asserted, risks formed one chain across altitudes, and decisions were separate nodes each carrying a named acceptor and an interval, so substituting an agent installation for an underwriting system instantiates a model that has already been argued through; the memo's most useful new structure is that a grant is a tree of subgrants rather than a flat list, and the load-bearing part is not the tree but the label on each node, because the memo's own question of how strong the controls are has a general answer that needs no vendor-specific claim, which is that a control bounds a grant only when it is enforced by something the grant does not include, giving three tiers of boundary, setting and expectation, and placing a tool's own folder restriction in the second tier because the grant includes the ability to run code as the user the tool runs as; the two scenarios are not two examples of one thing, they are the two populations from 16 August, and neither dominates, because a local agent has an enormous grant and a containment you own and could strengthen, while a hosted agent has a smaller grant and a containment you can neither inspect nor change, which was tested here by finding root inside the container and an egress allowlist that root could not defeat; the proposal that every grant and mandate carry a keypair should be dropped, because a rule set earlier today already covers it, since an agent is a principal and a grant is an artefact, so grants and mandates want an identifier, a content hash and their issuer's signature rather than identities of their own; the memo's instinct that prohibitions present better is right and does not conflict with this morning's finding that they are unsafe as the enforcement form, because the two are different layers, so the person reads and accepts a list of things the agent will not do while the system stores and enforces the allow-list, generated from each other; and the success metric needs correcting, because a count of acceptances is maximised by making risks easy to accept, which is the failure mode the corpus already named when it separated accepted from acceptable, so the primary measure should be risks stated well enough to be accepted, meaning each one carries a named acceptor and an interval, with the acceptance count kept as a secondary and gameable figure and the declines counted alongside it.** It is the eleventh document of 20 August (cross-ref: the v0.33.55 worked example, the v0.33.53 accepted-is-not-acceptable brief, the v0.33.59 nhi site brief, the v0.33.61 grant and mandate brief, and the v0.33.61 register interface brief). New contributions: **the flow located in the existing model, the grant tree's node labels identified as the load-bearing part, the three-tier control test, the two scenarios placed as the two populations with neither dominating, one hosted tree measured including a tested boundary, grants ruled artefacts rather than principals, prohibitions resolved as a presentation layer, and the acceptance metric corrected.**

## The Flow Is Already Specified, With A Different Twin

The memo describes a chain running from what an agent can reach, through facts and evidence, to risks at several altitudes, to somebody accepting them. **That chain exists and was worked end to end on 2 August.**

The worked example took one provision of a regulation and one deployed system and ran it through: reality, then a twin where the graph meets the running thing, then eight facts each backed by evidence or explicitly marked unevidenced, then obligations attaching at the twin, then findings derived from a fact plus a provision rather than asserted, then four risks forming a single chain with each derived from the one below, then decisions as separate nodes each carrying a named acceptor and an interval, then questions as nodes whose unanswered ones were the most valuable output.

Substituting this memo's subject:

| The 2 August model | This scenario |
|---|---|
| Reality | The agent, installed and running |
| **The twin** | **The agent installation, which is what facts attach to** |
| Facts | The grant tree, and the mandate, each evidenced or marked unevidenced |
| Evidence | The audit output, the configuration export, the tested boundary |
| The provision that findings derive from | **The mandate**, which is the statement of what was intended |
| Derived finding | **Excess authority**, computed rather than asserted |
| The risk chain | Developer, team lead, security, board |
| Decisions | Separate nodes, each with an acceptor and an interval |
| Questions | The ones with no evidence behind them |

**That mapping is the whole flow**, and the substitution that makes it work is the fourth row. In the August example a finding was arithmetic because it was a fact set against a written obligation: thirty days of logs against a six month requirement. Here the same move applies. **Excess authority is a fact about the grant set against a statement of the mandate**, which makes it computed rather than a matter of opinion, and that is what makes it defensible in front of somebody being asked to accept it.

So the work is instantiation rather than design, and the parts that genuinely need building are the grant tree, its labels, and the interface.

## The Grant Is A Tree, And The Nodes Need Labels More Than Names

The memo's structural contribution. The project lead: **"a grant, in a way, has subgrants"** and **"the grant ultimately is a tree that that also contains the grants, and then the grants have management control."**

A flat list of what an agent can reach is not useful, because the interesting relationships are containment ones. Running as your user contains reading your files, which contains reading your credential files, which contains reaching every service those credentials open. **The blast radius is a path through the tree, not an item in a list.**

But enumerating the tree is the easy half and it will be done by tooling. **The half that decides whether any of this is worth reading is the label on each node**, and the memo asks the right question about it. The project lead: **"how strong are those controls, right? But this is where it's almost like on security review."**

So each node in the tree carries the same shape the register interface brief gave every edge earlier today: not just what is reachable, but what stands between the agent and it, who enforces that, and whether anybody has checked.

## A Control Bounds A Grant Only If The Grant Does Not Include It

The general test, and it needs no claim about any particular product, which matters because vendor-specific security assertions age in weeks and invite argument.

> **A control bounds a grant only when it is enforced by something the grant does not include.**

That gives three tiers, and every containment mechanism in either scenario falls into one of them:

| Tier | Enforced by | Example shape | Worth |
|---|---|---|---|
| **Boundary** | Something outside the grant: the operating system, a separate user account, a container, a network policy, a remote service | An egress allowlist the process cannot edit | **Real.** It holds against a compromised agent |
| **Setting** | The tool itself, running inside the grant | A directory restriction the application enforces, an approved-tools list, an auto-approve toggle | **Bypassable** by anything able to run code as that user, which the grant includes |
| **Expectation** | Nothing. It is written in a prompt or a policy file | Instructions in a project rules file | **None.** It is a mandate, and this morning's brief says so |

**The middle tier is where most of what people currently rely on sits**, and it is the tier that reads like a boundary and behaves like a setting. This is this morning's own line arriving in a new place: a safe inside a house you handed the keys to is a delay, not a boundary. A folder restriction enforced by the application, running as you, inside a grant that includes running programs as you, is the same object.

The memo reaches the same conclusion about the command line case and is right for a reason worth stating precisely. The project lead: **"from the CLI, ironically I think is even more dangerous because I think a lot of them are even less contained... and the whole YOLO mode means that you know, and we know that doesn't work."** The published audit tool named below looks for exactly this: dangerous flags in shell initialisation that skip permission prompts. **A prompt that can be disabled by a flag in a file the agent can write is a tier-three expectation wearing tier-two clothing.**

So the grant tree's node label is:

| Field | Values |
|---|---|
| What is reachable | The subgrant |
| What stands in the way | Named mechanism, or nothing |
| Who enforces it | **Boundary, setting, or expectation** |
| Evidence | Tested, documented, or asserted |
| Date checked | Because this ages |

**That third row is the column the whole page exists for**, and it is the one nobody currently publishes.

## The Two Scenarios Are The Two Populations, And Neither One Wins

The memo picks local and web as two scenarios. **They are the run and rent split from 16 August**, which means the site already has a thesis about them and the two trees have structurally different shapes rather than different contents.

The counterintuitive part is worth leading with, because the instinct is that local is safer:

| | Agent on your machine | Agent hosted by a vendor |
|---|---|---|
| Size of the grant | **Enormous.** It runs as you, so it inherits everything you can reach | **Smaller.** It reaches a workspace, not your life |
| Who owns the containment | **You.** You could add a separate user, a container, a network policy | **The vendor.** You can install nothing |
| Can you inspect the containment | **Yes** | **No** |
| Can you strengthen it | **Yes, and almost nobody does** | **No** |
| Can you verify what it claims | **Yes, by testing** | **No.** Tested today and there is no attestation |

**So neither dominates.** The local case is a large grant with a boundary you own and have not used. The hosted case is a small grant with a boundary you cannot see. Those produce different risk statements, different acceptors, and different remediation, and a product that presents them as two rows of one table will mislead.

And it gives the honest one-line version for each: **locally, the containment is available and unused. Hosted, the containment may be excellent and is unverifiable.**

## Both Trees: One Measured, One Already Enumerated

Fact-driven, as the memo asks, which means measuring rather than describing.

**The hosted tree, measured inside a running agent container on 20 August.** Findings, with the boundary tested by making requests rather than by reading documentation:

| Node | Observed |
|---|---|
| Process identity | **Root inside the container.** No internal boundary at all |
| Escalation | Passwordless, so the distinction between the agent's user and the box's administrator does not exist |
| User files | None, beyond what was deliberately uploaded into the session |
| Credential stores | Present but empty of usable material: an empty key directory, a configuration file with no keys in it |
| Signing identity | **A configured commit signing key**, so the agent can produce signed commits under a stated identity |
| Other accounts on the box | Two, readable |
| **Network egress** | **Allowlisted.** A package index resolved and returned a response; an arbitrary public host returned nothing |

The last row is the interesting one, and it is a tier-one boundary demonstrated rather than claimed: **the agent is root and root cannot defeat it**, because it is not enforced by anything inside the container. That is the whole taxonomy above in one measurement, and it is a good thing to put on the page, because it is a case where the answer is favourable and the site is more credible for showing one.

**The local tree does not need inventing.** A published read-only audit for exactly this purpose enumerates it in modules, and its structure maps onto the tree directly: credentials, covering key files and their permissions and whether an agent is loaded, cloud and cluster credentials, package and container registry tokens, code host credentials, environment files in the workspace, signing keys and wallets; agent tool configuration, covering installed command line agents, permission-skipping flags in shell initialisation, integration configurations holding plaintext secrets, project rules files and approved-tool lists; token scope, distinguishing long-lived credentials from short-lived ones; environment separation, including whether a production database string is sitting in a development workspace; and sessions and history, classifying secrets found in shell history, agent session files and chat transcripts.

Two things to take from it rather than rebuild.

**Its module list is a ready-made first version of the local grant tree**, and adopting it means the page is comparable with an existing public tool rather than being a private taxonomy nobody can check.

**And its last module independently confirms a finding made here earlier today.** The shared drive brief established by inspection that a session transcript is a superset of every file the session read, and therefore that excluding a secret by path does not exclude its contents. That audit classifies secrets found in agent session files and chat transcripts as a category of its own. **Two independent routes to the same conclusion**, which is worth recording because it moves the claim from an observation to a finding.

## Grants And Mandates Are Artefacts, So Sign Them Rather Than Key Them

A correction, and the rule that decides it was set earlier today rather than invented here. The project lead: **"each of those grants and mandates for now should have a public and a private key."**

This morning's register brief established the distinction while answering a different question about skills: an agent is a principal, because it acts, can be delegated to, can hold a mandate and can be wrong, whereas a skill is an artefact with no interests that takes no actions, and giving an artefact a keypair suggests it could be a party to something, which it cannot.

**A grant is an artefact. A mandate is an artefact. Neither acts.**

| Object | Needs | Does not need |
|---|---|---|
| An agent | An identity: a keypair, because it signs and is signed to | |
| A grant | An identifier, a content hash, and the signature of whoever observed or issued it | **A keypair of its own** |
| A mandate | An identifier, a content hash, and the signature of its issuer | **A keypair of its own** |

The practical consequence is not stylistic. A keypair per grant and per mandate multiplies the private key inventory by every object in the system, and this morning's brief established that a published or mislaid private half can never be promoted or revoked meaningfully. **Signing gives everything the memo wants from keying**, which is provenance, integrity and attribution, and it leaves the number of private keys equal to the number of parties rather than the number of documents.

The exception worth naming so it is not lost: an agent presenting a mandate presents a signed document, and the signature is its **issuer's**. That is what makes a mandate's trust ceiling its issuer's, which was reached independently earlier today.

## Prohibitions Are The Presentation Layer, Allow-Lists Are The Enforcement Layer

The memo returns to prohibitions and adds something this morning's brief did not have. The project lead: **"the mandate is also what not to do, which is interesting... this actually might be a really nice way to present it."**

This morning's finding stands: a mandate written as prohibitions widens silently whenever a supplier adds a capability, because a deny-list cannot exclude something that did not exist when it was written, so the enforceable form has to be an allow-list.

**And the memo's point is about a different layer, so both are right.** The prohibition list is enormously more legible. Compare what a person is being asked to accept:

| Presented as an allow-list | Presented as prohibitions |
|---|---|
| May read files under one project directory; may invoke three named tools; may open outbound connections to two hosts | **Will not read your credentials. Will not open your browser sessions. Will not act as you anywhere else. Will not reach other machines on your network** |

The right-hand column is what somebody can actually accept or refuse. The left-hand column is what the system must store and check.

> **Generate one from the other.** The person reads and accepts the prohibitions. The system enforces the allow-list. The prohibitions are a rendering of the allow-list's complement over a known capability set, and they carry a stated date, because the moment the capability set grows the rendering is stale.

That last clause is where the two findings meet rather than collide: the deny-list is unsafe as a stored rule and safe as a generated view, precisely because a generated view can be regenerated and a stored rule cannot notice that the world moved.

**And this matters for the memo's own objective**, because a person cannot accept a risk they cannot understand. The presentation form is not cosmetic; it is upstream of the metric.

## Counting Acceptances Is The One Metric That Can Be Gamed

The correction that matters most, because it is the stated objective. The project lead: **"the overall objective here is to get the risks accepted. So the measure of success is how many risks get accepted on this."**

**The direction is right and the metric on its own is the one that inverts under pressure.** A count of acceptances is maximised by making risks easy to accept: shorter statements, smaller scopes, softer wording, a single button. A product optimised on that number converges on blanket acceptance by people who did not read, which is worse than no register at all, because it manufactures evidence that somebody considered it.

The corpus already has the vocabulary. On 28 July it established that **accepted and acceptable are orthogonal axes**, and on 9 August it recorded the same hazard about simulating executive responses, that the capability which surfaces the questions a case cannot answer will, pointed the other way, find the version most likely to be approved.

The memo's own second question is the better objective and it is in the same sentence. The project lead: **"what's the user experience, and how do they understand, and what do they take out of it in terms of understanding the... risks that they are buying with running agents in their environment."**

So the metric family:

| Measure | Why |
|---|---|
| **Risks stated well enough to be accepted** | The primary one. A risk qualifies only if it can carry a named acceptor and an interval, which is the test settled on 28 July |
| Risks accepted, with a named person and a review date | Secondary, and only meaningful given the first |
| **Risks declined, escalated, or sent back** | **A hundred percent acceptance means the risks are trivial or the process is theatre** |
| Acceptances that survived their review | The only measure of whether anybody meant it |
| Risks that could not be stated | The gap, and the most informative number in the set |

**The third row is the one to instrument first**, because it is the cheapest test of whether the product is doing anything. And the last row is this corpus's own habit: the risks the tool could not express are more interesting than the ones it could.

## A Pre-Computed Tree Is A Dated Claim About Somebody Else's Product

The memo's user experience insight is good and it carries an obligation. The project lead: **"we're going to be answering for them because we already know."**

Asking three questions and rendering a prepared tree is the right interaction, and it is also **publishing an assessment of other people's products under their names**. The rules for that were settled on 16 August for the comparison pages and apply here without change: every entry carries a **verification date and a re-run method**, the method is published before the findings, and the participant writing it is named on the page rather than in a footer.

Two specific consequences.

**Each node's label needs its own date**, not the tree's. A vendor changing one default invalidates one row, and a tree dated as a whole will be quietly wrong in one place while looking current.

**And the re-run method for the local tree already exists**, which is a gift. Pointing at a published read-only audit and saying this is how we produced these rows, run it yourself, is stronger than any assertion the site could make, and it costs nothing.

The commercial shape then falls out of the architecture rather than being attached to it. The memo sees it. The project lead: **"the ability to add new ones if you have an LLM powered, based on the same model, and which then leads to our token consumption, which is our operation model."**

| Path | Cost to serve | What it is |
|---|---|---|
| The prepared library: pick your agent, see the tree | Effectively nothing per visitor | The free tier, and the reason to visit |
| Describe your own setup and have a tree derived | Tokens per use, metered on the existing ledger | The paid tier |

That is a clean split and it needs no new billing thinking, because the ledger designed on 6 August is generic on unit type by construction.

## The Flow, Assembled

```
  REALITY        the agent, installed and running

  TWIN           the installation. Everything below attaches here

  FACTS          the GRANT TREE, node by node, each labelled
                 boundary / setting / expectation, each dated
                        +
                 the MANDATE, stored as an allow-list,
                 presented as prohibitions

  EVIDENCE       audit output, tested boundaries, published incidents.
                 Absence recorded as absence, not left blank

  FINDING        EXCESS AUTHORITY = grant tree minus mandate.
                 Computed, not asserted. Plus the SHORTFALL,
                 where the mandate needs what the grant lacks

  RISKS          one chain, altitude by altitude, in each
                 altitude's own language

  DECISIONS      separate nodes. Named acceptor. Interval.
                 An unaccepted risk escalates without an escalator

  OBSERVABILITY  who checked which mandate, in the issuer's own lane
```

**Nothing in that column is new except the two boxes in the middle.** The rest was settled between 17 July and 2 August, and the memo is right that the pieces are now in place; what it underestimates is how many of them were already finished.

## What This Does Not Try To Be

- **Not a new model.** It is the 2 August worked example with an agent installation as the twin.
- **Not a vendor security assessment.** The test is general, and no specific product's containment is graded here.
- **Not a claim that hosted is safer.** It has a smaller grant and an unverifiable boundary, which is a different position rather than a better one.
- **Not an endorsement of keypairs for grants.** Grants and mandates are artefacts, so they get signed.
- **Not a target of maximum acceptances.** That number inverts under pressure, and the declines matter as much.

## Honest Tensions

| Tension | Note |
|---------|------|
| Acceptance as the objective | It is the right direction and the number is gameable, and the version that is not gameable is harder to explain to a buyer |
| Publishing prepared trees | It is the entire user experience and it is a dated assessment of other people's products, maintained forever by somebody |
| The three-tier control test | It is general and needs no vendor claim, and applying it will label a great deal of what people currently rely on as a setting, which will be argued with |
| Neither population dominating | It is the honest finding and it denies the reader the simple answer they came for |
| Prohibitions as a generated view | It reconciles legibility with safety and it means the thing the user accepted is a rendering, so acceptance is of a view rather than of the stored rule |
| One measured hosted tree | It is real evidence and it is one vendor, one surface, one date, and generalising from it would be the error this brief warns about |

## Open Questions

| Question | Notes |
|----------|-------|
| What does the user actually accept, the rendering or the rule? | If the prohibitions are generated, the acceptance record must say which version was shown |
| Who maintains the prepared trees? | Every node is dated and a vendor default change invalidates rows silently |
| How is the shortfall detected? | Excess needs the grant enumerated; the shortfall needs the mandate enumerated and nobody has that yet |
| Does a boundary claim need re-testing, and how often? | The egress test here took two requests, so the cost is low and the cadence is unowned |
| What is the acceptor for a personal install? | The developer is the only candidate and is also the beneficiary, which is the weakest possible acceptance |
| Are the two scenarios two products? | Different grants, boundaries, acceptors and remedies, presented so far as one page |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 2 Aug | `v0.33.55__arch-brief__sg-send-end-to-end-worked-example-article-26-5-creditworthiness-agent-fact-to-board.md` | The flow, complete, with a different twin; this substitutes an agent installation for an underwriting system |
| 28 Jul | `v0.33.53__strategy-brief__sg-send-accepted-is-not-acceptable-orthogonal-axes-appetite-renamed-article-9-mandates-judgement-without-defining-it.md` | Accepted and acceptable as orthogonal, and the test that a risk carries an acceptor and an interval |
| 20 Aug | `v0.33.61__strategy-brief__grant-is-not-the-mandate-the-gap-between-them-is-the-exposure-nobody-accepted.md` | The vocabulary, the allow-list finding this reconciles with presentation, and the shortfall region |
| 20 Aug | `v0.33.61__arch-brief__register-was-designed-in-june-published-keypairs-are-fixtures-not-identities.md` | Principals against artefacts, which decides that grants and mandates are signed rather than keyed |
| 16 Aug | `v0.33.59__strategy-brief__nhi-site-two-populations-industry-answers-only-agents-you-run.md` | The two populations, which are the memo's two scenarios, and the participant rules the prepared trees inherit |
| 20 Aug | `v0.33.61__dev-brief__shared-drive-is-a-watcher-a-queue-and-three-vaults-batching-was-specified-in-may-ignore-file-blocks-it.md` | The transcript as a superset of what a session read, confirmed independently by the audit tool's session module |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | The flow is the 2 August worked example with an agent installation as the twin |
| 2 | Excess authority plays the role a regulatory provision played there, which makes the finding computed rather than asserted |
| 3 | A grant is a tree of subgrants, and blast radius is a path through it rather than an item in a list |
| 4 | A control bounds a grant only when enforced by something the grant does not include |
| 5 | That gives three tiers, and most current containment is a setting rather than a boundary |
| 6 | The two scenarios are the two populations, and neither dominates |
| 7 | Locally the containment is available and unused; hosted it may be excellent and is unverifiable |
| 8 | Measured in a hosted container: root inside, no internal boundary, and an egress allowlist root could not defeat |
| 9 | The local tree does not need inventing, since a published read-only audit enumerates it in modules |
| 10 | Grants and mandates are artefacts, so they get an identifier, a hash and an issuer signature rather than keypairs |
| 11 | Prohibitions are the presentation layer and the allow-list is the enforcement layer, generated from each other and dated |
| 12 | A count of acceptances is maximised by making risks easy to accept, so declines and unstatable risks must be counted beside it |

---

## Sources

- A published read-only audit of a local developer machine for agent-related risk, enumerating credentials including key files and their permissions and loaded agents, cloud and cluster credentials, package, registry and container tokens, code host credentials, environment files in the workspace, signing keys and wallets; agent tool configuration including installed command line agents, permission-skipping flags in shell initialisation, integration configurations containing plaintext secrets, project rules files and approved-tool lists; token scope distinguishing long-lived from short-lived credentials; environment separation including production database strings present in development workspaces; and a sessions and history module classifying secrets found in shell history, agent session files and chat transcripts, with findings recording only path, type, count and a redacted fingerprint: https://github.com/bartek-filipiuk/ai-agent-audit
- The measured grant tree of one hosted agent container, including process identity, passwordless escalation, the absence of user credential material, a configured commit signing identity, other accounts present on the host, and an egress allowlist established by issuing one request that resolved and one that did not: measured directly on 20 August 2026, held with the project record
- The 2 August worked example, with its reality, twin, evidenced and unevidenced facts, findings derived from a fact plus a provision, a four-altitude risk chain, decisions as separate nodes carrying a named acceptor and an interval, and unanswered questions as the exercise's primary output; and the 28 July finding that accepted and acceptable are orthogonal axes and that a risk is a statement able to carry a named acceptor and an interval: the project repository, cloned and searched on 20 August 2026, with both documents named in the relationship table above

---

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