Authority Without Assertion: Sealed Identity and Earned Capability for Agent Execution
Abstract
The usual way a request proves it is allowed is to present a token that says so. The token is a claim, and a claim is only as good as the system that validates it, the discipline that checks it, and the secrecy that protects it.
An agent operating system cannot rest authority on claims. The “customer agent” (CA) is arbitrary customer code; the consequential action may fire weeks after the human who authorized it has gone; and a regulator (presumably also a human, at least for awhile yet) will later ask not whether a claim was presented but (1) who in fact authorized the work, (2) what in fact executed it, and (3) on what platform it ran.
WunderOS moves authority from claim to proof along two axes. The first is the decision record. When the substrate governs an action it produces a decision, and the decision now seals three roots into itself: the human who authorized the work, the agent that executed it, and the platform it ran on. The origin is recoverable by reading the record, with no later lookup, and it is stable under WunderOS replay. The second is delegation. Authority descends from the human root along an attenuated chain, and each link is a signed bounded capability rather than an assertion of rank: it names its subject, its ceiling, the constraints a request may not exceed, and the conditions that return a human to the loop, and a hop may only narrow what it received. Over both sits the interceptor, where two gates compose: one asks whether the agent is what it registered as, the other whether it has shown it can do the thing it is about to do.
Authority is sealed, attenuated, and earned. None of it is asserted.
1. The claim is the weak point
Authorization usually works by assertion. A caller presents a credential that says it may act, a checker consults a table keyed to the caller’s identity, and the table decides. Two weaknesses are built into the pattern. The first is that authority attaches to identity rather than to the act, so a component that holds a right for one purpose can be induced to spend it on another, which is the confused deputy (Hardy, The Confused Deputy, 1988). The second is that the credential is a claim, held apart from the act and from any record of what the act in fact did, so that an audit after the event cannot reconstruct who authorized the work, what executed it, or where.
Both weaknesses are sharp for agent execution. The actor is not ours; it is arbitrary customer code, as PLRN-011 had to assume of the agent it could not trust to write its own rollback. And the consequential action does not always fire while the requester is present: the compensations and triggers of PLRN-010 and PLRN-011 run on deadlines of hours to weeks, fired by a part of the system that is still running when the agent no longer is. A claim presented at request time is not present when the deferred action fires, and identity-keyed authority is exactly the ambient authority that an arbitrary agent should not be handed.
The remedy is an old one by name. A capability is an unforgeable token that designates a specific right; to hold it is to be able to exercise it, and to exercise it is to present the right rather than a claim about who one is (Dennis and Van Horn, Programming Semantics for Multiprogrammed Computations, 1966; Miller, Robust Composition, 2006). WunderOS applies the discipline in two places that an agent operating system most needs: the record a decision leaves behind, and the authority a delegation passes down.
2. The decision proves its own origin
When the substrate governs an action it emits a decision, the recorded form of the governed verdict that the interceptor of PLRN-008 returns on every tool call, memory write, and egress. The decision is itself a Pentad, the substrate’s five-slot fact (SPO, Context, Lineage). The recent work seals three roots into that record, so that the record proves where it came from rather than pointing at where the answer might be found.
The three roots
The first root is the human. The authorizing human or initiating system is carried as the root identity of the delegation under which the request runs, so the requester is part of the decision and is read off the decision, not resolved later against a directory that may since have changed.
The second root is the agent that executed: the model it used, the version of the prompt that drove it, and the seed of its inference, so that the question “what ran this” is answered by the record, and two runs that differ in model or prompt are distinguishable after the fact.
The third root is the platform: the deployment that hosted the run and the fact that the deployment passed its evaluation gate, so that “where did this run, and was that platform in a sanctioned state” is in the record, too.
The three are sealed into the decision, not filed beside it. They are recovered by reading the record, with no external owner or agent lookup, and the read is deterministic and replay-stable. The reason to seal rather than reference is the provenance-by-construction of PLRN-006: a fact should carry its derivation.
A decision that points to its requester through a lookup is dynamic but not necessarily stable, that is, a decision whose meaning can change when the lookup does; a decision that carries its requester means the same thing forever. The append-only discipline of PLRN-007 then keeps it, the decision being a fact retired only by a later fact and never edited in place, so the sealed origin is as durable as the ledger that holds it.
One boundary belongs in this section rather than deferred to the end, because an auditor needs it stated plainly. The model runs outside the substrate, and the execution identity arrives across the trusted seam that also supplies the delegation tokens. The seal therefore binds, immutably and faithfully, what that seam reported about the run; it does not turn an external inference into one the substrate can reproduce from scratch. The decision proves what executed it as reported by the seam it trusts to report it, which is a real and useful claim, and it is a narrower claim than local reproduction would be.
3. Delegation is a signed bounded capability
Authority has to travel from the human root to the agent that acts, often across more than one hop. A human authorizes a customer agent; the customer agent’s paired shadow agent of PLRN-010 and PLRN-011 acts on its behalf; the chain can run further still. BEAM supervisory trees are deep, bro! What matters is what passes down it. If what passes is rank, an attribute that says the holder is privileged, then every holder of the rank wields all of its authority and the confused deputy returns through the front door.
In WunderOS what passes instead is a delegation certificate: a signed object that designates its own limits rather than asserting a station. It names its subject, the agent the authority is granted to; a ceiling, the level a request under it may not exceed; the constraints, the scope a request must stay within; the escalation conditions, the named triggers that force a human back into the loop if they fire; and an expiry. It is signed with a classical scheme (Ed25519), and a post-quantum scheme is deferred to roadmap and named rather than quietly assumed.
The certificate’s central property is attenuation. A hop may only remove authority from the certificate it holds; it may never add. The chain narrows monotonically from the human root downward, and the authority any agent wields is bounded by the product of every narrowing above it. This is the delegation-certificate discipline of SPKI/SDSI (Ellison et al., RFC 2693, 1999) and the contextual-caveat discipline of macaroons (Birgisson et al., Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud, NDSS 2014): authority travels as an attenuable object whose holder can pass on less but never more, so that handing authority to a less trusted party is safe because the most that party can do is narrow it further.
Replay determinism is preserved at the one place it is easy to lose. Whether an escalation trigger fired is not recomputed when authority is checked. It is read as a recorded verdict, written once to the log when the condition occurred and re-read thereafter, and passed to the check as data. The constraints and the triggers live in the certificate; the question of whether a condition occurred is answered once and remembered, so the same chain re-evaluated under the deterministic clock of PLRN-002 reaches the same decision it reached the first time.
4. Integrity and competence, composed
A capability says what an agent may do. Two further questions sit in front of every privileged call, and the interceptor of PLRN-008 is where they are asked, as ordered evaluators whose verdicts combine by denial: any gate may block, and all must pass for the call to proceed.
The first gate is integrity. An agent registers with a signed manifest of the tools it will use, and the gate checks at call time that the agent is still running the manifest it registered, so that an agent cannot present one face when it registers and another at the venue where the tool fires. This is capability-based access control in the ordinary sense: the right is bound to a certificate, and the certificate is checked against what the agent actually is.
The second gate is competence, and it is the newer move. Holding the right to use a tool is not the same as having shown one can use it. The competence gate unlocks a tool for a plan only when the agent has passed a probe for that plan, a certification that it can in fact do the thing it is about to attempt, and blocks the call otherwise. The blessing is per-plan and fixed for the life of the chain, so the check at each call is constant-time; the work of earning it happens once, before the plan runs, and the venue only reads the result.
Integrity asks whether the agent is what it claims to be. Competence asks whether it can do what it is about to do. The two are independent. An agent that is what it says but has not shown competence is blocked, and an agent that has shown competence but is not what it registered as is blocked. Neither property implies the other, and authority that checked only one would be authority half-proved.
5. Earned, not granted
One discipline runs under all of this, and PLRN-013 states its cousin: trust is earned, not assigned. There, an agent’s trustworthiness as a source of facts is grounded in a measured posterior over its work rather than a scalar set by hand. Here, an agent’s authority to act is grounded in a signed chain it can present and a probe it has passed, rather than a rank it has been handed. These are the same refusal in two registers.
A system that assigns trust by fiat and grants authority by role rests its security on the correctness of its assignments and the secrecy of its tokens. A system that earns trust by measurement and proves authority by capability rests instead on what is recorded and what can be re-checked. The first is a claim about the world. The second is a fact in the ledger.
For an operating system whose actors are arbitrary and whose actions are subject to audit, only the second is worth offering, because only the second survives the question a regulator asks, which is never “what did the token say” but “who authorized this, what ran it, under what bounded authority, and how do you know.”
6. Status of this work
The work here is recent extension, landing in slices: the sealing of the three roots into the decision, the delegation certificate as a signed object carrying its constraints and escalation, and the competence gate composed above access control in the interceptor. The claims are architectural commitments about how the pieces fit, with the landed parts checked as they land, and not a measurement of a finished whole.
Three boundaries are worth stating plainly. The execution-identity seal is attestation, not reproduction, in the sense of section 2: it binds faithfully what the trusted seam reports, and it does not make an external inference locally reproducible. The signatures are classical, and the post-quantum scheme is named and deferred rather than in place. And the end-to-end guarantee of a long delegation chain depends on every intermediate signer behaving as the chain records; attenuation bounds how much authority can reach the end, but the deeper the chain, the more its integrity rests on each hop, which is the standing cost of delegation and is not removed by making delegation a capability. Delegation that crosses a tenant boundary is, as in the rest of the system, out of present scope.
7. Related notes
The capability discipline is the object-capability lineage of Dennis and Van Horn (1966) and Miller (2006), with the confused deputy (Hardy, 1988) as the failure that ambient, identity-keyed authority invites. The delegation certificate is the attenuable-credential line of SPKI/SDSI (Ellison et al., 1999) and macaroons (Birgisson et al., 2014), where authority travels as an object a holder may narrow but not widen.
Within the PLRN line, the sealing rests on the provenance-by-construction of PLRN-006 and the append-only retraction of PLRN-007, which are what let a decision carry its origin durably rather than point at it; the gates sit in the interceptor of PLRN-008; the deferred action that makes a request-time claim insufficient is the saga and standing-lease machinery of PLRN-010 and PLRN-011; and the governing principle is the earned-not-assigned discipline of PLRN-013. What this note adds is the claim that an action’s authority should be carried and proved by the action, sealed into the decision, attenuated down the delegation, and earned at the gate, rather than asserted beside it.
A note on method
Written in conversation with Claude Opus 4.8 (Anthropic) as structured interlocutor and prose editor. The research backstop was assembled in part with Paper Lantern. The motives, ideas, claims, framing, and architectural commitments are mine.
Kendall Clark · k@pentad.ai
Great Falls, Virginia
June 2026