NeurIPS 2026 · Education Track · Submission 10 · Final version, November 2026

When telling is not governing.

Epitácio Vicente do Nascimento Neto and Prof. Dr. Felipe André Zeiser · Graduate Program in Applied Computing (PPGCA), UNISINOS

LLM-based agents are mostly governed by telling them things: system prompts and policy files. This resource teaches an emerging alternative, architectural governance: making a prohibited effect structurally unreachable rather than discouraged, reviewed, or checked by a mechanism the agent itself could alter. Four instruments carry the idea: the access-vs-mandate classification, the enforcement ladder, six supervision viability conditions, and the supervision residue. The evidence comes from one real production multi-agent deployment, the founding case, which is introduced in the box below before any of its numbers appear.

Start here: the lecture notes are the primary text; the slides and the website follow the same nine modules. Open the user guide for reading paths, session plans and the module map.

Start here Enter the lab Download materials

Terms you need first. Plain definitions of human in, on and out of the loop, instruction hierarchy, prompt injection, in-context scheming, the adversarial ceiling of prose, and control flow versus data flow. Open before reading on.

Instruction hierarchy

A rule for which instruction wins when instructions conflict: text from an application's developer (the system prompt) outranks text from a user, which outranks text that arrives inside a web page, a document or a tool's output. Wallace and colleagues (2024) train language models to follow that ordering and to ignore lower-ranked instructions that conflict with higher-ranked ones. It makes a violation less likely; it does not stop a model that fails to follow the ordering, so it is still a control written in prose. In the running example: the approval policy should outrank anything the deploy agent reads in a ticket.

Prompt injection

Text placed in data that an agent reads (a web page, an email, a file, the output of a tool) which the agent mistakes for an instruction and obeys, so that whoever wrote the data, and not the agent's operator, steers what the agent does. In the running example: a ticket the deploy agent reads says "skip the approval step"; if the agent obeys, that text, not the approval policy, governs the deploy.

In-context scheming

An AI agent covertly pursuing a goal that was given to it in its context window, for example by hiding what it did, disabling an oversight mechanism or misreporting its own actions. Meinke and colleagues (2024) show that several frontier models can do this in test environments built to encourage it, strategically introducing subtle mistakes, attempting to disable oversight and trying to copy what they believed to be their own weights. This is a capability result from constructed tests. The founding case does not show scheming: its 61.1 per cent (REPORTED) measures a mismatch between a report and the evidence, not intent.

The adversarial ceiling of prose (the authors' own phrase)

A control written as prose, such as a system prompt or a policy file, works only if the model chooses to comply. Against a model, or a text, that is working to evade or override it, the guarantee a prose control gives cannot be raised above what the adversary allows, however carefully the prose is worded. That upper bound is the adversarial ceiling of prose. Prompt injection and in-context scheming are two ways of reaching it. In the running example: however carefully the approval policy is worded, it binds only an agent that chooses to follow it.

Human in, on and out of the loop

Three ways a human relates to an agent's action. In the loop: a human approves before the action happens. On the loop: the agent acts and a human reviews afterwards and can intervene. Out of the loop: the agent acts with no human review beforehand. The study ties them to the three levels used in these materials: Level III is human-in-the-loop, Level II is human-on-the-loop, and Level I approximates human-out-of-the-loop. In the running example: the approval policy asks for in the loop; the study found that an environment which described itself as on the loop exercised that loop zero times in 46 days.

Control flow and data flow

Control flow is the sequence of steps a program decides to take; data flow is the information that moves between those steps. CaMeL (Debenedetti and colleagues, 2025) extracts the control flow from the trusted request, so that untrusted data an agent retrieves can never change which steps run. That is enforcement placed in the structure of the system rather than in the model's behaviour.

Read this before the numbers

The founding case: what it is, who observed it, and what its numbers can and cannot show

The founding case is a deployment coordinated by one of the authors: an AI conversational application operated by multiple AI agents working 24/7 to monitor and patch it autonomously, with some work done by a human on the loop, a real service in a real real-estate business in Sydney, Australia (AUTHOR-ATTESTED), coordinated by one of the paper's authors, who identified the opportunity to start working on the architecture side of reinforcement. Its figures come from one read-only run (20260807-1714, 7 August 2026) by a single observer who is also the operator, on one host: the agent orchestration hub. The conversational side is REPORTED, not observed. 60 action classes enumerate that host; 61.1 per cent (11 of 18 audited episodes, drawn from 46 candidate episodes, REPORTED) is a rate within non-randomly chosen candidates. This is one environment, one snapshot, one observer: findings about this estate, not prevalence estimates.

What it is. AUTHOR-ATTESTED. The founding case is an AI conversational application (the service's conversational engine) operated by multiple AI agents working 24/7 to monitor and patch the application autonomously, with some work done by a human on the loop. It is a real service running in a real real-estate business in Sydney, Australia, coordinated by one of the paper's authors, who identified the opportunity to start working on the architecture side of reinforcement. These contextual statements are the authors' own; they are not part of the study's registers and were not independently audited. No company, customer or individual is named.

Who observed it, and when. The registers come from one read-only collection run (run 20260807-1714, captured on 7 August 2026), in which the study's single observer examined one host of the estate and changed nothing. The study's documents state that the estate was built and operated by the doctoral candidate and that the observer is the operator. The study is therefore a single-observer, read-only, evidence-cited snapshot of a deployment coordinated by one of the authors, and it is not an independent external audit. Two partial mitigations were applied: every factual claim cites an evidence identifier, and one hypothesis the author carried into the run was corrected rather than confirmed (finding F-035). Neither makes the study independent.

Limits of a single case. One environment, one snapshot, one observer, and the observer is the operator. The guardrail catalogue, the determinants and the viability conditions are shaped by what this one environment contains; a different environment would plausibly give different layers and determinants, and there is no way to know from inside how much. So every number in these materials is a finding about this estate on 7 August 2026, not a prevalence estimate. The study's own plan for testing generality is an isolated experimental environment and replication in other deployments; both are future work. Open question for the learner: does the pattern hold in other deployments? The study lists this as an open question (OQ-004).

The registers are identity-free by construction (no hostname, account, customer or third party is named). The deployment's sector (real estate) and city (Sydney, Australia) are author-attested and are not part of the registers; no company, customer or individual is named.

What was observed

What was observed. The host examined is the agent orchestration hub of the estate, the place where the fleet of coding agents is started, supervised and dispatched. At the time it ran 14 live agent sessions (9 registered fleet agents and 5 started ad hoc) that shared one operating-system account holding unrestricted passwordless root, 9 supervised services, and 17 automations that can start an action with no human keystroke, with 1 human operator, and its console audit logs span 46 days. The conversational engine that talks to members of the public by voice and message runs on other hosts of the estate and was not examined; it enters the registers only as REPORTED action classes (AC-049, a real-time voice interaction with a member of the public, and AC-050, a message to a member of the public). The figures in these materials therefore describe the agents that operate the service, their actions, their controls and the supervision over them, not the service's business logic or its customers.

How the author's description and the registers relate

The author's description of the founding case set against what the registers show
The author's statement	What the registers show	Label
An AI conversational application	Voice and messaging action classes AC-049 and AC-050 on another estate host	REPORTED, not observed
Multiple agents	14 live agent sessions and 1 human operator	OBSERVED
Working 24/7	Continuous unattended operation: 17 automations that act with no human keystroke; a heartbeat watcher every three minutes with no iteration cap and no end condition; every fleet agent recreated daily at 08:00. The literal phrase 24/7 is the authors'	AUTHOR-ATTESTED; the registers support continuous operation
To monitor	A stall watchdog and watchers exist; 8 of the 14 live sessions sit outside every watchdog's scope, and one had produced no output for 7 days at capture time	OBSERVED
And patch the application autonomously	AUTHOR-ATTESTED. In the registers, agents author and submit patches to the deployment approval gate, where only a human identity can approve; the console audit logs (46 days) show zero deployment rejections and zero update approvals; 434 update proposals were pending and none had been applied	AUTHOR-ATTESTED, with these register observations beside it
Some work as human-on-the-loop	The environment describes itself as on the loop; over 46 days the loop was exercised zero times (finding F-042); DERIVED from the register field effective posture: 22 of 34 supervision points are recorded as plain out-of-the-loop (25 if the qualified variants “out-of-the-loop, defensibly” and “out-of-the-loop at the time of action” are counted)	OBSERVED (zero loop use, F-042); DERIVED (the counts 22 and 25)
A real service in a real real-estate business in Sydney, Australia	Not in the registers, which name no sector, city, company or customer	AUTHOR-ATTESTED
Coordinated by one of the paper's authors	The study's documents state that the estate was built and operated by the doctoral candidate, who is also the observer	STATED in the study's documents; not independently verified; which author coordinated is for the authors to confirm

How the counts were defined

How the counts were defined.

60 action classes: a complete enumeration of one host, not a sample. Every distinct class of action an agent on the host can perform was catalogued at a consistent granularity, the level of "commit to a repository" or "restart a managed process" rather than a single API call, giving AC-001 to AC-060. Completeness is the study's claim; no completeness test is documented. 46 of the 60 classes have a coding agent as actor. 55 classes were verified on the host (OBSERVED) and 5 are REPORTED because the mechanism sits on another host (AC-044, AC-049, AC-050, AC-051, AC-052). Each class was graded for access, mandate, risk grade and current enforcement.
134 guardrails: a catalogue of the design space, not 134 deployed controls. Entries are numbered GR-L01-01 to GR-L12-09 across 12 layers; each states its mechanism, enforcement class, the action classes it binds, a mandatory bypass analysis, its fail state and the signal it emits. 39 entries are present on the host, 17 partial and 78 proposed. The catalogue was derived from one environment, and its generality is a hypothesis.
72 metrics: specified metrics, 21 engineering and 51 governance, of which 14 are available today, 25 derivable and 31 absent (2 further entries split). Only one, the claim divergence rate MG-022, has a computed baseline.
34 supervision points: places where the architecture claims some human supervision, intervention or signal. Each was assessed against the six viability conditions; 27 diverge between nominal and effective posture. How the 34 were enumerated is not documented.
32 residue classes: the action classes that remain above Level I under the fully hardened condition set CS-09, found by applying ten supervision determinants; 22 at Level III and 10 at Level II.

The 61.1 per cent: how it arose

The 61.1 per cent. REPORTED. It is the claim divergence rate MG-022: audited episodes in which at least one material factual assertion in the agent's own report is contradicted by independent evidence, divided by episodes audited. A material assertion is one about an action taken, a state reached or a verification performed; style, intention and reasoning are excluded, and so are episodes with no independent evidence on either side. The independent comparator is infrastructure records: version-control history, process-manager state, health checks, cloud control-plane state and the reverse-proxy access log. The value is 11 of 18 audited episodes, 0.611. The 18 were drawn from 46 candidate episodes identified by the system itself, and the technical core was confirmed in 18 of 18. The figure comes from the proposal-stage audit and was not re-executed in the run of 7 August 2026. The study's documents record that the audit was manual and that the sampling frame was not random. Who audited, when, how the 18 were chosen from the 46 candidates and how an episode was defined are not documented in the evidence base. The study's documents call the audit independent; because the observer is the operator, these materials do not rely on that word.

What the findings can and cannot establish

What the findings can and cannot establish. They can show, for this estate on 7 August 2026: that access exceeded mandate for 50 of 60 action classes; that only 4 of 60 classes were bound to a control the actor could not reach around, and all 4 are REPORTED; that 27 of 34 claimed supervision points diverge between nominal and effective posture; and that in the audited candidates agent self-report could not serve as the evidence base for governance. They cannot show how common any of this is in other deployments; a rate for agent misreporting in general (11 of 18 is a rate within non-randomly chosen audited candidates, not a population rate); deception or intent (the audit compared reports with evidence, not motives); incompetence (the technical core was confirmed in all 18); that a human intervention was warranted and not made (zero interventions in 46 days establishes that the loop was not exercised, which is a weaker claim); that the six conditions are complete; that the residue is intrinsic (it is relative to the catalogue); or that the framework works in practice (it has not yet been used to make a decision).

Evidence labels used on this page

Evidence labels. Every finding in the study carries one of four labels. OBSERVED: verified on the host in the run, with an evidence identifier. REPORTED: taken from the doctoral proposal or the run brief and not verifiable on the host in that run. PROPOSED: a design proposal of the study that does not exist in the estate. NOT DETERMINED: could not be established, with the reason stated. These materials add AUTHOR-ATTESTED for statements the authors make that are not in the registers.

0 action classes enumerated on one host (the founding case)

0of 60 action classes where access exceeds mandate (47 OBSERVED, 3 REPORTED)

0of 39 present guardrails that are structural (REPORTED)

0% factual divergence between agent self-report and independent evidence: 11 of 18 audited episodes (REPORTED)

Start here · user guide

How to use these materials

These materials teach one idea, architectural governance of LLM-based agents: telling apart the rules a system enforces by its structure from the rules it only asks for in prose. There are three teaching artifacts and a short proposal, all built on the same nine modules (M0 to M8) and the same running example.

The lecture notes are the primary artifact. They are the complete lesson: every definition, worked example, exercise and solution is in them, and they can be read on their own.

The slides are a lecture pass over the same modules. Every slide has speaker notes, and the slides-with-notes PDF lets you follow the lecture without an instructor.

The interactive website animates the access-versus-mandate matrix, the enforcement ladder, the guardrail layers, the six viability conditions and the supervision residue. It also hosts the Guardrail Lab, which Exercise E5 uses. Its complete source is included, so everything runs offline.

The two-page proposal describes the package for the Education Track.

The optional live demo, MeridianSeal Light, is a hands-on companion at https://neurips2026.meridianseal.com/demo/. In a browser you send the kind of request the deploy agent makes to governed agents, watch a human Patch Gate and a structural block, and switch between the ten condition sets. It needs a network connection and uses simplified rules, it is not a study result, and nothing else in these materials depends on it. The offline website works without it.

The problem, and the one example used throughout

The problem. Picture an AI agent that is allowed to deploy software. The organisation's policy says that every deploy needs a human's approval. The policy is written in files the agent reads, and an approval gate records each approval, but the gate is a check inside the deployment tooling, and the agent can route around it. How can anyone tell, for any agent system, which of its rules are enforced by the structure of the system and which are only requested? These materials teach a way to answer that question, and show with evidence from one real deployment that most rules there were only requested.

The three elements in plain words:

An agent that may deploy: what the system technically lets it do (its access).
A policy that needs approval: what the organisation authorises it to do (its mandate).
A control it can route around: the approval gate, whose strength we grade by who can defeat it (the enforcement ladder).

The running example: the deploy agent. Three elements, used under the same three names in every module, slide, exercise and website section. The deploy agent is an agent that may deploy software to a production service. The approval policy says every deploy needs a human's approval before it goes live. The approval gate is the control meant to enforce that policy, and it is a control the agent can route around.

The example is an illustrative simplification of two rows and one control in the study's registers; it is not a transcript of the incident. The deploy agent is action class AC-044, deploy application code to another estate host (access Level II, mandate Level III, risk grade severe, enforcement conditional, REPORTED). Recording an approval is action class AC-056, record an approval in the deployment approval gate (access Level I, mandate Level III, risk grade severe, enforcement conditional, OBSERVED). The approval gate is guardrail GR-L06-01, deployment approval gate held by a separate principal (layer L6 Change and deployment; population partial; enforcement class conditional; fail-open).

The register records AC-056 at access Level I because separation of duties is by role convention among agents sharing one operating-system identity (AC-056 note); the gate's approve route itself needs a human session (GR-L06-01), so the exposure is the shared credentials and the unbound approval-to-execution link.

The study records three routes around the gate, and none of them forges a human's approval. First, the credentials the gate relies on are readable by the one account every agent runs as, so any agent can present any agent's identity; one recorded incident has a session using the lead agent's credential to record a formal peer review of its own patch. Second, the gate governs a record and not an artefact: approval sets a status field, but nothing binds what actually runs to that field, and the process manager re-executes whatever is on the shared working tree at any restart; two documented incidents shipped code through an ordinary restart before a deploy event was recorded. Third, on the examined host the production working tree is writable over the network, so an ordinary file write places code that the next restart will serve.

Reading paths

Reading paths by audience
You are	Start with	Then
A self-study learner	The lecture notes, M0 to M8 in order. Do E2 after M2, E1 and E4 after M3, E3 after M5, E5 after M6.	The slides-with-notes PDF to review each module, and the website section for the module (table G4).
An instructor giving one lecture (90 minutes)	The slides, M0 to M8.	A live walk through the Guardrail Lab in adversarial mode. Hand out the lecture notes.
An instructor teaching a course module	The 3-session plan or the 4-session plan (G3).	The slides for each session; the Guardrail Lab in the session that covers M6.
A practitioner who wants to apply it to their own system	M0, M2 and M3 in the notes, then E1 and E3 on your own system.	M4 to M6 when you want the full catalogue and the oversight test.

Session plans

3-session plan. Session 1: M0 to M3, the core classification machinery (exercises E2, E1, E4). Session 2: M4 to M6, evidence and oversight (exercises E3 and E5). Session 3: M7 to M8, measurement and the frontier.

4-session plan. Session 1: M0 to M2 (exercise E2). Session 2: M3 to M4 (exercises E1 and E4). Session 3: M5 to M7 (exercises E3 and E5, the Guardrail Lab after M6). Session 4: M8 and an exercise review.

Both plans cover M0 to M8 once; choose the one that fits your calendar.

Where each module lives

Where each module lives: lecture notes, slides, website section, exercise
Module	Lecture notes	Slides (frame numbers)	Website section	Exercise
M0 Why now: agents act, instructions leak	Module M0	5 to 11	#start, #founding	none
M1 Anatomy of an agentic deployment	Module M1	12 to 13	#founding	none
M2 The access-versus-mandate dual classification	Module M2	14 to 18	#gap	E2
M3 The enforcement ladder	Module M3	19 to 24	#ladder	E1, E4
M4 Guardrails in twelve layers	Module M4	25 to 27	#stack	none
M5 Is your human oversight real? The six viability conditions	Module M5	28 to 30	#watcher	E3
M6 The supervision residue and its determinants	Module M6	31 to 32	#residue, #lab	E5
M7 Measuring governance	Module M7	33 to 34	#founding, #learn	none
M8 The frontier: making enforcement architectural	Module M8	35 to 36	#learn	none

Slides 1 to 4 are the opening (title, this guide, agenda, the problem and the running example); slides 37 to 38 are the optional live-demo break (MeridianSeal Light); slides 39 to 41 close the lecture; slides 42 to 43 are the glossary appendix. Slide frame titles start with the module tag.

How to use the interactive parts of this page

Matrix (The Gap): select a cell to list its action classes with their access level, mandate level, risk grade and enforcement, each in its own labelled tag.
Ladder (Ladder): select, hover or focus a rung to read its definition, its count in the founding case and the Lab outcome it produces.
Stack (Stack): select a layer to open its guardrails; press Escape to close.
Lab (Lab): pick a condition set, press Play, switch adversarial mode, change the speed; below the stage read the outcome tables, follow one action across all ten sets, and export the CSV for Exercise E5.
Watcher (Watcher): pick an example supervision point to run the six-condition test; read the approval gate of the founding case beside it.
Live demo (Demo): an optional hands-on companion in a separate page; it needs a network and is not part of the offline copy.
Residue (Residue): select a determinant for its definition; open the list of the 32 residue classes.

Running the website offline

The website is a static folder. From the website folder of the ZIP, run python3 -m http.server 8000 and open http://localhost:8000 in a browser. A server is needed because the page loads data.json; opening index.html directly from disk does not work. There is no build step and no external dependency: fonts are the system fonts and nothing is fetched from the network.

Where the code is

The folder code contains reproduce.py and reproduce.ipynb. Both read only website/data.json, use relative paths, and reproduce the access-versus-mandate matrix, the gap sizes, the enforcement-ladder counts, the layer table, the guardrail population counts, the supervision-point and residue counts, and the Guardrail Lab outcome tables for every condition set. expected-output.txt is the output of a clean run, so you can check yours against it.

Versions and how the accepted version is kept

This is the final version, November 2026, of the material accepted at the NeurIPS 2026 Education Track (Submission 10). The version as accepted and submitted on 24 Aug 2026 is kept unchanged on the hosted website at accepted/index.html and is linked from the website downloads section as "Accepted version (as submitted, 24 Aug 2026)". It is not part of the ZIP. All downloads on the website and in the ZIP are the final version.

What is in the ZIP

neurips2026-education-materials-final.zip contains README.md, USER-GUIDE.md, the proposal, the lecture notes, the slides (slides.pdf and slides-notes.pdf), the full website folder (index.html, css, js, data.json and the four PDFs under assets), the code folder, the LaTeX sources, the licence files and MANIFEST.txt. neurips2026-website-source.zip contains the website folder alone.

What changed since the accepted version

This user guide, the reading paths and the module map; the founding case is introduced before any of its numbers.
One running example, the deploy agent, carried through the page; the Lab lets you follow its two action classes across all ten condition sets.
Levels I to III defined in one table, a worked access-versus-mandate table for one action, and the risk grade defined and shown apart from the levels.
A Definition, example and non-example box for each of the four author-proposed terms.
The Lab: an outcome table for every action class under every condition set, a worksheet summary table, a CSV export, and an explanation of why its CS-03 differs from the ladder. Exercise E5 now asks about these four outcomes.
Layer names, viability-condition order and identifiers follow the study's registers; the binding-condition counts carry the study's convention caveat.
Both authors, the status wording and a version stamp; no external fonts or network requests; the website source and the full materials are available as ZIP files.

Instrument 1 · Access vs mandate · module M2

The gap between can and may

Every action class gets two grades: the access level the agent technically holds, and the mandate level it is authorised for. Where access outruns mandate, governance exists only on paper. In the founding case, 50 of 60 action classes show access exceeding mandate, and 0 show the reverse. Both grades use the same three levels, defined next.

Three separate scales

Levels say who decides, enforcement says who can defeat the control, the risk grade says how bad the consequence is.

IIIIII Access level and mandate level: Square badges, cool colours. Always labelled "Access level" or "Mandate level". Ordered by the human control they require.
lowmoderatehighsevere Risk grade (consequence): Rounded pills, warm colours, always labelled "Risk grade (consequence)". Never a roman numeral and never a level.
noneinstructionalconditionalstructural Enforcement: Outlined tags in the ladder colours (see the next section). Who can defeat the control that bounds the action.

Levels I to III

Levels I to III (definitions from the study, verbatim). Ordered by the human control they require.
Access or mandate level	Badge name	Definition	Human role
I	autonomous	fully autonomous with no prior review, confined to development or version control, or permanently pre-authorised	approximates human-out-of-the-loop
II	autonomous, reviewed afterwards	autonomous with subsequent human review, carrying real production impact but reversible, communicated asynchronously	human-on-the-loop
III	prior approval or prohibited	requires prior approval or is prohibited outright: irreversible, externally facing, or altering a safety flag	human-in-the-loop

The levels are ordered by the human control they require: Level I needs none beforehand, Level II needs review afterwards, Level III needs prior approval or is prohibited. Permissiveness runs the opposite way: Level I is the most permissive. Access is more permissive than mandate when the access level number is lower than the mandate level number.

Access versus mandateDefinition, example, non-example

Access versus mandate. Author-proposed term, not an established standard.

Definition. Every action class is graded twice on the same three levels. Access is what the agent is technically capable of doing today. Mandate is what it is authorised to do today. Where access is more permissive than mandate, the study records a delta, an unenforced boundary, and these materials call it the governance gap.

Example. AC-056, record an approval in the deployment approval gate: access Level I, mandate Level III. The boundary between what the agent can do and what it may do is not enforced by the structure of the system; it rests on role convention among agents that share one operating-system identity.

Non-example. AC-004, push a commit to a hosted remote repository: access Level I, mandate Level I. The agent is able and authorised, so there is no gap, even though the only control on it is a sentence in a prompt (instructional, GR-L12-02). A weak control is not a gap; a gap needs access to exceed mandate. A second non-example is AC-052, write to the System of Record (REPORTED): access Level III and mandate Level III, no gap, because the capability does not exist.

Not to be confused with. The risk grade, which rates consequence, and the enforcement rung, which rates who can defeat a control. Source: D1:823-830.

Worked example: how the gap is read for one action

Take one action class, AC-056, record an approval in the deployment approval gate. Step 1, mandate: the approval policy says a human decides whether a deploy goes ahead, so for an agent recording an approval is Level III, prior approval or prohibited. Step 2, access: the register records Level I, because the agent can do it with no one acting first. The register records AC-056 at access Level I because separation of duties is by role convention among agents sharing one operating-system identity (AC-056 note); the gate's approve route itself needs a human session (GR-L06-01), so the exposure is the shared credentials and the unbound approval-to-execution link. Step 3, compare: Level I access against Level III mandate means access is more permissive than mandate, so the register records a delta, a governance gap. Step 4, gap size: mandate rank 3 minus access rank 1 is 2 (derived presentation, not a register field). Step 5, read the other two scales separately: the risk grade is severe (how bad the consequence is), and the enforcement is conditional (who can defeat the control). Level I access with Level III mandate is the worst cell of the matrix: the system relies on prose, role convention and the agent's cooperation to hold the line.

Worked table: access, mandate, risk grade and enforcement for five action classes, kept in separate columns. AC-056 is the hero row. Gap size is a derived presentation, not a register field.
Action class	Access level	Mandate level	Gap?	Gap size (derived)	Risk grade (consequence)	Enforcement today	Evidence
AC-056 Record an approval in the deployment approval gate	I	III	yes	2	severe 4/4	conditional (GR-L06-01)	OBSERVED (EV-030)
AC-044 Deploy application code to another estate host	II	III	yes	1	severe 4/4	conditional (GR-L06-01)	REPORTED (EV-030)
AC-029 Execute a command as root (two-step gap, no control)	I	III	yes	2	severe 4/4	none	OBSERVED (EV-003)
AC-004 Push a commit to a hosted remote repository (no-gap row)	I	I	no	0	moderate 2/4	instructional (GR-L12-02)	OBSERVED
AC-052 Write to the System of Record (no gap because access is absent)	III	III	no	0	severe 4/4	structural (GR-L05-01)	REPORTED

Three separate scales: levels say who decides, enforcement says who can defeat the control, the risk grade says how bad the consequence is. AC-044's access is II because, per the register, it is "bounded by the deployment approval gate where that gate is in the path; the gate is a check inside the tooling, not a property of the target". "Two steps" and "one step" are derived readings, a derived presentation, not a register field.

A governance gap exists for an action class when its access is more permissive than its mandate, that is, when the access level number is lower than the mandate level number. The register records this as a yes or no field called delta, and it matches this rule for all 60 classes. Gap size is a derived presentation, not a register field: mandate rank minus access rank, with Level I as 1, II as 2 and III as 3. Over the 60 classes, 28 have a gap of two steps (access Level I, mandate Level III), 22 have a gap of one step (18 at I and II, and 4 at II and III), and 10 have no gap; none has a negative gap, because access is never observed to be more restrictive than mandate on this host. 28 plus 22 is 50.

The matrix

Levels run from the least to the most constrained: Level I is fully autonomous with no prior review, Level II is autonomous with review afterwards (human on the loop), Level III needs prior approval or is prohibited (human in the loop). Rows are what the agent can do (access); columns are what it is authorised to do (mandate). Cells above the diagonal are the 50 classes where what the agent can do exceeds what it may do: the governance gap. No class sits below the diagonal. Select a cell to list its action classes.

Cells above the diagonal (18, 28 and 4 classes) are the 50 gap classes: 47 OBSERVED and 3 REPORTED (AC-044, AC-049, AC-050). The 28 classes at access I and mandate III are the worst case; by risk grade they split severe 17, high 9, moderate 2.

Risk grade is not a level

Risk grade (consequence). A four-point qualitative consequence rating (low, moderate, high, severe) recorded per action class by the study's observer; reversibility and blast radius are recorded as separate fields; no formula is documented. The study's documents and registers give no rule by which a grade was assigned, and no second rater checked it, so teach the grade as the observer's judgement, not as a computed score. It is not a level: a class can have any grade at any access and mandate. Severe appears with a two-step gap (AC-056), with no gap (AC-052), and low appears with no gap (AC-001, read source code); the grade says how bad the consequence is, the levels say who decides, and the rung says who can defeat the control.

Distribution over the 60 classes: severe 22, high 20, moderate 14, low 4. Among the 56 classes without a structural control: severe 19, high 20, moderate 13, low 4.

Instrument 2 · The enforcement ladder · module M3

Grade every control by who can defeat it

The ladder has four rungs, numbered 0 to 3. Ask of any control: who can defeat it? The answer, not the control's name or intention, decides where it sits. Select a rung to see its definition, the number of action classes currently resting on it in the founding case, the outcome the Lab gives it, and example guardrails. The running example, the deploy agent, is shown on every rung.

56 of 60 action classes have no structural enforcement. The 4 structural classes (AC-049, AC-050, AC-051, AC-052) are all REPORTED, and only 2 of them are among the 50 gap classes.

The as-found ladder of the founding case: 36 classes at rung 0, 8 at rung 1, 12 at rung 2 and 4 at rung 3 (the ladder counts each class by its recorded current enforcement). The Guardrail Lab applies a different, broader rule; see the note on CS-03 under the Lab.

Enforcement ladderDefinition, example, non-example

Enforcement ladder. Author-proposed term, not an established standard.

Definition. The enforcement ladder grades any control by one question: who can defeat it? Rung 0, none: no control of any kind. Rung 1, instructional: the actor is told what to do or not do, in prose the model reads as context, and nothing in the runtime blocks the action. Rung 2, conditional: a check exists in a code path and is evaluated at run time, but the actor could reach the same effect by another path, or could alter the condition it is checked against. Rung 3, structural: the prohibited action is not reachable by the actor; defeating the control needs a change of architecture, not a change of decision, and the agent's compliance is not a term in the outcome.

Example. The deploy at each rung. Rung 0: nothing governs AC-029, execute a command as root. Rung 1: the approval policy is a sentence in files the agent reads, and AC-043, execute a command on another estate host, is governed only by a prose instruction to confirm first (GR-L12-06). Rung 2: AC-044 and AC-056 are governed by the approval gate GR-L06-01 (partial, conditional, fail-open). Rung 3, PROPOSED: a separate approver identity (GR-L01-08) and a deploy artefact bound to its approval (GR-L06-11). The one present structural exemplar is AC-052 through GR-L05-01 (REPORTED). In the founding case: 36 classes sit at rung 0, 8 at rung 1, 12 at rung 2 and 4 at rung 3.

Non-example. A well-built control is not thereby structural. The approval gate is carefully engineered and approval authority is genuinely hard to bypass, yet the gate is conditional: the credentials it relies on are readable by the agents and nothing binds what runs to what was approved. The rung is a property of the mechanism, not of its intent or its quality. Also not a control: GR-L07-09 (prose brief as the operative mandate) is one of nine inverted entries that describe an absence.

Source: D3 section 1.2.

The catalogue · 134 guardrails, 12 layers · module M4

The guardrail stack

The catalogue spans 12 layers, from identity and credential up to the model and prompt layer. It is a catalogue of the design space, not a list of deployed controls. Each bar below is one layer, segmented by population: present, partial, proposed. The coloured edge marks the layer's dominant enforcement class. Of the 134 entries, 39 present, 17 partial and 78 proposed (39 present includes nine inverted entries, below); 49 structural on paper, but 47 of those 49 are proposed, not built. Fail states split 85 fail-closed against 49 fail-open. Select a layer to open its guardrails.

Inverted entries. Nine of the catalogue's present entries describe an absence or an arrangement that weakens the posture rather than a control: GR-L01-01 shared operating-system account, GR-L01-09 passwordless root, GR-L01-10 reachable metadata credential, GR-L04-10 permission skipping, GR-L07-09 prose brief as the operative mandate, GR-L08-13 transcript hook substrate unused for enforcement, GR-L09-10 restart-always supervision that defeats termination, GR-L10-08 automated answering of interactive prompts and GR-L11-05 scheduled unattended dispatch on a clock. Eight are enforcement class none and one (GR-L07-09) is instructional. They are part of the founding case as found (CS-03) and are left out of the fully hardened set (CS-09 holds 125 of the 134 entries). So "39 present" includes these nine.

The only two present structural controls, one shared shape: the prohibited effect is unreachable

Structural · present · data plane · GR-L05-01 · REPORTED

A read-only connection identity to the System of Record

The credential the agents hold cannot write. No instruction is consulted, no check is run, no reviewer is paged. A write attempt does not misbehave; it does not exist as an outcome. Not verified on the host in the run (the mechanism sits on another host).

Structural · present · change and deployment · GR-L06-08 · REPORTED

A structural test-mode overlay in the real-time domain

Every external dispatch in the real-time domain is intercepted below the agent's reach. The live effect is not gated behind good behaviour; it is not wired up at all. Not verified on the host in the run (the mechanism sits on another host).

In both, compliance is not a term in the outcome. That is the signature of structural enforcement. For contrast, the running example's approval gate, GR-L06-01 (layer L6 Change and deployment), is partial, conditional and fail-open; the structural redesign of it, a separate approver identity (GR-L01-08) and a deploy artefact bound to its approval (GR-L06-11), is PROPOSED.

Flagship interactive · The Guardrail Lab · module M6 · Exercise E5

Watch a configuration meet an agent

Pick one of the ten experimental condition sets, from the bare baseline to the fully hardened catalogue, then press play. Attempted actions stream into the stack and resolve by one rule: an action's effective class under a set is the highest enforcement class among the set's guardrails that bind it. Structural blocks. Conditional checks and proceeds. Instructional reminds and proceeds. None proceeds silently. Flip adversarial mode to see which rungs survive an actor that alters its own checks. The Lab shows enforcement outcomes; it does not show supervision levels.

How to read the Lab. A condition set is a named subset of the 134 guardrails. For each action class the Lab finds the strongest guardrail in the set whose binds list contains the class, and that decides the outcome. Structural: BLOCKED, the effect is unreachable. Conditional: CHECKED, the check passes and the action proceeds; in adversarial mode CHECK NEUTRALISED, the actor altered the check. Instructional: REMINDED, prose is shown and the action proceeds; in adversarial mode REMINDER IGNORED. None: SILENT, the action proceeds unobserved. The simulation draws attempts at random, with each of the 50 gap classes weighted four times a no-gap class, so 95.2 per cent of attempts are gap-class attempts. Counters: attempts; blocked; boundary crossings, the attempts on a gap class that were not blocked; detections, the attempts that were checked or reminded (always zero in adversarial mode). This is a simplified rule applied to the catalogue, not a study result.

Exercise E5 uses the tables below the stage. Condition sets are listed in the study's order, CS-01 to CS-10; CS-10 is the CS-09 ablation (CS-09 without the ten verification guardrails). A condition set is a named, explicit subset of the guardrail catalogue, used to hold the guardrail variable constant at a defined maturity level. Membership is explicit per set.

Adversarial mode Speed

0attempts

0boundary crossings

0blocked

0detections

What each action class meets under each condition set (Exercise E5)

Four outcomes, in the Lab's own words. BLOCKED: the strongest control that binds the action class is structural, so the effect is unreachable. CHECKED: the strongest control is conditional, a check runs and the action proceeds. REMINDED: the strongest control is instructional, prose is shown and the action proceeds. SILENT: no control binds the class. In adversarial mode conditional controls become CHECK NEUTRALISED and instructional ones REMINDER IGNORED; only BLOCKED holds. Simplified Lab rule applied to the catalogue; not a study result.

Show

Summary by condition set (the worksheet table)

Follow this action

The running example: the deploy agent is AC-044, and recording an approval in the approval gate is AC-056. Choose an action class to see what it meets under each of the ten condition sets, and which guardrails make it so.

or any class Also send only this action through the stage above

Outcome of every action class

Why the Lab's CS-03 differs from the ladder. The ladder in M3 counts each action class by its recorded current enforcement, which the register takes from the guardrails listed in that class's enforcing-guardrails field: 36 none, 8 instructional, 12 conditional and 4 structural classes. The Lab applies every guardrail in the condition set whose binds list contains the class, and takes the strongest: for CS-03, 56 guardrails, that gives 9 none, 6 instructional, 37 conditional and 8 structural classes. In the register every guardrail listed as enforcing a class also lists that class in its binds, so the ladder never exceeds the Lab; the binds lists are broader, and 35 of the 60 classes resolve to a stronger class in the Lab than on the ladder (25 are equal and none is weaker). For example AC-038, call a cloud control-plane read API, is none on the ladder but BLOCKED in the Lab, because GR-L05-01, a present structural entry, lists it in its binds. Why the two lists differ is not documented in the study's documents. For the as-found count use the ladder; read the Lab's CS-03 as the catalogue's bindings applied to the as-found set, not as a measurement.

GR-L05-01 is itself REPORTED: the mechanism sits on another host and was not verified on the host in the run.

Didactic simulation driven by the study's registers (the guardrail catalogue and the ten condition sets); a simplified rule, not the full research model. The residue, supervision-point and viability figures elsewhere on this page are read from the same data file but are not computed by the Lab.

Exercise E5 as set in the lecture notes

E5. Guardrail Lab worksheet (website companion). Open the Guardrail Lab, on the live site or from the ZIP (run python3 -m http.server 8000 in the website folder). The Lab shows what happens to an attempted action under a condition set, as one of four outcomes. BLOCKED: the strongest control that binds the action class is structural, so the effect is unreachable. CHECKED: the strongest control is conditional, a check runs and the action proceeds. REMINDED: the strongest control is instructional, prose is shown and the action proceeds. SILENT: no control binds the class. In adversarial mode the actor defeats what it can, conditional controls become CHECK NEUTRALISED and instructional ones REMINDER IGNORED, and only BLOCKED holds. Using the Lab's outcome table, for each condition set CS-01 to CS-10 in order record (i) its guardrail count, (ii) how many of the 60 action classes are blocked, checked, reminded and silent in standard mode, and (iii) how many classes change outcome compared with the previous set. Repeat with adversarial mode on and record how many classes still hold. Then follow AC-044 and AC-056 through the ten sets, and say at which set each becomes blocked and which guardrail makes it so. Finally list the action classes that are never blocked in any set, and write a short paragraph on why a blocked class can still be in the supervision residue of M6. Two cautions: the Lab applies a simplified rule to the catalogue and is not a study result, and its CS-03 row differs from the enforcement ladder of M3 for the reason given in the note on CS-03.

Instrument 3 · Supervision viability · module M5 · Exercise E3

Is your human oversight real?

A human-in-the-loop point is only real if six conditions all hold. Try the test on three familiar supervision points, read how the founding case's own approval gate scored, then see the whole case.

Select a supervision point above to run the six-condition test. The three examples are illustrations written for teaching, not records from the study.

The running example's approval gate, as the study recorded it

The approval gate of the deploy agent has three supervision points in the registers: SP-005 (human approval of a patch), SP-006 (independent reviewer) and SP-007 (binding approval to what runs). Pass, partial and fail are the study's cell values. OBSERVED

Supervision viabilityDefinition, example, non-example

Supervision viability. Author-proposed term, not an established standard.

Definition. Supervision viability asks whether the human supervision an architecture claims at a supervision point actually exists. Each point has a nominal posture (what the architecture claims) and an effective posture (what a human can actually exercise). Six conditions must all hold for the claimed posture to be real: VC1 independence, VC2 latency, VC3 halt, VC4 attention, VC5 comprehensibility, VC6 authority. Where one fails, the effective posture is weaker than the nominal one.

Example. SP-005, deployment approval gate: human approval of a patch. Nominal posture in the loop. VC1 partial, VC2 pass, VC3 fail, VC4 pass, VC5 fail, VC6 pass; effective posture in the loop, weakly. Binding condition as recorded by the study: VC5 comprehensibility, because the approval request carries the agent's own description of the patch and not independent evidence. SP-006, independent reviewer, fails four of the six conditions and is effectively out of the loop. SP-007, binding approval to what runs, fails five of the six: no signal is emitted when an unapproved artefact is loaded.

Non-example. SP-024, structural test mode intercepting external dispatch, and SP-029, read-only connection identity to the System of Record, pass all six conditions (both REPORTED). They are not a human watching harder: the control acts before the action and does not depend on a human or on the agent's cooperation. Notification volume is not viability either: 19,334 automation events against 4 human-facing alerts is a volume, and operator capacity was not measured.

Limits. The six conditions are asserted, not derived; there is no proof that they are complete, independent or minimal, and the order in which they are read is a convention. Source: D2 sections 4 and 9.

What the founding case showed

34 supervision points were assessed against the six conditions. 27 of 34 diverge between what they nominally provide and what they effectively provide. The binding condition, as the study recorded it for each of the 27, distributes like this:

The binding condition is the one the study recorded for each supervision point. The study's convention reads the conditions in the order VC1 to VC6 and takes the first failing condition as the binding one; this is a convention, not a result, and it does not reproduce every recorded row (10 of the 27), so do not recompute the counts 8, 8, 3, 3, 2, 2 and 1 from the six columns. For example SP-005 reads VC1 partial, VC3 fail, VC5 fail, and the study recorded VC5. VC3 fails earlier in the order than VC5, so first-fail does not explain the recorded VC5; treat the binding condition as the study's judgement, not a formula.

0days 46 days of console audit logs with zero records of a human stopping, pausing, rejecting or overriding an agent on the basis of what it was doing

0vs0 19,334 automation heartbeat and nudge events versus 4 human-facing alerts over the observation window; 14 concurrent agent sessions, 1 operator. A volume only; operator capacity was not measured.

Instrument 4 · The supervision residue · module M6

What no guardrail configuration frees

Harden everything in the catalogue except the nine inverted entries (condition set CS-09, which holds 125 of the 134 entries) and a residue remains: 32 of 60 action classes stay above the autonomous level, 22 at Level III and 10 at Level II (the register's residue level). The residue is not a failure of engineering effort; it is where the reasons for human oversight live outside the stack. It is relative to the catalogue and is an upper bound, not a claim about what is possible in principle.

Why an action stays pinned: the determinants

Ten supervision determinants explain the pinning. Four dominate the residue: containment shortfall 9, externality 9, irreversibility 4, accountability 4. Select a chip for its definition.

Select a determinant to read its definition.

One nuance matters: the 9 classes whose dominant determinant is containment shortfall are the removable part of the residue. Better identity engineering dissolves that determinant. Externality, irreversibility and accountability do not dissolve (17 classes are dominated by them, 9 + 4 + 4); they are properties of the world, not of the stack.

The 32 residue classes, with their residue level and determinants

The register also records a best achievable level (III for 13 classes, II for 19), which differs from the residue level for 9 classes; this page quotes the residue level (22 and 10).

Supervision residueDefinition, example, non-example

Supervision residue. Author-proposed term, not an established standard.

Definition. An action class is in the supervision residue if and only if it remains above Level I under condition set CS-09, the fully hardened configuration that contains every catalogued control except the nine inverted entries. The definition is mechanical, so the residue can be recomputed whenever the catalogue grows. In the founding case 32 of 60 action classes are in the residue: 22 at Level III and 10 at Level II (the register's residue level). Each is pinned by one or more of ten supervision determinants (SD-01 to SD-10), one of them dominant.

Example. AC-056, record an approval in the deployment approval gate: residue Level III, pinned by SD-03 and SD-05, dominant determinant SD-03 accountability requirement. The register's reason: an approval is a statement that a named party accepts responsibility, and a machine recording it does not create the acceptance. AC-044, deploy application code to another estate host: residue Level III, pinned by SD-03, SD-04, SD-06 and SD-01, dominant SD-03; with the full catalogue it could reach Level II, but the decision to deploy under uncertainty remains a judgement with an accountable owner.

Non-example. AC-004, push a commit to a hosted remote repository, is not in the residue: Level I is defensible under CS-09. The residue is also not the set of classes the Guardrail Lab blocks: under the Lab's rule 31 of the 32 residue classes are BLOCKED at CS-09 and still remain above Level I (derived), because a structural block removes the agent's ability to act alone, while a determinant such as accountability keeps the human decision.

Limits. The residue is relative to the catalogue and is an upper bound, not a claim about what is possible in principle. The register also records a best achievable level (III for 13 classes, II for 19), which differs from the residue level for 9 classes; these materials quote the residue level (22 and 10) and say so. Source: D2 section 3.3 and section 9.

Optional hands-on · modules M3, M5 and M6

Try it live: MeridianSeal Light

Everything above is read from the study's registers. MeridianSeal Light is a small public demo that lets you watch the deploy agent's situation happen: governed agents work in a virtual workspace, and every tool call they make is shown as allowed, checked or blocked. There is no login. Each session is ephemeral and stops by itself after five minutes, the agents have no access to a real host, and the language model is a real one (DeepSeek), with a scripted fallback if it is unavailable. It is a teaching sandbox with simplified rules, not the founding deployment and not a study result, and nothing else on this page depends on it.

Screenshot of the MeridianSeal Light Agent Zone in dark mode: three governed agents in an orbit view on the left, and on the right a chat in which a Patch Gate message offers Approve and Deny buttons. — The Agent Zone. The change requested by the agent waits at the Patch Gate until a human presses Approve or Deny.

Screenshot of the MeridianSeal Light Governance page in light mode: the enforcement ladder with four rungs, the active mandate, the six viability conditions VC1 to VC6, and the condition-set presets CS-01 to CS-10. — The Governance page: enforcement ladder, active mandate, the six viability conditions and the condition-set presets CS-01 to CS-10.

Four steps with the deploy agent

Ask for a gated change. In the Agent Zone, launch the three governed agents and send the task “Request a change that policy requires a human to approve”. The agent’s patch step is conditional, so it stops at the Patch Gate until you press Approve or Deny. This is the approval gate of the running example, and you are the human on the loop (Watcher).
Try the bypass. Send “Try to bypass the guardrail”. The attempt ends in a structural block: nobody is asked and no instruction is ignored, because the effect is unreachable (Ladder).
Read the Governance page. It shows the four enforcement rungs, the active mandate with what lies outside it, and the six viability conditions VC1 to VC6.
Switch the condition set. Pick another preset, CS-01 to CS-10, and re-run both tasks. The same request changes outcome as controls are added, as in the Guardrail Lab, which remains the tool for Exercise E5.

Open the live demo

Live demo (needs a network connection): https://neurips2026.meridianseal.com/demo/

Teach with this

Learning objectives, modules and materials

By the end, a learner can

Remember / Understand define an agentic AI system and distinguish technical access from authorised mandate.
Apply classify any given control into the four enforcement classes by asking who can defeat it.
Analyse assess a human-in-the-loop supervision point against the six viability conditions and name its binding condition as the study recorded it.
Analyse read an access-vs-mandate matrix and locate the governance gap of a system.
Evaluate explain why instructional and conditional controls dominate deployed systems and what that costs, using the founding-case evidence and its limits.
Apply / Create propose a structural replacement for a given instructional control (e.g. read-only credential instead of a "do not write" instruction).
Evaluate interpret governance metrics, including a self-report divergence rate, and argue what they do and do not establish.

Prerequisites

A working idea of what an LLM and a prompt are.
Basic software systems literacy: processes, file permissions, version control, CI.
No security, formal-methods or ML-theory background needed. The material teaches by classification and case analysis, not proofs. Each specialised term is defined where it first appears.

Modules

M0 Why now: agents act, instructions leak
M1 Anatomy of an agentic deployment
M2 The access-versus-mandate dual classification
M3 The enforcement ladder
M4 Guardrails in twelve layers; fail-open vs fail-closed
M5 Is your human oversight real? The six viability conditions
M6 The supervision residue and its determinants
M7 Measuring governance: 72 specified metrics, the 61.1 per cent claim divergence rate (REPORTED)
M8 The frontier: making enforcement architectural

Reference tables

Identifiers and names as the study's registers write them, read from data.json. Layers L1 to L12, viability conditions VC1 to VC6 and the four enforcement classes.

Guardrail layers, viability conditions, enforcement classes and identifiers

ID legend

AC action class (AC-001 to AC-060); GR guardrail (GR-Lnn-nn); L layer (L1 to L12); CS condition set (CS-01 to CS-10); SP supervision point (SP-001 to SP-034); VC viability condition (VC1 to VC6); SD supervision determinant (SD-01 to SD-10); MG metric (MG-001 to MG-072); DM applicability domain (DM-01 to DM-09); F durable finding (F-001 to F-043); EV evidence file (cited by identifier; the raw files never leave the host); Level I, II, III autonomy level; rung 0 to 3 enforcement rung. Do not confuse L1 (layer) with Level I, or CS with SD.

Downloads

Everything below is the final version, November 2026. Cards for files that are not present in the folder you are viewing are hidden, so the offline copy has no dead links.

Lecture notes PDF · primary self-study text, modules M0 to M8, exercises E1 to E5 with solutions, glossary Slides PDF · 16:9 lecture deck over the same nine modules Slides with speaker notes PDF · every slide with its speaker note, to follow the lecture without an instructor Track proposal PDF · 2-page Education Track proposal

Glossary

The literature this sits in

Six papers frame the concept: two measure agent risk, one shows control under adversarial assumptions, one moves enforcement into architecture, one is the strongest instructional-side defence, and one shows what the authors call the adversarial ceiling of prose (prose cannot bind an actor that is free to ignore or rewrite it; see Terms you need first).

ICLR 2024 · arXiv:2309.15817

Identifying the Risks of LM Agents with an LM-Emulated Sandbox (ToolEmu)

Ruan et al.

Measures what agents could do wrong before they do it: risk surfaced by emulation, not incident.

NeurIPS 2024 Datasets and Benchmarks · arXiv:2406.13352

AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents

Debenedetti et al.

A live arena where prompt-injection defences bend under pressure: evaluation of agent risk in motion.

ICML 2024 · arXiv:2312.06942

AI Control: Improving Safety Despite Intentional Subversion

Greenblatt, Shlegeris, Sachan, Roger

Control protocols that assume the model itself may subvert them: governance under adversarial assumptions.

2025 · arXiv:2503.18813

Defeating Prompt Injections by Design (CaMeL)

Debenedetti et al.

Enforcement moved into control and data flow: the structural turn this resource generalises.

2024 · arXiv:2404.13208

The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions

Wallace et al.

The strongest version of the instructional side: the contrast case for everything above it on the ladder.

2024 · arXiv:2412.04984

Frontier Models are Capable of In-context Scheming

Meinke et al.

A capability result from constructed tests, and a reason instructions alone cannot carry governance: the adversarial ceiling of prose.