# The Broker Market Is Driven By Insurance, And A Broker Must Carry Its Own

**version** v0.33.77
**date** 31 August 2026
**from** Human (project lead)
**to** Strategy, the RiskMandate team, the registry site

**type** Strategy brief — memo 6 of 8 on the insurance pivot

*Produced from the sixth of eight voice memos, carried verbatim below and then read against the corpus by the site agent. Everything in the transcript is the project lead's; everything under the reading is the site agent's and is labelled as such. This memo **refines the delta taxonomy proposed in [memo 3](v0.33.74__strategy-brief__who-pays-for-the-delta-nobody-chose-and-the-rating-that-moves-overnight.md)**, by naming a case that taxonomy could not hold — a platform that offers the granularity and makes it impractical to use — and it **corrects a framing the estate had accepted**, that a broker narrows the grant. It does not narrow it; it changes its shape.*

---

## What This Is

The business case for the broker market, and the mechanism that makes its claims falsifiable: **the memo argues that access and execution brokers for agents are an emerging market whose commercial case is the reduction in insurance level they produce — use our product and your level drops by X — and that the claim must not rest on the vendor saying so, because a broker should carry its own policy underwriting its failures, which is what aligns the vendor's incentives with the assurance it sells and turns a marketing claim into a warranty; that the market exists at all because grants can only be narrowed so far, since platforms have not shipped the scoping features least privilege needs, or have shipped them so complex that using them is impractical, while the permissions that ought to be dynamic and PKI-backed are not available anywhere; that the buying conversation becomes concrete — this product carries policy X and reduces my level by Y because it prevents this specific thing; and that where the broker runs is itself a rating input, because a centralised SaaS broker means requests and data leaving the organisation for a decision and returning, which is latency and risk both, against an in-environment broker with no egress and a much smaller attack surface.** It is the third document of 31 August (cross-ref: v0.33.71–76, the v0.33.60 service-twin brief, and GM-D45's delta taxonomy). New contributions: **the broker's own policy as the falsifiability mechanism, deployment topology as a rating variable, the impractical-granularity case the taxonomy missed, and the broker's rating identified as systemic.**

## The Memo, Verbatim

*Transcribed by otter.ai; carried whole, exactly as received.*

> So on this one, I want to talk about the emerging market of companies who then provide access brokers and execution brokers for agents for agents when they do an action. And I think we already capture a number of these in some of the flows, but now we have an angle which is much more interesting, which is the practical and the business case for deploying these brokers is that they reduce the insurance level of a particular deployment. So a good example is if somebody breaks builds a broker for GitHub, right, in terms of the granularity of the access that it provides, then, in a way, that entity can provide the insurance, right, of the assurance, right, that it gives, and that's very important because what it provides is fundamentally is to say, hey, use our product, and we can now lower your insurance level by X, and not just kind of going. Oh, and because we said so, you know, they should actually have an insurance policy at their end that will underwrite any mistakes or any if they actually don't do the right thing. So the logic would be that, hey, if I, if I use a service that, for example, confirms that the only thing that you can push is this particular branch, and the only thing you can do is these particular actions on GitHub with this particular activity, with this particular brand, with this particular identity, etc. then you know that company should actually also have an insurance policy that it gives to its customers as a guarantee. And you know we have a bunch of industry who do this, right? There are industries who say use this, and we have an insurance policy that will cover you against any lawsuits, against any kind of problems you have, because we're big enough to basically absorb that stuff, and also he aligns that company with the the need to actually do a good job, right? Because if they don't, they actually are in quite big financial risk, right? So it's it's aligns in a way the incentives of that company with the actions that they do, and with the insurance risk that they have in having a customer that suddenly does commit to something else, or there's a bug, or or something happens, right? That is not covered, right? That you know that was supposed not to happen by their product, and this is kind of quite interesting because you now can have a much more interesting conversation on, hey, I'm buying this product which comes with insurance policy X, and this product is going to reduce my risk level and my insurance level by Y because it's not going to allow this thing to occur, and this is kind of a piece, a missing piece of the puzzle, because one of the problems we have here, and I think it's very important to map this out, is that one of the massive challenges that we have here is at the moment a lot of the grants that we have can only be reduced to a certain amount, right? We basically have fundamental gaps in our current platforms who don't actually allow us, you know, for a whole bunch of visits from technology to market pressure to market competition or lack of market competition, and who basically have not added the features required to reduce the scope to what we want to do, or when they do, they make it so crazy complex that it's again is impractical to have that lowest privilege execution, and you take into account that ideally the permission should be done dynamically, the grant should be done dynamically, and we should be using PKI and other authorization models and other modes to operate. So, so basically, That's not currently sort of possible. So that means that you, if you as a business, then turn around and says, "Well, I'm not comfortable with that level of exposure. I'm not comfortable with that level of Of risk that exists in in this by that grant because my mandate is much smaller than what I want to happen, then then this creates the market for those brokers and the market for these brokers should be driven by insurance, should be driven by the reduction in the insurance level that is needed to run that particular capability, that particular product, and and this is now super powerful, right? Because then you can start to connect the dots, right, in terms of of how everything works, right, and where everything runs. And look, and a good example of again how this works in practice is that if you have a product, let's say this broker, if this broker technology runs on a centralised place, which basically the data has to go to the the SaaS provider to do something about, and then come back with a decision. Not only there's probably maybe technology and latency issues, but more important, it's much more risky. So in a way, you also then have to take an insurance policy for the risks that happens because you're sending data and requests to something outside of the organisation environment versus, for example, something that can run in that organisation environment that can actually operate in that environment, which has a and which is locked down with no access to the internet, no other things, with maybe models that you can actually control if you use, etc. So basically, where the attack surface is much reduced. So then we we also start to be able to have a way to measure again that risk based on the policy, which goes back to the whole idea that we should be tracking and measuring risks through policy and through the cost of those policies, and the controls that we put in place should be measured against the reduction of the policies, which ultimately is the reduction of the risk of what's happening.

## The Reading — the site agent's, from here down

### 1 · The broker's own policy is what stops "we reduce your level" being apparent authority

> use our product, and we can now lower your insurance level by X, **and not just kind of going, oh, because we said so** ... they should actually have an insurance policy at their end that will underwrite any mistakes

**This is the estate's own central concept arriving in commercial dress.** A vendor claiming *we reduce your exposure* is asserting authority nobody granted — and it binds anyway, because the buyer acts on it. That is [apparent authority](v0.33.61__strategy-brief__grant-is-not-mandate-the-gap-is-the-exposure-nobody-accepted.md), the thing this whole corpus exists to make visible, in the vendor channel rather than the agent channel.

**The policy is what converts an assertion into a warranty**, and the memo's incentive argument is exactly right: a vendor who is wrong pays, so a vendor who is wrong has reason to be right. Indemnities of this shape do exist in the industry — most commonly for intellectual-property claims rather than security outcomes, which is precisely the gap the memo wants filled.

But it produces a rule the memo does not draw, and it is the sharper half:

> **A broker's claimed level reduction is computed by the rating method, not by the broker.**

Otherwise every vendor measures its own reduction favourably, and the number is marketing wearing arithmetic. This is [GM-D43](../packs/grant-and-mandate/change-control.html) — *a rating produced by the party that wants the answer is self-assessment* — appearing in a channel that decision did not anticipate: not the deploying team this time, but the vendor selling to them. **The same rule, a different conflicted party** (GM-D58).

And it is exactly what [GM-D56](../packs/grant-and-mandate/change-control.html) is for. *We define what a broker must be able to show* stops being an abstraction here: **the disclosure a broker owes is the derivation of the reduction it claims.**

### 2 · A broker does not narrow the grant — it changes the grant's shape

Here the estate had accepted a framing that this memo's own SaaS example disproves.

[Memo 3's reading](v0.33.74__strategy-brief__who-pays-for-the-delta-nobody-chose-and-the-rating-that-moves-overnight.md) said a broker's value is *"exactly how much structural delta it converts to elective."* That is true and incomplete. Interposing a broker **removes reach from one tree and adds a new party with reach of its own**:

| | Before the broker | After |
|---|---|---|
| The platform credential | Held by the agent; reaches every branch | **Held by the broker.** The agent's reach narrows to what the broker permits |
| The broker relationship | Does not exist | **New nodes**: the broker sees every request; it holds a credential that reaches everything the agent used to; and — if it is SaaS — requests and data cross the organisation's boundary |
| Egress | Whatever it was | **Possibly new**, and the memo names this itself |

> **The rating nets what a broker removes against what it adds, and the net is not automatically negative.**

A SaaS broker that narrows GitHub access while routing every request through a third party has moved exposure rather than removed it — and whether that is an improvement depends on the placement, not on the product. An in-environment broker with no egress is a different proposition **and a different rating**, which is precisely why the memo is right that where it runs matters.

**Deployment topology is therefore a first-class rating variable**, and it is one of the more computable ones — *does a decision leave the boundary?* is a question a twin can answer (GM-D59).

This also sharpens the service-twin brief's own warning. That brief said the broker becomes the highest-value target because it must hold usable credentials. In rating terms:

> **The broker's own rating is systemic.** It is the one placement whose mis-rating propagates to every customer whose level it reduced.

Which is [memo 4's](v0.33.75__strategy-brief__why-insurance-and-the-cautionary-tale-is-cyber-insurance-itself.md) correlated-risk problem in its most concentrated form, and the reason a broker's policy is not optional (GM-D61).

### 3 · The case the taxonomy could not hold

The memo names something [GM-D45's three classes](../packs/grant-and-mandate/change-control.html) do not cover:

> they have not added the features required to reduce the scope ... **or when they do, they make it so crazy complex that it's impractical** to have that lowest privilege execution

The taxonomy had **elective** (the operator could close it and did not), **structural** (the platform offers no finer grain), and **defect**. The memo's second case is neither: the granularity *exists*, so it is not structural; and calling it elective charges an operator full price for not adopting something that takes six months and a specialist.

**Two ways to hold this, and the second is better.**

A fourth class — call it *latent* — is tempting and multiplies the taxonomy without earning it. The cleaner fix is to give the existing class a dimension it was missing:

> **Elective delta carries a cost to close.** *Latent* is simply its high-cost region.

That matters for fairness and for action in the same move. **A rating that treats all closable delta as equally the operator's fault is nearly as unfair as one that charges for structural delta** — and it is less useful, because "you could close this in an afternoon" and "you could close this in two quarters with a specialist" are different instructions wearing the same number. [GM-D44](../packs/grant-and-mandate/change-control.html) already requires the derivation to decompose; **this adds the axis that makes the decomposition actionable** (GM-D60).

And it is where the broker's product actually lives. A broker selling into structural delta is selling capability the platform lacks. **A broker selling into latent delta is selling absorbed complexity** — the granularity existed and nobody could afford to use it. The second is the larger market and the honest description of most of this category.

### 4 · The market exists because the estate's own thesis is unbuilt

> ideally the permission should be done **dynamically**, the grant should be done dynamically, and we should be **using PKI** and other authorization models ... **That's not currently sort of possible.**

Worth recording plainly, because it closes a loop rather than opening one. **The broker market exists because dynamic, checkable, PKI-backed authorisation does not.** Brokers are the workaround for the missing primitive — and the missing primitive is the thing [this site](../index.html) argues should exist.

Two consequences, and they point in opposite directions, which is why both should be said:

- **It is a strong argument for the registry.** If the primitive existed, a whole category of intermediary would be less necessary. That is the clearest statement yet of what the register is *for*, commercially.
- **And it means the broker market is transitional by construction.** A vendor whose product is *we absorb the complexity the platform imposed* is betting the platforms stay that way. That is worth knowing on both sides of a sales conversation, and it is not a reason to avoid the market — the transition may be long.

### 5 · Measuring controls by the reduction they produce

> the controls that we put in place should be **measured against the reduction of the policies**, which ultimately is the reduction of the risk

This is [memo 2's](v0.33.73__strategy-brief__the-ecosystem-without-the-money-insurance-as-a-go-live-gate.md) control-to-premium loop restated as the measurement principle, and it is consistent — a control's value is the level movement it causes, computed the same way for everybody.

**The consistency requirement is the whole thing.** If each vendor computes its own reduction, the numbers are not comparable and the market cannot form; a buyer cannot weigh broker A's claimed two bands against broker B's claimed three if they were computed differently. **A shared method is what makes vendor claims comparable, which is what makes a market** — and that is the connective-tissue position from [memo 5](v0.33.76__strategy-brief__not-in-line-the-schemas-are-the-product-and-the-scale-is-one-to-five.md) earning its keep rather than merely being principled.

## What This Changes

| Position | Status after memo 6 |
|---|---|
| A broker converts structural delta to elective (memo 3) | **Incomplete.** It changes the grant's topology — removing reach from one tree, adding a party with reach of its own. The rating nets both, and the net may be positive |
| GM-D45's three delta classes | **Extended**: elective delta carries a **cost to close**; the platform-offers-it-but-impractically case is its high-cost region |
| GM-D43: the rater is separated from the deploying party | **Widened**: the vendor is a second conflicted party. A broker's claimed reduction is computed by the method, not by the broker |
| The broker is the highest-value target (service-twin brief) | **In rating terms: its rating is systemic**, propagating to every customer whose level it reduced |
| Where a broker runs is an implementation detail | **Wrong.** Deployment topology is a rating variable, and a computable one |

## Decisions This Implies (proposed into change control)

| # | Decision | Status |
|---|---|---|
| GM-D58 | **A broker's claimed level reduction is computed by the rating method, never by the broker.** GM-D43's separation, applied to the vendor channel; and the disclosure GM-D56 requires is the derivation of the claimed reduction | Proposed |
| GM-D59 | **A broker changes the grant's topology, not only its width.** The rating nets what it removes against what it adds — including the broker's own reach and, for a SaaS broker, decisions crossing the organisation's boundary. **Deployment topology is a rating variable** | Proposed — corrects memo 3's framing |
| GM-D60 | **Elective delta carries a cost to close**, and *latent* delta — offered by the platform but impractical to adopt — is its high-cost region. A rating that treats all closable delta as equally the operator's fault is nearly as unfair as charging for structural | Proposed — extends GM-D45 rather than adding a fourth class |
| GM-D61 | **A broker's own rating is systemic**: the one placement whose mis-rating propagates to every customer whose level it reduced. Which is why its policy is not optional | Proposed |

## Open Questions, The Project Lead's

1. **How is cost-to-close estimated, and by whom?** §3 needs it and it is not measurable from a twin — it is a judgement about effort, which is exactly the kind of input the two-channel rule says must be marked as declared.
2. **Does a broker's own rating publish?** §2 says it is systemic. A market in which brokers reduce levels but their own levels are private has an obvious asymmetry, and fixing it is a policy choice.
3. **Do we rate a SaaS broker's boundary crossing as one node or many?** *Decisions leave the environment* is one fact; what the broker can then see, retain and be compelled to disclose is several.
4. **Still open from memo 5:** the first MVP is unblocked and unbuilt. Memo 6 adds a natural second view to it — *what would a broker buy you here* — which is the same counterfactual machinery pointed at a product rather than a control.

---

*CC BY 4.0. Sources: the project lead's voice memo of 31 August 2026, sixth of eight (verbatim above); v0.33.71–76; the v0.33.60 service-twin brief; GM-D43 to GM-D57 in Grant & Mandate change control. Everything below the transcript is the site agent's reading and says so, including the correction to memo 3's framing in §2.*