<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Building Mission-Bound Authorization on Control Plane by Karl McGuinness</title><link>https://notes.karlmcguinness.com/series/building-mission-bound-authorization/</link><description>Recent content in Building Mission-Bound Authorization on Control Plane by Karl McGuinness</description><generator>Hugo</generator><language>en-us</language><managingEditor>public@karlmcguinness.com (Karl McGuinness)</managingEditor><webMaster>public@karlmcguinness.com (Karl McGuinness)</webMaster><lastBuildDate>Sat, 06 Jun 2026 18:00:00 -0700</lastBuildDate><atom:link href="https://notes.karlmcguinness.com/series/building-mission-bound-authorization/index.xml" rel="self" type="application/rss+xml"/><item><title>The Agent Runtime and Audit</title><link>https://notes.karlmcguinness.com/notes/mission-agent-runtime-and-audit/</link><pubDate>Sat, 06 Jun 2026 18:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/mission-agent-runtime-and-audit/</guid><description>The first five layers make the Mission approvable, enforceable, governable, and delegable. This operational close makes them hold up against a real agent: a harness that treats session continuity as recoverable state and not as authority, an orchestrator that unwinds work already in flight when a Mission stops, and a transparency profile that makes the suite&amp;rsquo;s evidence independently verifiable across trust domains. It closes with a synthesis of the six operational layers and their deployment bundles, the practice-side view of the adoption path the architecture series stages.</description></item><item><title>Mission Lifecycle and Change</title><link>https://notes.karlmcguinness.com/notes/mission-lifecycle-and-change/</link><pubDate>Sat, 06 Jun 2026 16:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/mission-lifecycle-and-change/</guid><description>The issuance core gives a Mission three states and gates derivation on active. This part adds the surfaces that make state actionable over time: Status for canonical pull freshness with Signals as its experimental push complement, Expansion for governed growth, and Completion for monotonic narrowing. One rule threads through all four. Only active permits reliance, so every state a newer profile adds fails safe for a consumer that predates it.</description></item><item><title>Mission-Bound Runtime Enforcement</title><link>https://notes.karlmcguinness.com/notes/mission-bound-runtime-enforcement-profile/</link><pubDate>Sat, 06 Jun 2026 15:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/mission-bound-runtime-enforcement-profile/</guid><description>OAuth issuance bounds what authority may exist. It does not check the action at the point of use, so an active Mission becomes ambient authority within a token&amp;rsquo;s lifetime. The runtime layer closes that gap. A PEP at each consequential execution boundary obtains a permit from a PDP that evaluates the action, its parameters, the actor, and the current Mission state before any consequential effect occurs. The runtime profile fixes the invariants. The AuthZEN profile is its concrete wire binding.</description></item><item><title>Mission-Bound Authority: Instances, Actors, and Delegation</title><link>https://notes.karlmcguinness.com/notes/mission-sub-agents-and-delegation/</link><pubDate>Sat, 06 Jun 2026 14:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/mission-sub-agents-and-delegation/</guid><description>The AI agent auth best practices give an agent workload identity, credentials, and delegated user authority. This part binds Mission authority to that identity. The mission claim projects the approved task into every derived token, attested instance identifiers and actor chains keep every actor attributable, and delegated work gets explicit, narrower, separately revocable authority. A sub-agent that acts because it descends from a parent session is inheriting ambient authority, not delegated authority. Child Missions give durable sub-agents their own revocable handles with strict-subset authority and cascade revocation. Offline attenuation, the experimental roadmap for fan-out at scale, keeps the Authorization Server off the hot path with the runtime state check as the surviving kill switch.</description></item><item><title>From a Request to an Approved Mission</title><link>https://notes.karlmcguinness.com/notes/mission-approval-integrity/</link><pubDate>Sat, 06 Jun 2026 11:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/mission-approval-integrity/</guid><description>A user request is untrusted input. This post covers the integrity of the approval event, the layer before any token exists: the client-side shaper that proposes a candidate Mission Intent, the Consent Evidence that commits the structured consent disclosure the Authorization Server recorded as rendered (not the pixels or the Approver&amp;rsquo;s comprehension), and the deferred and revisable approval that lets a human reviewer narrow a proposal in place. Authority is created only when the Authorization Server validates, narrows, and approves.</description></item></channel></rss>