# 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
- [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) 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.