How this was made. The version number counts drafts of the text. It does not measure the inquiry behind it, which has run over days and across several AI systems, with argument between those systems and within them, directed, refused and repeatedly redirected by the author. The source material was AI-generated, and then adversarially and iteratively refined across a range of tools — systems built by different companies in different jurisdictions, set against each other and against the author. No one of them produced this text, and no one of them reviewed it alone. The plurality is deliberate rather than incidental. A single model carries a single set of priors about which sources are authoritative, and this series argues that an evidence base narrowed in exactly that way is how a contested question comes to look settled. Using one model to investigate that claim would have been the claim refuting itself. To name a single model on it would credit that model with work that was neither its own nor done in a single pass. The plurality was also necessary, and the record should say why. In drafting, the assisting model repeatedly led with United States institutional sources — a national laboratory, an industry association, a market study nineteen years old — and presented conclusions drawn from them as the state of knowledge. On one occasion European measured data contradicting those conclusions was present in the same research return and was placed below them. Framings were proposed that would have argued against this series’ own position using that evidence base, and offered as rigour. Each was refused by the author and the material rebuilt. That is the mechanism these documents describe, occurring in their own making, and it is recorded because a series arguing that evidence bases narrow without anyone deciding to narrow them cannot credibly claim its own production was exempt. The framing, the corrections and the judgements are the author’s, and so are the errors. How this site is written sets out what is declared on every piece, who checks it, and where the per-piece record lives.
What this publication does not claim, and what is outstanding against it in the register.
Nothing outstanding in the register. Every claim in this publication has its evidence recorded, and no question against it is parked. That is a statement about this publication on the date shown above, generated from the register rather than asserted, and it will change when the register does.
What this publication rests on, and how solid each part of it is. The four properties underneath is a specification, and this page describes it as one.
This publication cites outside sources, and they are listed below — each with what it supports, and with what it does not support. That second column is the one that matters: the common failure is not a fabricated source, it is a real source stretched past its finding.
framework
Supports. Central worked example, tested by “If everyone in the organisation were entirely mistaken about what the agent was doing, which of these layers would still hold?” — used to show only the innermost technical ring “inspects text” and none constrains what the system may do; also analysed for its verbs of accomplishment (embed, set, assign, build, prevent, block, ensure, detect and protect) and its rhetorical form (closed rings implying, without asserting, sufficiency).
Does not support. The document treats it as “not a caricature” and not the work of a vendor, but as “missing the only ring that survives being wrong”; it establishes neither authorship, prevalence, nor that all such diagrams share the flaw — only that this one does.
⚠️ Retrieval. No author, title, publisher or date given — referred to only as “a diagram [that] circulates widely, in several versions.”
standard
Supports. Used for several claims: has “no entry for delegation… The string appears three times in the whole glossary, inside other entries”; defines ‘principal’ without accountability — “A specific identity claimed by a user when accessing a system… equivalent to the notion of login account identifier,” and “each subject is associated with only one principal”; defines a security audit trail as sufficient “to enable the reconstruction and examination of the sequence of environments and activities…”; and states “Non-repudiation service does not prevent an entity from repudiating a communication.”
Does not support. As a glossary it states definitions, not controls; its ‘principal’ definition is used to show a gap (a system can satisfy it “completely and contain no accountable party”), not endorsed as adequate.
standard
Supports. Cited (negatively) that it “does not contain the word” delegation — further evidence the term is undefined across the standards actually used for it.
Does not support. Shows only an absence of the term; does not establish that OAuth 2.0 security practice fails to achieve delegation properties in substance.
specification
Supports. Cited that the protocol “most of the industry uses for delegation… uses it once, adjectivally” — reinforces that ‘delegation’ is essentially undefined in the standard actually used for it.
Does not support. Does not establish that OAuth 2.0 fails to implement delegation properties, only that its text does not define or substantively use the term.
standard
Supports. Quoted as “the one normative definition retrievable from a standards body”: “Delegation is the assignment of authority and responsibility to an agent… to carry out a specific activity as a delegate or representative, while the agent it acts on behalf of retains some responsibility for the outcome of the delegated work.” Used to establish that responsibility does not transfer under delegation.
Does not support. “PROV also states its own limit: it does not say who bears responsibility, or in what degree.” It is a provenance model, not an access-control standard.
paper
Supports. Quoted: “A principal is, by definition, the entity accountable for the activities of a virtual processor,” described as “the unit of accountability.” Also cited for design principle (f), least privilege: “Every program and every user of the system should operate using the least set of privileges necessary to complete the job.”
Does not support. Establishes the classical accountability-linked definition of principal and least privilege only; the document (via Miller) argues Saltzer and Schroeder’s own meaning of “privilege” is unclear and is routinely conflated with “authority.”
specification
Supports. Quoted: “An agent must have at least one owner… and an agent must support at least one notion of identity” — the one standard found that made owner and identity a condition of being an agent at all.
Does not support. A 2004-era standard no longer in active use; specification text survives only in archive, not on the live domain.
⚠️ Retrieval. ⚠️ “fipa.org today serves a gambling affiliate site; the Internet Archive’s capture timeline places the change between 21 July and 5 September 2026, and the specifications survive in the archive.”
paper
Supports. Quoted definition of ambient authority: “authority that is exercised, but not selected, by its user… the caller of a function such as open() does not choose any credentials to present with the request; the request merely succeeds or fails” — used to argue almost all current AI tool-calling is ambient authority, “not delegation” in the technical sense.
Does not support. Defines ambient authority as a general systems-security concept; applying it to AI tool-calling is this document’s inference, not a claim in the original paper about AI agents.
⚠️ Retrieval. Identified as “the 2003 paper” that actually coined ‘ambient authority’ (correcting a common misattribution to Miller’s 2006 dissertation).
paper
Supports. Cited for a negative/corrective claim (the term ‘ambient authority’ does not originate here, contrary to common attribution) and, at §8.1, as the source of the least-privilege vs least-authority distinction and the Alice/Bob “indirect access right”/“acting as his proxy” example.
Does not support. Does not itself coin ‘ambient authority’ — the document explicitly corrects this misattribution: “the term is often attributed to Mark Miller’s 2006 dissertation. It does not appear there. The document runs to 229 pages and contains the phrase zero times.”
⚠️ Retrieval. ⚠️ Citation-care correction stated in the document itself.
paper
Supports. Quoted: “The compiler serves two masters and carries some authority from each to perform its respective duties. It has no way to keep them apart,” and “When the code was written to produce the output it was correct! What happened to make it wrong?… it became wrong when we added home files license to (SYSX)FORT” — foundational demonstration that authority confusion is a structural defect independent of code correctness.
Does not support. A 1988 compiler example; establishes the general defect class, not that any specific current AI system exhibits it.
specification
Supports. Quoted: “The MCP server MUST NOT pass through the token it received from the MCP client” — shows the 1988 defect “is in the specification of the protocol most agent tooling now uses,” with attenuation (property three) named as the fix.
Does not support. A companion passage about a single omnibus scope masking “user intent per operation” is not in the 2025-06-18 revision. It appears under “Scope Minimization” in the 2025-11-25 revision.
⚠️ Retrieval. The two revisions are easy to conflate: the live documentation URL for 2025-06-18 serves the later text, so a reader checking that URL sees 2025-11-25 content under a 2025-06-18 address.
specification
Supports. Cited as describing “the same shape” of confused-deputy concern, corroborating within the same protocol family.
Does not support. Not quoted directly; described only in general terms.
standard
Supports. Cited: “verification does not imply evaluation of the truth of the claims encoded” — establishes that an auditable record (property four) proves authorship, not truth.
Does not support. Addresses credential verification generally, not specific to AI agents or delegation records.
other
Supports. Named as the actual source of a competing definition of ‘non-repudiation’ that the IETF deprecates and instructs its own authors not to use — sharpens the technical/legal non-repudiation distinction.
Does not support. Cited here mainly as a correction, not to establish new substantive content.
⚠️ Retrieval. 🔴 The deprecated definition of non-repudiation is published by CNSS Instruction 4009, not by NIST. The two are easily confused and the distinction matters to anyone quoting it.
paper
Supports. Credited with naming indirect prompt injection in 2023 — the origin of the concept that hostile instructions can be placed in retrieved material rather than typed by a user.
Does not support. Establishes naming/definition of the phenomenon, not its prevalence or severity, which are cited separately.
paper
Supports. Cited finding: “15,300 validated injection instances across 11,700 pages, roughly 70% of them in non-rendered HTML — invisible to a person looking at the page” — current prevalence evidence for indirect prompt injection.
Does not support. A prevalence measurement only; does not establish attack success rates, treated separately and as contested.
⚠️ Retrieval. ⚠️ Post-cutoff. No author names given in the document.
paper
Supports. Cited for a success-rate figure for prompt injection against a specific agent architecture.
Does not support. Immediately qualified by the 2025 critique below — success-rate benchmarks are contested, so this figure should be “taken as contested,” not established.
paper
Supports. Quoted: existing injection benchmarks suffer “flawed success metrics, implementation bugs, and most importantly, weak attacks,” and are “easily saturated” — counsels treating prevalence as established but success rates as contested.
Does not support. Critiques measurement methodology; “cuts at the measurements rather than at the threat” — does not claim prompt injection is not a real risk.
specification
Supports. Cited: “specifies a workload identifier with no notion of ownership, responsibility or accountability anywhere in it” — evidence current identity standards fall short of property one.
Does not support. Describes SPIFFE’s scope on this one point only; does not evaluate its adequacy for its designed purpose.
standard
Supports. Cited: “carries a delegation chain in its act claim but treats prior actors as informational” — example of tooling that records a chain without treating it as authority-bearing.
Does not support. Describes only the act claim’s informational status; not a claim that RFC 8693 is inadequate for its original purpose.
standard
Supports. Cited: “states its scope as the identity of users” — evidence, with SPIFFE and RFC 8693, that no standard yet requires an AI agent to hold its own identity.
Does not support. States scope only; does not evaluate the standard’s adequacy for its stated purpose.
standard
Supports. Cited as the nearest thing to an identity requirement — “requires that system services and applications be uniquely identified and authenticated before communicating” — but “is in no baseline. Not Low, Moderate, High, Privacy, or the operational-technology overlay.”
Does not support. A control existing in the catalogue does not mean organisations select it; shown as “a control that exists and was then made optional: NIST SP 800-53 IA-9 … and it is in no baseline.”
specification
Supports. Cited: one states “agent identity does not replace principal identity; it supplements it,” requiring each delegation-chain link to carry “its own cryptographic binding” — described as encoding property three (attenuation) as a protocol requirement.
Does not support. “Both are individual submissions” — not adopted standards, no stated working-group or organisational endorsement.
⚠️ Retrieval. ⚠️ Post-cutoff and “unverifiable against this author’s knowledge.”
paper
Supports. Cited for naming “recursive delegation accountability” among gaps that “no current technology or regulatory instrument resolves” — corroborates that property four remains unmet by current standards.
Does not support. Named without author, venue, or methodology; a gap-analysis claim, not primary incident evidence.
⚠️ Retrieval. ⚠️ Post-cutoff, and “unverifiable against this author’s knowledge.”
Foundational documents. These are positions this project has taken, not findings.
| Record | What it is | Status |
|---|---|---|
CON-05 |
Default deny | draft v0.1 |
None. This publication references no evidence record. That is the correct description of what it is rather than a gap: it is a specification, reasoning from the foundational documents above rather than reporting a measurement. Where it states a number, that number is marked in the text as what it is.
| Record | What it is | Status |
|---|---|---|
CON-09 |
No laundering | draft v0.1 |
CON-23 |
Records survive the cryptographic transition | draft v0.1 |
FIG-29 |
The rings, and the question that collapses them | drawn for this publication · figures/FIG-29.svg |
Generated from the corpus, not written by hand: this page cannot claim a source the corpus does not hold, and it changes when the records do.
Alongside: the publication · questions and answers