# The Enforcement Ladder: Six Levels, A Measured Assurance, And A Catch Above The Hook Is An Incident

**version** v0.33.85
**date** 3 September 2026
**from** Human (project lead)
**to** Strategy, the RiskMandate team, the registry site

**type** Strategy brief — memo 13, recorded before the project lead had read the insurance ecosystem pack

*Produced from a voice memo of 3 September 2026, 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. The memo was recorded without having read the pack it turns out to describe, so the reading's first job is to say where each idea already sits and where it does not.*

---

## What This Is

A ladder. **The memo takes one policy — the number and size of files committed — and walks up every place it could be enforced: nothing; a line in a prompt; a skill or a system prompt; a git hook in the agent's own clone; a check at the destination, on the pull request or the receiving side; and out-of-band verification after the fact. Each rung has a level of assurance, and the memo's sharpest claim is that the assurance is measured rather than asserted: watch what each layer catches on normal usage and you learn whether the system can take abuse, from an over-enthusiastic agent or a compromised one. The first four rungs are client side, which the memo calls limited and a great signal in the same breath, because a breach seen on the server side means something is seriously wrong — a different policy, a different buffer, and possibly the loss of the licence to operate. Then the practical half: start small, with a published skill, a script and examples; look for a standard to reuse; find a name; and tie it back to the grant and the mandate with a default-deny list of everything a GitHub agent can do that nobody wants.** New contributions: **the six-level ladder as a maturity model, assurance as a measured quantity per level, a higher-level catch as an incident class, and level five as the control the pack did not have.**

## The Memo, Verbatim

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

> **Dinis Cruz 0:01** Okay, so I want to continue on the theme of these policies that, which are agent policies, which define the the operation model, and and the thing about this is, we also need to make this as simple as possible. So, although in the more advanced concept we have the risk acceptance, which is connected to the insurer, which is connected. Sorry, which is connected to the yeah insurance policies, which is connected to the actual policies and the claims and all that stuff, and it's connected to the controls and the actions. We can actually also implement this, have a solution where you don't have a lot of this, because the point here is, and also connecting with graphs and stuff like that, because the point here is to have something that you can start very small, right? And and the the one I want to talk about now is the levels of enforcement that we have for a particular policy, and and again, policies are graphs; they're easy to understand. There's something that happens. We just are connecting the dots, right? So, the the concept I want to talk about here is, for example, let's take take the example of number of files committed and number and size of files, right? So, if what I want to capture here is that we have multiple places where that can be enforced, that can be enforced via the agent, right? So that can be enforced by, in a way, by a skill that is given to an agent. In that skill, that can be enforced as a pure, you know, text guidance. Do this before committing, but that could also be enforced by writing a bit of code that, for example, is a Git hook, right? That gets installed, that prevents the the commit from going through, right? And that's if you think about the first, you have. In fact, this is also where we can also create a maturity model here, where you could say that in the first one there is nothing, right? Then there is sort of a prompt level. So in the in the user prompt, you say, "Hey, don't do this. You have it at skill level, which is a bit stronger. I think skill slash system prompt would probably have equivalent weights, and then you have at agent code level, which is you know Git basically pre-commit hooks or pre-action scripts, right? Like Git hooks, and then you have destination hooks, and this will be scripts that can no tests that can run, for example, on the pull request if you do a pull request, or on commit on the other side, and I guess you could even also have post action Verifications where out of bound you can check for that, and what's interesting about this, right, is that, and what's nice about some of these workflows is that the the level you can apply a level of detection on here that is very important. So, what I mean by this is that every one of these layers, in principle, has a level of assurance, right? And what's interesting is, over time, we can measure, even on normal usage, what happens, right? And that gives us confidence whether the the the system is working and is able to accept or handle abuse, abuse by an overenthusiastic agent or abuse by an advanced an attacker or an agent who's been compromised, and and each of these should be connected to a different policy, and each of these should be connected to a different incident response and detection model, right? So, for example, I think the first four I was saying, they are all client side, right? So, client side security is always limited, but it's also a great signal because if we ever detect any of these breaches of our policy on the server side, then we know that something is seriously wrong, and especially in some of our operations, that could be a direct case of you lose the licence to operate, because we need to understand what happened, right? Or the insurance policy is different, and the buffer that you have is different at that level, and and that's the key element here, right? So the key element here is to implement this. And what I like about this is that we can now create a series of prompt skills, controls, examples that help to start this, which basically means that you can start using our solution with a simple skill, which we can publish, and with a simple what's it called scripts and and examples, and we usually do some research to see if there's already a standard that we can copy or we can reuse or something that we can can create around this. And we need to figure out a name. Could be agent policies. Could be it might be agent insurance policies. Let's just figure out a nice name that we can use. Origenic graph policies or something that we can use that connect the dots here, but I think with this we can actually make it much easier, and we can have to start and to visualise this because what we're basically saying here is that you can start this with a simple skill, which is kind of what you want. You want a simple skill done that somehow you can just use, and then it's about finding examples, and and then defining. If you want to tie this all up, defining what is the grant and what is the mandate. So, for example, we could create a policy that lists everything that, for example, an agent with access to GitHub can do that we don't want to do, so we can actually have almost like a default deny list, which, which again, it's it's the the whole thing of you know these are limitations of the platform, but we can start to start to go around and make them visible by our policies, and hopefully the policies determine what can be done, and give us a benchmark to protect.

One transcription artefact, flagged rather than repaired: *"Origenic graph policies"* is almost certainly **agentic graph policies**.

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

### 1 · The ladder is the tier test, made finer

The corpus scores a control by one question: is it enforced by something the grant does not include? That gives three tiers — expectation, setting, boundary. The memo's six levels sit on them exactly:

| Level | The memo | Enforced by | Tier |
|---|---|---|---|
| 0 | nothing | nobody | — |
| 1 | a line in the prompt | nobody | expectation |
| 2 | a skill, a system prompt | nobody | expectation |
| 3 | a git hook, a pre-action script | the tool, inside the grant | **setting** |
| 4 | a destination hook: CI on the pull request, a host rule | a party the agent cannot reach | **boundary** |
| 5 | post-action verification, out of band | a replay of what actually happened | **detection** |

The memo's instinct that a skill is stronger than a prompt is right, and not because either enforces anything. It is stronger because agents comply with it more reliably, and that reliability is exactly the quantity the next section says to measure. Level five is new to the ladder: it does not prevent, it finds out.

### 2 · Assurance is measured, not asserted

*"Every one of these layers, in principle, has a level of assurance… over time, we can measure, even on normal usage, what happens."* The pack's ledger already stamps every verdict with the point that produced it; with a level on each event, the catch rate per level on ordinary work is a derivation, not a claim. That is the number that says whether a prompt is worth anything, and it is the number nobody has.

### 3 · A catch above the hook is an incident

The memo's central sentence: *"if we ever detect any of these breaches of our policy on the server side, then we know that something is seriously wrong."* The pack treated a setting as a weaker boundary. The memo makes it a detector: a refusal at level four of something level three should have refused means the hook was bypassed, uninstalled or broken. That is not a volume event and it does not draw on the pool. It is a different policy, no buffer, and a candidate for suspension of the licence to operate — the third response in the architecture brief's repricing table.

### 4 · Level five was the cheapest strong control the pack lacked

A hook is bypassed with one flag. The pack's maintainer run recomputed balances from the ledger and never looked at git. The replay the push checker already had — every commit re-weighed against its parent — is level five: for each commit, is the claim the hook should have written in the ledger, and does the commit's weight agree with it? A commit that carries no claim is the detection. Built as `tools/reconcile.py`, run the same day over the eleven commits since the hook was installed: no catch. The site's own release the same morning showed levels three and four in one afternoon — the hook refused the oversized commits; the destination's validator caught a broken link the client side could not see.

### 5 · Start small, and the kit already exists

*"You can start using our solution with a simple skill, which we can publish, and with a simple scripts and examples."* The push-policy skill and the pack's two hooks are that kit. What the memo adds is the adoption path beside the pack's vault-building order: prompt, then skill, then hook, then a destination check, then reconciliation — each a step somebody can take without the step above it. On standards: SLSA is the published model of numbered assurance levels; the pre-commit framework is how a hook is conventionally shipped; GitHub rulesets and required checks are the destination hook; Cedar is already adopted for evaluation.

### 6 · The default-deny list exists, from the other side

*"A policy that lists everything an agent with access to GitHub can do that we don't want."* The sibling pack stores the mandate's allow-list and renders the prohibitions from its complement; the signed mandate's rendered prohibitions are that list, and the measured grant per platform is *the limitations of the platform made visible*. Nothing new to build; a worked example to publish.

### 7 · Naming

*Agent policies* collides with IAM and OPA; *agent insurance policies* borrows the regulated word the doctrine warns against, since stage one transfers no risk. The object is already a policy on this site. What needed a name was the ladder, and *levels of enforcement* says what it is. The product name is the project lead's.

## Decisions This Implies (proposed into change control)

| # | Decision |
|---|---|
| GM-D104 | The levels of enforcement are the tier test refined: three expectations, a setting, a boundary, and detection as a fourth tier the test had not named |
| GM-D105 | Assurance per level is a measured quantity, derived from the ledger's catch rate on ordinary work, never asserted |
| GM-D106 | A catch at a level above the one that should have refused is an incident, not a volume event: no draw, a different policy, escalation, and a candidate for suspension of the licence to operate |
| GM-D107 | Out-of-band reconciliation of the ledger against the system of record is the control that turns a setting into a detector, and it is the maintainer's job |
| GM-D108 | The object stays *policy*; the ladder is *levels of enforcement*; a product name is the project lead's decision |

## Open Questions, The Project Lead's

| Question | Notes |
|---|---|
| What is the consequence at level four, today? | The destination check runs in report mode; making it a required check that refuses is the issuer's call |
| What is the rating period for assurance? | A catch rate over a week says little with one policyholder |
| Which standard to align the levels with? | SLSA's shape is closest; its vocabulary is supply-chain, not agents |
| The name | Open |

---

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