# Control Plane by Karl McGuinness

> Thoughts on identity and security as a foundational control plane for modern software systems. Drawing on decades of experience building internet-scale identity platforms, the blog explores how authentication, authorization, access management, policy, and trust move upstream into shared infrastructure that governs who can act, what they can do, and how execution unfolds across systems.

Essays and protocol profiles about identity, authorization, delegation, agent governance, OAuth, AAuth, MCP, and related standards.

Each link below points to the canonical Markdown representation of an article. The corresponding human-readable page uses the same URL without the `.md` suffix.

## Notes
- [Mission-Bound Authorization: The Glossary](https://notes.karlmcguinness.com/notes/mission-bound-authorization-glossary.md): Appendix F of the Mission-Bound Authorization handbook: every term in one alphabetical table, from the act chain to verifiable continuity, each entry linking the part that defines it.
- [Mission-Bound Authorization: The Standards Map](https://notes.karlmcguinness.com/notes/mission-bound-authorization-standards-map.md): A standards map for Mission-Bound Authorization: the ratified substrate, active OAuth and WIMSE work, selected individual drafts, and OpenID specifications that the architecture builds on, composes with, or must not be confused with.
- [The Mission-Based Authorization Vendor Test](https://notes.karlmcguinness.com/notes/mission-based-authorization-vendor-test.md): The public evaluation tool for agent authorization claims: six questions that separate mission-based authorization from scopes, sessions, task IDs, token validation, and logs. Built for architecture reviews, vendor calls, and RFPs.
- [Common Objections to Mission-Based Authorization](https://notes.karlmcguinness.com/notes/common-objections-to-mission-based-authorization.md): Twenty-three strong objections to mission-based authorization, answered by control plane while keeping existing capabilities, proposed additions, and residual risks distinct.
- [Mission-Bound Authorization on the Wire](https://notes.karlmcguinness.com/notes/mission-bound-authorization-on-the-wire.md): The running example of the Mission-Bound Authorization handbook as actual protocol exhibits: the PAR submission, the Mission-bound token, the AuthZEN permit and denial, the revocation, the lifecycle event, and the status check that stops the resume. Authorization for AI agents, byte by byte.
- [Mission-Based Authorization: The Field Reference](https://notes.karlmcguinness.com/notes/mission-based-authorization-field-reference.md): The canonical reference for mission-based authorization, the authorization layer for AI agents: the category definition, the six-property litmus test, how it compares to scopes, sessions, task IDs, and PDPs, the adoption stages, the threats and non-goals, the glossary, and one worked example end to end.
- [Least-Privilege MCP Tool Calls Need a Mission](https://notes.karlmcguinness.com/notes/least-privilege-mcp-tool-calls-need-a-mission.md): Least-privilege MCP tool calls can carry narrow authority in a token or decide each call at the resource. Both work for one call. Both fragment under fan-out. A Mission supplies the durable approved task both models project from.
- [Least Exposure Is Broader Than Least Privilege](https://notes.karlmcguinness.com/notes/least-exposure-is-broader-than-least-privilege.md): Least privilege bounds what an agent may do. Least exposure bounds what reaches the model while it decides what to do. For agents, authorized access is not the same as safe exposure: prompt context, retrieved documents, tool schemas, secrets, policies, memory, and tool outputs can all steer or leak through a perfectly authorized call. The same approved task that bounds tool use should bound the working set.
- [The Question Authorization Never Answered](https://notes.karlmcguinness.com/notes/the-question-authorization-never-answered.md): Authorization standardized human and workload identity, delegation, asynchronous resource sharing, and per-request decisions, and every generation deferred the same question because a person or a process carried the answer. Unattended work removes the carrier and exposes what the stack still lacks: durable shared state for the approved undertaking.
- [The Convergence and the Wagers](https://notes.karlmcguinness.com/notes/the-convergence-and-the-wagers.md): The closing part of the Mission-Bound Authorization handbook: AAuth as the clean-slate protocol that adopted the same missing object, the six wagers underneath the design (admission grain, issuer home, the price of Termination, the necessity of the object, the portability of its authority, the classification line), each with the evidence that would falsify it, and where the framework leads.
- [The Authority Control Plane](https://notes.karlmcguinness.com/notes/the-authority-control-plane.md): Part 2 of the handbook's concluding chapter: the layer's operational position. Two enforcement chokepoints that are strictly stronger together, the pattern space of bindings from the standalone Mission Authority Server to the portable Mandate, and the structural mapping that makes the layer the control plane for delegated authority, with the three disciplines that keep the framing honest.
- [What Survives Without OAuth](https://notes.karlmcguinness.com/notes/what-survives-without-oauth.md): Part 1 of the handbook's concluding chapter: the substrate-neutral framework behind mission-bound authorization. Four functions that survive any substrate, a verb spine from propose to analyze owned by named documents, and the fundamental-versus-accidental test that separates the laws from their OAuth realization.
- [Closing the Agent Authorization Gaps](https://notes.karlmcguinness.com/notes/closing-the-agent-authorization-gaps.md): An individual Internet-Draft in the OAuth working group's orbit catalogs nine agent use cases, a gap analysis under each, and five major gaps rolled up in its summary. This part runs Mission-Bound Authorization against twelve asks drawn from both grains: ten answered with named machinery, one partial with the nuance stated, one largely delegated.
- [Making Compliance a By-Product](https://notes.karlmcguinness.com/notes/making-compliance-a-by-product.md): AI governance frameworks do not ask whether your agent is safe. They ask you to show it: who approved the work, what exactly was approved, who could stop it, and where the records are. This part crosswalks NIST AI RMF, the EU AI Act's high-risk obligations, and ISO/IEC 42001 onto the handbook, whose enforcement artifacts are the evidence the frameworks demand.
- [Containing the OWASP Agentic Threats](https://notes.karlmcguinness.com/notes/containing-the-owasp-agentic-threats.md): OWASP's agentic threat work is where security reviews of agent systems start. This part runs mission-bound authorization against the fifteen-threat Agentic AI Threats and Mitigations taxonomy, the LLM Top 10, and the 2026 Top 10 for Agentic Applications, and gives each a verdict instead of a hand-wave: contained by machinery built for it, bounded at the action gate, or delegated to a named complement.
- [Answering the Laws of AIdentity](https://notes.karlmcguinness.com/notes/answering-the-laws-of-aidentity.md): A critical crosswalk from Patrick Parker's Seven Laws of AIdentity to Mission-Bound Authorization: where the architecture maps directly, where coverage depends on an assurance level or optional profile, and where real gaps remain.
- [Splitting the Lethal Trifecta](https://notes.karlmcguinness.com/notes/splitting-the-lethal-trifecta.md): The lethal trifecta is private data, untrusted content, and external communication in one agent loop. Mission-bound authorization cannot make the model injection-proof, so it does the structural thing instead: type the three legs, keep them split at execution time, and make the third leg unreachable without a fresh decision.
- [The Agent Runtime and Audit](https://notes.karlmcguinness.com/notes/the-agent-runtime-and-audit.md): An approved Mission can be revoked, but a long-running agent has a session that survives the revocation, work already in flight, and signed records only its issuer can vouch for. This part defines the operational layer that closes those gaps: harness binding, safe unwinding, and tamper-evident audit.
- [Mission Lifecycle and Change](https://notes.karlmcguinness.com/notes/mission-lifecycle-and-change.md): A Mission is not static. This part makes its state a first-class, fail-safe surface. A consumer holding only a mission_id can observe current state and be told when it changes, an authorized party can revoke or suspend it, growth happens only through a fresh approval that supersedes its predecessor, and authority retires itself one entry at a time as work finishes.
- [Mission-Bound Runtime Enforcement](https://notes.karlmcguinness.com/notes/mission-bound-runtime-enforcement.md): A Mission-bound token is not a license to act. Before each consequential action, a Policy Enforcement Point gets a permit from a Policy Decision Point that evaluates the action against the current Mission. This is the load-bearing safety layer of the handbook.
- [Mission-Bound Authority: Instances, Actors, and Delegation](https://notes.karlmcguinness.com/notes/mission-bound-authority.md): Agent authentication answers who is acting. The Mission answers what the acting is for. This part is the bridge: the mission claim on tokens bound to attested agent instances, the actor chain that records who acts for whom, the cross-domain grant that lets another Authorization Server honor the Mission, and delegation that only narrows, from act chains to Child Missions to offline attenuation.
- [From a Request to an Approved Mission](https://notes.karlmcguinness.com/notes/from-a-request-to-an-approved-mission.md): Before any token exists, a user request has to become a trustworthy approved Mission. Shaping proposes a candidate Intent, Consent Evidence commits the structured consent disclosure the Authorization Server recorded as rendered (not the pixels or the Approver's comprehension), and Deferred Approval with its Revision companion makes the approval event async and narrowable. None of them grants authority.
- [Adopting Mission-Bound Authorization](https://notes.karlmcguinness.com/notes/adopting-mission-bound-authorization.md): The adoption path for mission-bound authorization, staged honestly: crawl is the issuance core and a kill switch, walk is the Runtime-Enforced level with per-action enforcement on ratified substrate, and run is the Governed and High-Assurance Agent levels with the advanced and experimental roadmap. Each stage names what you get, what you do not, and what you will operate, and each level makes a broader class of write authority defensible: the graduation path off the read-only ceiling.
- [The Mission Is the Missing Abstraction](https://notes.karlmcguinness.com/notes/the-mission-is-the-missing-abstraction.md): OAuth has no first-class object for the task the user approved. A Mission makes that task a durable governance record that bounds AI agent authority across tokens, calls, sub-agents, and time.
- [From the Card to the Architecture](https://notes.karlmcguinness.com/notes/from-the-card-to-the-architecture.md): The corporate-card chapter taught a governance loop with no protocol in sight. This part is the translation: each of its five rules becomes a law of delegated authority, the corporate-card test becomes the claim gate, and every place the analogy broke becomes a named piece of the draft family.
- [Canceling the Card Doesn't Stop the Charges](https://notes.karlmcguinness.com/notes/canceling-the-card-doesnt-stop-the-charges.md): You canceled the card, and the gym billed the replacement number you never gave it. Endings are the hardest part of delegated authority, and payments has the scars to prove it: freezes versus cancellations, charges caught between authorized and settled, disputes as governed undo, and the statement that joins the whole story. AI agents need every one of those endings, built on purpose.
- [The Network Approves Every Transaction, Not the Card](https://notes.karlmcguinness.com/notes/the-network-approves-every-transaction.md): A declined card is the most normal event in payments, because possession of the card was never the control. Every swipe is authorized against current state with the amount and merchant in the authorization. AI agents need the same per-action check, in a world with no payment network, no honest cardholder, and more than one ATM.
- [The Contractor Gets Their Own Card](https://notes.karlmcguinness.com/notes/the-contractor-gets-their-own-card.md): Lending your corporate card to a contractor is the convenient failure everyone recognizes on sight. The right answer is a narrower instrument with the contractor's own name on it, one that dies with the project. AI agents spawn helpers by the dozen, and the same rule is the difference between delegation and contagion.
- [You Approve What You Were Shown](https://notes.karlmcguinness.com/notes/you-approve-what-you-were-shown.md): An approval is not a feeling of assent. It is a decision bound to a specific disclosure: the request as the approver saw it, at the moment they saw it. Spend systems learned this, payment regulation made it explicit, and agent systems need it before any agent takes its first action.
- [Agents Need a Corporate Card, Not a Blank Check](https://notes.karlmcguinness.com/notes/agents-need-a-corporate-card-not-a-blank-check.md): Enterprises already run a mature delegated-authority architecture for humans. It is called expense governance. The corporate-card pattern maps, control by control, onto what agent authorization is missing, and the places where the analogy breaks are the build list.
- [A Blocked Agent Is a Captive Client](https://notes.karlmcguinness.com/notes/a-blocked-agent-is-a-captive-client.md): Agent egress proxies block destinations the agent discovers it needs at runtime, and today that block is an opaque connection failure with no machine-actionable recovery. RFC 8908, the Captive Portal API, supplies the recovery state machine for a blocked client. A headless agent can be modeled as a captive client, with the carrier chosen by where the block lands.
- [The Identity Continuation Assertion](https://notes.karlmcguinness.com/notes/identity-continuation-assertion.md): ID-JAG works at the first hop, where an application holds the user's credential to exchange. The hops after it hold no user credential, yet only the IdP can mint the next audience-scoped grant. The Identity Continuation Assertion is the missing input: short-lived, sender-constrained evidence of an in-flight delegation that an intermediate presents to the IdP to request an onward ID-JAG.
- [Trusting Issuers in Open-World OAuth](https://notes.karlmcguinness.com/notes/trusting-issuers-in-open-world-oauth.md): Open-world OAuth needs a way to decide whether a previously-unknown issuer is trusted for a particular subject namespace. The Identity Assertion Trust Framework separates issuer authenticity from namespace authority, and the Domain-Authorized Issuer Trust Method gives domain owners a fail-closed way to publish that authority.
- [Closing the Gaps in Least-Privilege MCP Tool Calls](https://notes.karlmcguinness.com/notes/closing-the-gaps-least-privilege-mcp-tool-calls.md): The two models for least-privilege Model Context Protocol (MCP) tool calls both leave gaps on plain OAuth. The AuthZEN Authorization API standardizes the policy decision, its MCP profile (COAZ) the request mapping, the Access Request and Approval Profile (ARAP) what happens when the answer is no, and proposals like the Access Request OAuth Profile (AROP) and MCP Specification Enhancement Proposals (SEPs) bind the workflow to the wire. None of them names the task the calls serve. This second part walks that stack and the gap that remains.
- [Two Models for Least-Privilege MCP Tool Calls](https://notes.karlmcguinness.com/notes/least-privilege-mcp-tool-calls.md): Least-privilege Model Context Protocol (MCP) tool calls can be authorized two ways: carry a narrow token an authorization server mints, or let the resource decide each call. This first part walks both models on plain OAuth, lays out the OAuth challenge family that signals and remediates insufficient authorization at four grains, makes the MCP tool boundary first-class, and shows where each one strains and how to choose. Part two covers the standards that close the per-call gaps.
- [Authorization Is the Other Half of Executable Intent](https://notes.karlmcguinness.com/notes/authorization-is-the-other-half-of-executable-intent.md): Evaluations made human intent executable for verification: did the agent behave? Authorization needs the same move for the other question, what the agent should be allowed to do. A shaped, validated, and approved mission turns an open-ended request into a bounded authority enforced at runtime, the preventive twin of an eval.
- [Re-Subjecting Is a Mint, Not an Attenuation](https://notes.karlmcguinness.com/notes/re-subjecting-is-a-mint-not-an-attenuation.md): Attenuation can narrow authority already represented by an artifact. It cannot create an authoritative binding to a target-local subject identifier. When a downstream domain names the user differently, an authority trusted for that mapping must mint new identity evidence.
- [Authorization Denied Is No Longer Enough](https://notes.karlmcguinness.com/notes/authorization-denied-is-no-longer-enough.md): Most authorization systems still treat denial as a terminal state. In open-world systems with agents, runtime discovery, delegation, and evolving missions, denial is increasingly the start of a governance escalation. What is missing is a standardized handoff between authorization and whatever workflow decides whether authority should continue.
- [SAML at the Post-Quantum Crossroads](https://notes.karlmcguinness.com/notes/saml-at-the-post-quantum-crossroads.md): SAML is still the enterprise SSO default, but XML Signature complexity, aging implementation stacks, and post-quantum migration pressure make it a poor long-term default for new deployments.
- [The Agent Provider Is the IdP: A Standards Reading of WorkOS auth.md](https://notes.karlmcguinness.com/notes/agent-provider-is-the-idp-standards-reading-of-workos-auth-md.md): WorkOS auth.md frames a real pattern for one-click agent setup with third-party services. The useful standards question is not whether agents need runtime signup, but how the Agent Verified path composes ID-JAG, OAuth client registration, metadata, lifecycle, and trust establishment.
- [Sessions Are Not Missions](https://notes.karlmcguinness.com/notes/sessions-are-not-missions.md): Resumable agent sessions preserve execution continuity. They do not preserve authority. Long-running agents need a mission layer that can decide whether execution should still be allowed to continue.
- [Client Instances Are Actors, Not New Clients](https://notes.karlmcguinness.com/notes/client-instances-are-actors-not-new-clients.md): OAuth registers clients. Agent platforms run instances. The Actor Profile gives us the slot to make instances first-class without changing how OAuth clients work at the protocol level.
- [Enterprise SaaS Needs OAuth Federation Now](https://notes.karlmcguinness.com/notes/enterprise-saas-needs-oauth-federation-now.md): Point-to-point OAuth keeps creating app-specific OAuth islands across enterprise SaaS. The fix is OAuth federation: issuer-signed assertion in, local access token out, with XAA as the standards direction for user-delegated cross-app access.
- [AAuth Now Has a Mission Layer](https://notes.karlmcguinness.com/notes/aauth-now-has-a-mission-layer.md): The new version of AAuth (draft-hardt-aauth-protocol-01, since resubmitted as draft-hardt-oauth-aauth-protocol) adds a real mission layer to the protocol. The remaining question is no longer whether Mission exists, but whether the published model is strong enough to support portable containment, attenuation, and cross-domain enforcement.
- [ID-JAG Beyond the Enterprise IdP](https://notes.karlmcguinness.com/notes/id-jag-beyond-the-enterprise-idp.md): ID-JAG, also often discussed as Cross-App Access (XAA), is usually framed as an Enterprise IdP pattern, but the real boundary is narrower and more useful: the issuer the downstream authorization server already trusts for SSO and subject resolution. In many deployments that immediate IdP is a CIAM or platform identity layer, not the top-level workforce IdP.
- [Open-World OAuth Still Needs Mission Shaping](https://notes.karlmcguinness.com/notes/open-world-oauth-still-needs-mission-shaping.md): Part 2 of the Open-World OAuth series. Even if OAuth closes its discovery, resource binding, and first-contact trust gaps, agents still need a way to turn approved task intent into bounded authorization that stays governed across delegation chains, unfamiliar tool semantics, consent expansion, and the full lifecycle of a task from approval to termination.
- [OAuth for Open-World Ecosystems](https://notes.karlmcguinness.com/notes/oauth-for-open-world-ecosystems.md): OAuth was built around a closed-world deployment model: clients, authorization servers, and resource servers were configured to know each other ahead of time. Agents invert that assumption. They discover tools and protected resources at runtime, which means OAuth needs stronger support for open-world discovery, resource binding, and first-contact trust.
- [Standardize `act` Across Assertion Grants and JWT Access Tokens](https://notes.karlmcguinness.com/notes/standardize-act-across-assertion-grants-and-jwt-access-tokens.md): OAuth deployments need one interoperable way to represent explicit delegation. Reusing `act` with entity profiles across JWT assertion grants and JWT access tokens closes a long-standing gap where `sub` semantics are ambiguous and delegation is implicit.
- [Mission Shaping Is Not Enough](https://notes.karlmcguinness.com/notes/mission-shaping-is-not-enough.md): Part 2 of the Mission Shaping series. Even a well-shaped Mission cannot by itself make an open-world agent safe.
- [The Mission Shaping Problem](https://notes.karlmcguinness.com/notes/the-mission-shaping-problem.md): Part 1 of the Mission Shaping series. Approved intent is not authority, and many current deployments still skip the step that turns approval into a governable Mission.
- [Why Mission-Bound OAuth Might Be the Wrong Answer](https://notes.karlmcguinness.com/notes/why-mission-bound-oauth-might-be-the-wrong-answer.md): Mission-Bound OAuth may be a pragmatic improvement for OAuth-heavy enterprises, but it may also be the wrong layer for the real problem. This post argues the architecture overloads the authorization server, mixes governance with transport, and may still underfit actual agent execution systems.
- [Mission Architecture on AAuth](https://notes.karlmcguinness.com/notes/mission-architecture-on-aauth.md): A follow-up to Mission-Bound OAuth: if OAuth is the incremental path, AAuth may be the clean-sheet substrate for the same Mission governance model.
- [Client Context and ID-JAG for Mission-Bound OAuth](https://notes.karlmcguinness.com/notes/client-context-and-id-jag-for-mission-bound-oauth.md): Access tokens are audience-bound: a token for one resource server is not valid at another. When an agent mission spans multiple authorization domains, Rich Authorization Requests alone cannot carry the mission across that boundary. This post proposes a narrower companion profile: OpenID Connect Client Context bootstraps Mission approval at authentication time, and ID-JAG projects reduced Mission context across same-IdP trust domains.
- [Mission-Bound OAuth](https://notes.karlmcguinness.com/notes/mission-bound-oauth.md): An RFC for Mission-Bound OAuth: an OAuth-based architecture for durable, bounded delegated authority for agents and automation.
- [Agents Don't Need Your Passport. They Need Your Authority.](https://notes.karlmcguinness.com/notes/agents-dont-need-your-passport-they-need-your-authority.md): Identity controls verify who the agent is. Access controls govern each boundary. Delegation records who may act for whom. None of them ask whether the mission behind a request should still be running. That is the gap agents expose, and it is structural.
- [From Passports to Power of Attorney](https://notes.karlmcguinness.com/notes/from-passports-to-power-of-attorney.md): No widely adopted control-plane component holds mission authority as a first-class, independently revocable artifact. The Execution Mandate closes that gap: a signed authority record carrying purpose, scope, conditions, lifecycle, and delegation chain, governable independently of token validity.
- [Governing the Stay, Not Just the Entry](https://notes.karlmcguinness.com/notes/governing-the-stay-not-just-the-entry.md): The Execution Mandate is the artifact. This post builds the four-component control plane that makes it real: a mandate service that owns mission state, continuous evaluation that governs whether execution should continue, cross-domain propagation that extends authority across trust boundaries, and orchestration-layer enforcement that can terminate execution when the mandate ends.
- [Welcome to Control Plane](https://notes.karlmcguinness.com/notes/welcome-to-control-plane.md): Hot takes, insights, and analysis on identity, security, and agentic systems.

## Other

- [Site home](https://notes.karlmcguinness.com/): Human-readable article index.
- [RSS feed](https://notes.karlmcguinness.com/index.xml): Recently published content.
- [Full Markdown corpus](https://notes.karlmcguinness.com/llms-full.txt): Full text of every published article in one file.
- [The complete handbook edition](https://notes.karlmcguinness.com/mission-handbook/read.md): The full Mission-Bound Authorization handbook (version 0.13.3), chapters, companions, and appendices, as one Markdown file.