# Grant Is Not Mandate: The Gap Between Them Is Exposure Nobody Accepted, It Is Measurable Today, And It Corrects A Claim Made In July **version** v0.33.61 **date** 20 August 2026 **from** Human (project lead) **to** Strategy, Architecture, the RiskMandate team **type** Strategy brief *Second of 20 August. Drawn from two memos: the first proposing the split, and a later one the same day sharpening both definitions and adding prohibitions, which is folded in here rather than written separately because this is the document where the vocabulary is defined. Records a correction to a July claim, checked against that brief in the repository rather than recalled. The declaration format for scope of authority is checked and cited, and the estate's own key registry site was fetched directly, which established that most of this brief's mandate vocabulary is already published there rather than new. Limitation: the repository clone available today ends at 14 August, so the 16 and 19 August briefs are known through the day index and the handoff pack rather than read in full.* --- ## What This Is A vocabulary split the memo proposes, the July claim it corrects, and the measurement it makes available: **the memo separates two words that this corpus has been treating as one, proposing that a grant is what a party has been given access to and a mandate is what it is allowed and expected to do, and observing that in practice the first is very much larger than the second, so an agent given a code host credential holds a grant covering every repository its human could reach while its mandate for the afternoon was to commit to one branch of one project; that split contradicts a claim made on 17 July, where the identification of the two was stated as a key claim in the words that to grant is to mandate, and the correction is worth making carefully because the July brief was right about what it was describing, namely that a person carries the exposure of whatever they were handed whether or not anybody wrote it down, and wrong to conclude from that accounting identity that the two objects are the same, since treating them as one makes the difference between them invisible and the difference is where all the exposure lives; naming the difference makes it countable, because grant minus mandate is excess authority, it is the same quantity the corpus has been calling blast radius from the other end, and under the corpus's own rule it is unaccepted by construction, since nobody can accept an exposure nobody has written down, which means it defaults to critical and escalates without anybody escalating it, exactly as the unowned regulatory risk did in the August worked example; the memo's own illustration is better than it realises and needs one correction, because telling an agent in a chat to commit to a development branch is not a narrow mandate, it is an instruction with no issuer, no interval, no record and no revocation path, and an instruction that cannot be checked afterwards is not a mandate at all, so a mandate needs five fields before it is worth the name; there are then two worlds and they should not be presented as alternatives at the same maturity, since an execution broker that holds the credential and performs the action bounds the grant itself and is enforcement by construction, while a declared mandate handed to an agent that already holds a broad credential is instrumentation, and the corpus's own position is that you instrument before you enforce, which makes the declared mandate legitimate and makes describing it as a control dishonest; the memo's hedge that frontier models might honour mandates well enough is a genuine hypothesis and it is cheap to test, and the test has a number, but compliance measured on a cooperative agent says nothing about an injected one, because ambient authority means the attacker asks the deputy to use the authority it already holds; and the mandate has a partial home already, since published agent cards declare scope of authority, spend caps and what requires human approval, leaving the issuer signature and the interval as the missing half.** It is the second document of 20 August (cross-ref: the v0.33.49 risk mandate brief, the v0.33.56 plugins brief, the v0.33.60 service twin brief, the v0.33.55 worked example, and the v0.33.53 accepted-is-not-acceptable brief). New contributions: **the grant introduced as a third term beside the identity and mandate the registry site already publishes, the definitions sharpened to a union conferred at assignment and an expectation that may carry prohibitions, prohibitions shown to be unsafe as the enforcement form because a grant's vocabulary is set by somebody else and grows, the correction to the July identification, excess authority named as the unit and related to blast radius, the honest separation of enforcement from instrumentation, the compliance experiment and its limit, and the declaration format identified.** ## The Split, In The Memo's Own Words The memo reaches for the distinction and asks for the terms to be settled. The project lead: **"I think you have a grant and a mandate, because I think let's get these terms right, because it's almost like the grant is what we are given access to. Maybe there's a better word for it, but that's kind of what I'm thinking of. And then the mandate is what I'm allowing or I'm expecting them to have."** Grant is the right word and does not need replacing. It is already load-bearing in this corpus in exactly this sense: plugins are capability grants, and the shipped interface describes four capabilities where an append token grants write and an enumeration key grants list and fetch. Adopting it here is consistent rather than colliding, which is worth stating because three naming collisions have been caught in this corpus in the last fortnight and this is not a fourth. | Term | Means | Held by | Enforced by | |---|---|---|---| | **Grant** | The union of capabilities conferred when an identity, account or key is assigned | The party acting | The system issuing the credential | | **Mandate** | What the party is authorised and expected to do, as permissions and, informally, as prohibitions | The party acting, as a statement | **Usually nothing** | The last cell is the whole subject of this brief. ## The Definitions, Sharpened, And Prohibitions Are Not The Complement Of Permissions A later memo the same day tightened both terms and added one thing the first pass missed. On the grant. The project lead: **"the grant, at least on the definition that we have, is everything that's possible. Is the ability to connect to a GitHub repo, is the ability to connect to write to the entire Git repo or make changes, read, write. Is basically is the union of all the capabilities that just been given when we assign the identity or the account or the API key."** Two words there are load-bearing. It is a **union**, so it is as wide as the widest of several conferrals rather than the intersection of what any of them intended. And it is fixed **at assignment**, which is where the drift starts, because nobody returns to it afterwards. On the mandate. The project lead: **"the mandate is what the business account or the business owner of the expectation that we're giving the agent to do. So that's the mandate, and the mandate could be don't do other things than this, only read this file, don't delegate this authority. Don't do other actions. You know, if actually the mandate could be do and don't, so it is interesting."** **The last clause changes something.** A mandate may contain prohibitions and not only permissions, and that is not a stylistic choice between two ways of writing the same thing. ### The Two Forms Behave Differently Because The World Is Open In a closed world, where the set of possible capabilities is fixed and known to both parties, an allow-list and a deny-list express the same set and either will do. **This world is not closed.** A grant's vocabulary is defined by somebody else, a code host or a model provider or a cloud, and it grows on their release schedule without asking anybody here. | Mandate form | What happens when the provider adds a capability | |---|---| | **Allow-list.** May do A and B | **Correctly excluded.** It was never named, so it is not permitted | | **Deny-list.** Must not do X, Y or Z | **Silently permitted.** It is absent from the list because it did not exist when the list was written | So a mandate written as prohibitions **widens by itself**, quietly, every time a supplier ships a feature. Nothing in this estate would notice, because the event that changes the mandate's meaning happens in somebody else's repository. That points where the corpus already points. The vault runtime documents a deny-by-default permission model, which is an allow-list, and enforcement belonging where it cannot be bypassed has been reached five times from different directions. ### It Also Constrains The Measurement Worth stating because it qualifies the section below. **Excess authority is only well defined when the mandate is an allow-list.** Grant minus mandate is a set difference, and a difference taken against a deny-list is not a number, it is the whole open world minus three named items. So the measurement this brief proposes carries a precondition on the form of the thing being measured, and a report produced from deny-list mandates would be meaningless rather than merely imprecise. ### And Prohibitions Still Belong In The Record They should be kept, and kept somewhere other than the enforcement surface. A prohibition carries intent that an allow-list cannot express. Do not delegate this authority says something about **why**, not only about what, and it remains legible to a person reading the record months later who is trying to work out what the issuer was worried about. That is worth preserving. > **The enforceable mandate is the allow-list. Prohibitions are annotations on it: recorded, reviewable, and never what a checker consults.** That also matches the decidability finding later in this brief. A prohibition that names an operation the system can see merely restates the allow-list. A prohibition that names an intention was never enforceable in the first place, and writing it in the imperative is precisely what disguises that from the person who wrote it. ## This Corrects A Claim From 17 July Recorded plainly, and with care, because the earlier brief was more right than a quick reading suggests. On 17 July, `v0.33.49__strategy-brief__sg-send-what-we-sell-is-the-risk-mandate-...` set out that the authorisation point and the mandate are the same object, that every grant is a mandate, and it carried as a numbered key claim that **to grant is to mandate, and to mandate is to accept.** **What that brief got right, and which stands.** As an accounting identity it is correct and it was the argument that made the product legible. Whatever a role or an agent has been handed, they are carrying the exposure of it, whether or not anybody decided to give it to them, and stating that turns an invisible liability into a document with a name and a clock on it. Nothing here retracts that. **What was wrong was the inference.** From the fact that a party carries the exposure of its grant, the brief concluded that the grant and the mandate are one object. They are not, and collapsing them has a cost: **if grant equals mandate by definition, the difference between them cannot be described**, and the difference is where every incident in this corpus has actually occurred. The corrected form: > A grant confers a mandate only where the two coincide. Everywhere else, the excess is authority the party holds, was never authorised to use, and nobody accepted. The July identity is therefore the special case, and it is the rare one. ## Excess Authority Is The Unit, And It Is Already Named Once the two are separate, the interesting quantity is the difference, and the memo's own example gives it clearly. The project lead: **"right now, when we map, for example, the mandate of a particular agent, a particular access, let's say to GitHub, right from Claude, he has a much bigger grant than a mandate."** ``` GRANT every repository the human authorised, read and write, indefinitely | | <------- EXCESS AUTHORITY: held, unauthorised, unaccepted | MANDATE commit to one branch of one project, this afternoon ``` Three things follow immediately, and all three connect to positions this corpus already holds. **It is blast radius, seen from the other end.** Blast radius asks what a compromise reaches. Excess authority asks what was handed over beyond what was needed. They are the same volume measured from opposite directions, and the corpus mentions blast radius in over three hundred documents, so this is a new name for a quantity already central rather than a new concept. **It is unaccepted by construction.** Under the rule settled on 28 July, a risk is something that can carry a named acceptor and an interval. Excess authority carries neither, because nobody wrote it down, so it cannot have been accepted. Under the corpus's own escalation rule an unaccepted risk defaults to critical and rolls upward, which means **excess authority escalates without anybody escalating it**, exactly the mechanism demonstrated by the unowned regulatory risk in the 2 August worked example. That is not a new mechanism to build; it is an existing one with a new input. **And it is the thing the risk product should show.** The July brief demoted the register to an output of the mandate. This sharpens what the output contains. A register row that says an agent has access to a code host is not informative. A row that says the agent's grant covers forty-one repositories while its mandate covered one, that the difference has no acceptor, and that it has been that way for six weeks, is a finding with a number in it. ## An Instruction In A Chat Is Not A Mandate The memo's second example is the sharpest thing in it, and it needs one correction. The project lead: **"at the moment I sometimes go to a cloud agent and say, hey, can you commit now to dev? But that's just me saying in a chat somewhere I wasn't registered."** The diagnosis is right and the framing is slightly off. That utterance is **not a narrow mandate that failed to be recorded. It is an instruction, which is a different kind of object.** An instruction directs an action now. A mandate is a durable statement that can be checked afterwards by somebody who was not there, which is the same standard this corpus applies to a brief. So a mandate needs five fields before it earns the word: | Field | Why it is required | |---|---| | **Issuer** | Somebody authorised this, and their key says so | | **Subject** | The identity it binds, by fingerprint rather than by name | | **Scope** | What may be done, stated so a violation is decidable | | **Interval** | When it expires, because a mandate with no clock is a grant | | **Revocation path** | How it is withdrawn before expiry, and where a checker looks | The interval is the one that connects everything. The corpus already requires that a risk acceptance carry a named acceptor and a review interval, and a mandate is the same object pointed forwards. **A mandate with no expiry is indistinguishable from a grant**, which is how most standing access came to exist in the first place. **Four of those five are already published on the estate's own key registry site, and the fifth is implied there**, so the corpus should credit that rather than arrive at them fresh. That site sets identity and mandate out as two independent statements, saying in its own words that a mandate is that this agent may do these things, until this date, on whose authority, and that identity and mandate are independently revocable. That is a subject, a scope, an interval, an issuer, and a revocation path, on a public page before this memo was recorded. **So the five fields are not this brief's contribution. The third term is.** Identity and mandate are both statements about what was authorised. A grant is a fact about what a credential permits whether or not either was ever written down, which is why it can be larger than both, and the finding here is the distance between the second and the third. Note the consequence for the fixture personas in the companion brief: a mandate is signed by its issuer, so a mandate issued to a fixture is signed by a real key even though the subject is decorative. The issuer side is where the trust lives, which is a useful thing for the demonstration to make visible. ## Two Worlds, And They Are Not At The Same Maturity The memo asks for both and is right to want both. They should not be described as two options. **World one: the credential is bounded.** An execution broker holds the credential, the agent asks for an effect, and the broker performs the action. The grant available to the agent is whatever the broker will do on its behalf, so **grant and mandate coincide by construction** and the excess is zero. This is the July identity being made true rather than assumed. It closes the boundary that three earlier briefs each named as their own limit, and it inverts the breach property by concentrating credentials in one place, which is why self-hosting is the mitigation rather than an upsell. **World two: the mandate is declared.** The agent holds a broad credential and is told what it is expected to do with it. Nothing prevents it doing more. | | Execution broker | Declared mandate | |---|---|---| | Grant | Bounded by the broker | Whatever the credential permits | | Excess authority | **Zero by construction** | The whole difference | | On violation | The action does not happen | It happened, and you may find out | | Cost | An interpreter per provider per capability | A document | | Available | Proposed, and a naming decision is outstanding | **This week** | | Honest description | Enforcement | **Instrumentation** | That last row is the correction the memo needs. The project lead: **"even if at the moment we have a bit of hope strategy because the agent has more capability than it's supposed to, the mandates, especially with I guess some of the more frontier models today, the mandates might be good enough."** **Declared mandates are worth building and they are not a control.** The corpus position reached repeatedly is that enforcement belongs where it cannot be bypassed, and a declaration in a prompt is bypassable by anybody who can write to the prompt. But the companion position is equally settled: instrument before you enforce, because you need not predict what breaks when you can measure it. Declared mandates are the instrumentation phase, they are cheap, they produce the data that says where enforcement is worth its cost, and describing them as anything more is the thing that would make this dishonest. Also worth flagging, since it is a standing item: the execution layer is still called a twin in its source material, twin already means the point where a graph meets reality, and the rename remains open from 19 August. This brief uses execution broker and does not settle the name. ## The Hypothesis Is Testable, And The Test Has A Ceiling The memo's hedge deserves to become an experiment rather than an opinion. The project lead: **"which is actually something that we should explore."** The experiment is cheap. Issue a mandate strictly narrower than the grant, instrument every action against it, and count. It produces four numbers nobody currently has: how often a mandate is honoured, how often it is exceeded, whether the excess was necessary to complete the task, and whether the agent said anything when it went outside. The fourth is the interesting one, because an agent that exceeds its mandate and reports doing so is a very different proposition from one that does it silently. **And the ceiling must be stated with the result.** Compliance measured on a cooperative agent tells you what a cooperative agent does. It says nothing about an injected one, because ambient authority is why injection works: the attacker does not need to acquire authority, only to persuade the confused deputy to use the authority it already holds. **A mandate honoured by a model is a usability property, not a security boundary**, and the corpus has grounded that from published analysis already. So the experiment measures whether declared mandates reduce accidental excess, which is worth knowing, and it must not be reported as evidence that they contain a hostile one. ## Mandates Have A Partial Home Already Worth knowing before inventing a format, and it connects the two briefs of today. Published agent cards already declare constraints, rate limits, spend caps and scope-of-authority boundaries, distinguishing what an agent may do autonomously from what requires human approval. That is a mandate, published in a machine-readable document, at a discoverable location, with a signature model. What it does not carry is the pair that makes a mandate accountable: **an issuer who is not the subject, and an interval.** A card is self-published, so its declaration is the agent describing itself, which under the June trust model is a self-declaration and grants nothing until a named party confirms it. That is not a defect of the format; it is the same shape as upward trust, and the confirmation is what the register exists to hold. So the design sits cleanly on things that exist: ``` AGENT CARD declares the mandate the agent claims (self-declared) | | confirmed or denied by v REGISTER ENTRY the issuer's signed mandate, with an interval (downward) | | compared against v THE GRANT what the credential actually permits | v EXCESS AUTHORITY the difference, unaccepted, escalating ``` That last arrow is the product. ## Some Mandates, Written Out The memo asks for examples. Six, deliberately varied in how decidable they are, because the variation is the finding. | Subject | Mandate | Interval | Decidable? | |---|---|---|---| | Coding agent | Commit to the development branch of one named repository | This session | **Yes.** Branch and repository are in the request | | Librarian | Read any vault in the catalogue; write only to its own | Standing | **Yes.** Capability tiers already express it | | Cartographer | Produce maps; publish none | Until revoked | **Mostly.** Publication is an operation; production is not observable | | Billing agent | Spend to fifty pounds per day against one account | Daily | **Yes.** The ledger already derives this | | Debrief agent | Process voice notes; never send outside the estate | Standing | **Partly.** Egress is decidable; the boundary of the estate is a list somebody maintains | | Review agent | Comment on findings; accept no risk | Standing | **No.** Acceptance is an act with a named acceptor, so this is a rule about who may sign, not about an operation | The pattern in the last column is the useful output. **A mandate is decidable when it constrains an operation the system already sees.** The corpus has been here before: the vault sees operations and not flows, which is why it cannot tell an injected action from a legitimate one. Mandates inherit that limit exactly, and any mandate expressed in terms of intent rather than operations is a statement of expectation that no broker can enforce, however well it is written. Which gives a rule worth carrying: **write mandates against operations, and when you cannot, say so in the mandate itself.** A mandate that admits it is unenforceable is instrumentation that knows what it is. ## Where This Meets RiskMandate The memo makes the connection and it holds, with one tension worth naming rather than smoothing. The July position was that what the product sells is a person's mandate to operate, delivered into their own vault, describing the exposure they are already carrying. Today's split says an agent's mandate is the same primitive with a different subject: an issuer, a subject, a scope, an interval, and a signature. **The tension is tense.** A human mandate is retrospective, a statement of what you are already carrying, and its honesty comes from describing reality rather than intention. An agent mandate is prospective, an authorisation to act going forward. One describes, the other permits. They can share a structure and they answer different questions, and a product that presents them as the same thing will confuse the buyer at exactly the moment it is explaining its central idea. The reconciliation available is that **excess authority is the object both of them are about.** For a person it is the exposure they carry that nobody decided to give them. For an agent it is the capability it holds that nobody authorised. Same quantity, same escalation rule, same absent acceptor. That is one primitive rather than two, and it is a stronger claim than the July identity because it survives the distinction rather than depending on erasing it. ## What This Does Not Try To Be - **Not a retraction of the July brief.** Its accounting identity stands; the inference that the objects are one does not. - **Not a claim that declared mandates are a control.** They are instrumentation, and calling them more would be dishonest. - **Not a new risk taxonomy.** Excess authority is blast radius measured from the other end, and it escalates by an existing rule. - **Not a mandate format.** Agent cards carry most of it; the missing half is an issuer signature and an interval. - **Not a decision on the execution layer's name.** That remains open from 19 August, and twin is taken. ## Honest Tensions | Tension | Note | |---------|------| | Splitting grant from mandate | It makes the gap visible and it costs the July brief its cleanest sentence, which is the one people repeated | | Excess authority as a metric | It is countable and it will produce large numbers on every existing deployment, including ours, which is a difficult first report | | Declared mandates as instrumentation | Honest, and a customer hearing that this does not stop anything may not fund the phase that produces the evidence | | The broker eliminates the gap | It also concentrates every credential in one place, inverting the breach property the rest of the architecture rests on | | Testing mandate compliance | The number is real and it is measured on a cooperative agent, which is not the population anybody is worried about | | One primitive, two tenses | The unification is elegant and a mandate that both describes what you carry and permits what you may do is two ideas sharing a word | | Prohibitions in the record | They carry intent an allow-list cannot express and they are the form that fails silently, so the record holds two kinds of statement that look alike and behave differently | ## Open Questions | Question | Notes | |----------|-------| | How is a grant enumerated at all? | Excess authority cannot be measured until the grant side is known, and most providers do not make that easy | | Who issues an agent's mandate? | The human who delegated, the project, or the broker, and they are not the same party | | What is the default interval? | Anything unbounded is a grant wearing a mandate's name | | Does a mandate survive a session? | This is the 19 August persistence question in its consequential form | | Where does a checker look for revocation? | The shipped commands have none, stated in the documentation's own words, and the register is meant to supply it | | Is excess authority reported per agent or per credential? | One credential shared by four agents has one grant and four mandates | | Who reviews a mandate when the provider adds a capability? | The grant grows on somebody else's release schedule, and a deny-list mandate widens without any event here | ## Relationship To Previous Briefs | Date | Document | Relationship | |---|---|---| | 17 Jul | `v0.33.49__strategy-brief__sg-send-what-we-sell-is-the-risk-mandate-mandate-to-operate-personal-vaults-not-dashboards.md` | The brief whose key claim that to grant is to mandate this corrects, and whose accounting identity it keeps | | 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` | The test that a risk carries a named acceptor and an interval, which excess authority fails by construction | | 2 Aug | `v0.33.55__arch-brief__sg-send-end-to-end-worked-example-article-26-5-creditworthiness-agent-fact-to-board.md` | The unaccepted risk escalating without an escalator, which is the mechanism this feeds | | 6 Aug | `v0.33.56__arch-brief__sg-send-plugins-are-capability-grants-ambient-authority-is-the-injection-root-cause-instrument-before-enforcing.md` | Grant in its established sense, ambient authority as the ceiling on declared mandates, and instrument before you enforce | | 27 Jul | `v0.33.52__arch-brief__sg-send-agentic-outbound-maturity-model-aomm-reach-motive-freedom-silence-could-has-will-liability.md` | Reach and freedom as the earlier vocabulary for the same volume | | 19 Aug | `v0.33.60__arch-brief__service-twin-agent-never-holds-the-credential-closes-the-authorised-misuse-boundary.md` | The broker that makes grant and mandate coincide, and the naming decision still open | | 19 Aug | `v0.33.60__cross-team-brief__pki-site-review-mandate-is-the-gap-registry-is-the-missing-half.md` | The review that named the mandate gap, on the site that publishes the identity and mandate pair this brief adds a third term to | --- ## Key Claims | # | Claim | |---|-------| | 1 | A grant is the union of capabilities conferred at assignment; a mandate is what the holder is authorised and expected to do | | 2 | Grant is already the corpus's word for a capability and needs no replacement | | 3 | The 17 July claim that to grant is to mandate is corrected: its accounting identity stands and its inference that the two are one object does not | | 4 | A mandate may carry prohibitions, and a deny-list mandate widens silently whenever the provider adds a capability | | 5 | Grant minus mandate is excess authority, which is blast radius measured from the other end | | 6 | Excess authority is unaccepted by construction, so it defaults to critical and escalates unaided | | 7 | An instruction in a chat is not a mandate, because it has no issuer, interval, record or revocation path | | 8 | The five fields a mandate needs are already published on the registry site, and one with no interval is a grant under another name | | 9 | An execution broker makes grant and mandate coincide by construction; a declared mandate does not | | 10 | Declared mandates are instrumentation rather than enforcement, and the corpus instruments before enforcing | | 11 | Mandate compliance is testable and the number describes a cooperative agent, not an injected one | | 12 | Agent cards already declare scope of authority, leaving the issuer signature and the interval as the missing half | --- ## Sources - Published agent cards declaring constraints, rate limits, spend caps and scope-of-authority boundaries, distinguishing what an agent may do autonomously from what requires human approval, and the signature model attached to the card: https://aigrowthagent.co/articles/agent-cards-best-practices/ and https://github.com/a2aproject/A2A/blob/main/docs/specification.md - The four shipped capability tiers, in which an append token grants write to one lane and an enumeration key grants list and fetch, as the established sense of grant in this estate: https://sgit.ai/llms.txt - The key registry site setting identity and mandate out as two independent and independently revocable statements, with a mandate stated as what an agent may do, until what date, and on whose authority: https://pki.sgit.ai --- This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).