Control Plane by Karl McGuinness

A Blocked Agent Is a Captive Client

Fri, 17 Jul 2026 09:00:00 -0700

Long-running agents discover mid-task that they need a destination their egress proxy does not allow, and the block comes back as an opaque connection failure with no machine-actionable way to ask for access and no human standing by. That block is a requestable denial, and the egress proxy is a policy enforcement point. RFC 8908, the Captive Portal API, supplies the recovery state machine for a blocked client on a network: discover captivity, learn the remediation endpoint, and retry after policy changes. A headless agent can use that state machine, with the denial carried by Proxy-Status and Problem Details where an HTTP response exists and by an authenticated side-channel status API where it does not. The recovery can ride the captive portal at two altitudes, destination-level on a proposed AuthZEN Access Request profile or operation-level on AAuth and Mission-bound authority. When the client already speaks AAuth, it needs no captive-portal shim at all, because AAuth carries the refusal and re-authorization in-band at the same request boundary the proxy already enforces.

The Identity Continuation Assertion

Wed, 08 Jul 2026 09:00:00 -0700

Re-subjecting across a SaaS boundary is a mint, not an attenuation, so the IdP must issue each onward grant. ID-JAG covers the first hop, where an application holds the user’s ID Token or SAML assertion to exchange. Subsequent hops hold no end-user credential, which leaves a gap: the intermediate has nothing to present to the IdP to continue the chain. The Identity Continuation Assertion fills it. It is a short-lived, sender-constrained JWT, issued by a Chain Authority the IdP trusts, that carries opaque evidence of the in-flight delegation and is presented as the Token Exchange subject token to request an onward ID-JAG. It is evidence, not authority: it carries no subject and grants no access, the IdP resolves the target audience’s subject and re-decides at every hop, and the chain correlator never reaches a Resource Server.

Trusting Issuers in Open-World OAuth

Sun, 05 Jul 2026 14:00:00 -0700

Self-service agent sign-up exposes a first-contact trust problem: a Resource Authorization Server can verify a perfectly valid JWT and still not know whether the issuer is allowed to assert identities for the user’s domain. That is two questions, not one. Federation proves the issuer is authentic, but not that the namespace owner authorized it, and static allowlists do not scale to onboarding unknown domains at runtime. The Identity Assertion Trust Framework lets a Resource AS publish the evidence it requires. The Domain-Authorized Issuer Trust Method lets a domain owner publish which issuers may assert identities in its namespace, fail-closed, the way mail and the web already pushed authority into DNS. Both compose with ID-JAG and the JWT-bearer grant without changing the grant surface.

Closing the Gaps in Least-Privilege MCP Tool Calls

Fri, 26 Jun 2026 10:00:00 -0700

Part one laid out two ways to lock down a single tool call an agent makes through the Model Context Protocol: carry a narrow token, or let the resource decide each call. This part walks the standards that close the gaps. AuthZEN gives a standard way to ask the policy question, the Access Request and Approval Profile turns a denial into a governed request for approval, and a set of proposals carries that approval over the wire. Each makes one call’s authorization more interoperable, and none gives a multi-step task a shared identity. So a string of individually correct calls can still drift from what the user approved. The missing piece is a durable, governed record of the approved task, the object I call a Mission.

Two Models for Least-Privilege MCP Tool Calls

Thu, 25 Jun 2026 10:00:00 -0700

There are two natural ways to lock an agent’s Model Context Protocol (MCP) tool calls down to least privilege. The agent can carry a narrow token scoped to the action, or the server can decide each call as it happens. Carrying a token gives portable proof of what the agent may do, but pushes domain knowledge onto the authorization server and token management onto the client. Deciding at the resource keeps the meaning where it lives, but the decision is not portable. MCP makes the tool boundary first-class for both. This part compares the two models and how to choose. Part two covers the standards that close the per-call gaps and the task object neither names.

Authorization Is the Other Half of Executable Intent

Wed, 10 Jun 2026 09:00:00 -0700

Microsoft’s ASSERT compiles written behavior requirements into executable evaluations: intent made executable for verification. That answers what the agent did, not what it was allowed to do: an eval produces a verdict, not a binding authorization decision, and for irreversible actions that is the whole difference. The mission is the preventive counterpart: a shaper proposes the request as a bounded, machine-readable object, a trusted authority validates and narrows it, an approver signs off, and enforcement checks every consequential action against it. Same lineage from natural-language intent, a higher bar, and teeth an eval does not have. One approved mission then drives both the runtime boundary and the behavioral eval, while a separate shaping-quality check asks whether the boundary matched the user’s intent in the first place.

Re-Subjecting Is a Mint, Not an Attenuation

Mon, 08 Jun 2026 09:00:00 -0700

In Cross-App Access, a single signed-in user’s identity has to cross applications that each name them under a different subject. Workload identity proves which service is calling, not which user delegated the work, and offline attenuation can narrow authority it already holds but cannot create a binding to a name it was never given. So crossing a subject namespace is a mint, not an attenuation: only the IdP or broker that owns the mapping can issue new audience-scoped identity evidence, while the destination Authorization Server still applies its own policy and mints the access token. The same shape holds on the authorization axis, where a different scope or policy model forces a non-amplifying re-mint rather than a narrowing. The open question is not whether that mapping authority is in the loop but how it is invoked: caller-pushed continuation, resource-pulled resolution, or another profile that preserves the trust invariant.

Authorization Denied Is No Longer Enough

Tue, 02 Jun 2026 09:00:00 -0700

Closed-world authorization treated denial as the end of the interaction. Agents, runtime discovery, delegation, and mission expansion turn denial into the beginning of governance escalation. The draft AuthZEN access request and approval profile standardizes that handoff without standardizing the workflow engines behind it. Client-Initiated Backchannel Authentication (CIBA) is not the answer because the problem is not authentication freshness. It is whether authority should continue under newly discovered runtime conditions.

SAML at the Post-Quantum Crossroads

Thu, 28 May 2026 12:00:00 -0700

OpenID Connect is mature, standardized, and widely deployed, but SAML remains the enterprise SSO default because it is familiar, explicit, and deeply embedded in procurement and operations. That familiarity now hides a harder problem: XML Signature complexity, aging implementation stacks, limited post-login integration, and post-quantum migration pressure make SAML difficult to defend as the long-term enterprise baseline. The industry needs a secure enterprise OIDC profile and a credible migration path that preserves identity contract continuity for existing SAML federations.

The Agent Provider Is the IdP: A Standards Reading of WorkOS auth.md

Fri, 22 May 2026 12:00:00 -0700

WorkOS auth.md is an agent-readable registration document for one-click setup, with Agent Verified, user-claimed, and anonymous paths. In the Agent Verified path, most pieces already exist across OAuth and OpenID standards: ID-JAG, OAuth metadata, dynamic client registration, standard token endpoints, and SSF/CAEP/OPC. The standards gap is a profile for runtime agent onboarding and trust establishment, not a new grant protocol.

Sessions Are Not Missions

Mon, 11 May 2026 21:08:15 -0700

Modern agent harnesses make work durable across restarts, devices, background jobs, and sub-agents. That durability is a runtime property, not a governance property. A session answers where the agent can continue working. A mission answers why the agent is allowed to keep working. Conflating them is a central failure mode of long-running autonomous agent systems.

Client Instances Are Actors, Not New Clients

Tue, 05 May 2026 10:00:00 -0700

Client instances are not new clients. They are actors. With the Actor Profile and the act chain already in place, and an instance_issuers field that fits any client registration channel (static, Dynamic Client Registration, or CIMD), treating instances as first-class actors needs no new grant type, no new client type, and no new claim. It needs a profile that ties them together.

Enterprise SaaS Needs OAuth Federation Now

Sun, 19 Apr 2026 20:05:00 -0700

Enterprise SaaS still defaults to app-by-app OAuth islands with their own clients, long-lived artifacts, and revocation paths. The architectural shift is OAuth federation: adopt issuer-mediated federation now for services and workloads, and adopt Cross-App Access (XAA) as the standards direction for user-delegated cross-app access.

AAuth Now Has a Mission Layer

Mon, 13 Apr 2026 11:21:00 -0700

The new version of AAuth (draft-hardt-aauth-protocol-01, since resubmitted as draft-hardt-oauth-aauth-protocol) materially changes the earlier comparison. Mission is now first-class in the protocol, with PS-mediated approval, mission-aware token choreography, and governance endpoints. The remaining gap is no longer whether Mission exists, but whether the published model is strong enough to support portable containment rather than just mission correlation and governance hooks.

ID-JAG Beyond the Enterprise IdP

Sun, 05 Apr 2026 12:00:00 -0700

ID-JAG, also often called Cross-App Access (XAA), is centered in the current draft on Enterprise IdP trust, but the issuer that matters is the immediate IdP the downstream authorization server already trusts for SSO and subject resolution, not necessarily the top-level workforce IdP. The same trust pattern can also extend architecturally to CIAM and platform identity layers that federate upstream workforce login while remaining authoritative for downstream product trust, tenant context, and subject resolution.

Open-World OAuth Still Needs Mission Shaping

Sat, 21 Mar 2026 10:00:00 -0700

Open-world OAuth can improve discovery, resource binding, and first-contact trust. That still leaves the harder agent problem: how approved intent becomes bounded authority that stays governed across delegation chains, unfamiliar tools, consent expansion, revocation, and task termination.

OAuth for Open-World Ecosystems

Fri, 20 Mar 2026 10:00:00 -0700

OAuth was built for closed worlds, and that constraint is why it became mature. Agents expose the limits of that deployment model. This post traces what the newer OAuth standards get right and which substrate gaps still need to close.

Standardize `act` Across Assertion Grants and JWT Access Tokens

Wed, 18 Mar 2026 10:30:00 -0700

The current split between token exchange semantics and JWT access token practice creates avoidable interoperability failures. A common profile for act, grounded in entity profiles, can align JWT assertion grant and JWT access token processing.

Mission Shaping Is Not Enough

Wed, 18 Mar 2026 09:00:00 -0700

Part 2 turns from the semantic problem to the runtime one. Quiet expansion, delegation, headless execution, stale state, and open-world execution all push Mission shaping past its strongest domain. Containment and runtime governance carry more of the safety burden.

The Mission Shaping Problem

Tue, 17 Mar 2026 09:00:00 -0700

This essay picks up from Part 4 of the Mission-Bound OAuth series and focuses on the first hard problem: how approved intent becomes a governable Mission. In structured domains that can look like staged Mission shaping or compilation. Many current deployments still do not do it at all.

Why Mission-Bound OAuth Might Be the Wrong Answer

Sun, 15 Mar 2026 12:00:00 -0700

Mission-Bound OAuth is a serious attempt to govern delegated agent authority using existing OAuth infrastructure. This post takes the pessimistic view: it may be the wrong answer because it asks the authorization server to become a governance engine, a lifecycle controller, and a mission ledger all at once. A cleaner alternative is to treat Mission as a separate authority service and let OAuth be one projection of that model rather than its home.

Mission Architecture on AAuth

Sun, 15 Mar 2026 09:00:00 -0700

Mission-Bound OAuth argues for a durable Mission object that governs delegated authority across approval, lifecycle, delegation, and termination. This follow-up asks whether Dick Hardt’s AAuth draft is a better protocol substrate for the same model, and where AAuth still appears to need an explicit Mission-like authority object.

Client Context and ID-JAG for Mission-Bound OAuth

Sat, 14 Mar 2026 09:00:00 -0700

Rich Authorization Requests are the natural first instinct for agent missions, but audience-bound access tokens and uneven cross-domain interoperability limit how far they can carry a governed task. Mission-Bound OAuth solves that by making the Mission a durable authority object at the authorization server. This post explores the authentication-layer companion profile: OpenID Connect Client Context carries purpose and approval input when the user is present, and ID-JAG carries reduced Mission projections across same-IdP trust domains.

Mission-Bound OAuth

Fri, 13 Mar 2026 09:00:00 -0700

OAuth answers whether a request is permitted right now. Mission-Bound OAuth asks whether a delegated mission should still be running at all. This RFC proposes a durable Mission object at the Authorization Server that governs token derivation, lifecycle, delegation, and termination across agent execution.

Agents Don't Need Your Passport. They Need Your Authority.

Sat, 21 Feb 2026 22:59:09 -0800

Enterprise IAM was designed for human-paced execution. Agents remove the presence, pacing, and natural scope-limiting that made those controls work. The result is a structural gap that stronger credentials, tighter scopes, and faster JIT provisioning cannot close.

From Passports to Power of Attorney

Sat, 21 Feb 2026 22:59:09 -0800

Tokens, credentials, and scopes tell a system what an agent may do. They say nothing about why execution was authorized or when it should end. The Execution Mandate is the primitive that closes that gap: a signed, inspectable authority record that runtime systems can evaluate and revoke throughout the execution lifecycle.

Governing the Stay, Not Just the Entry

Sat, 21 Feb 2026 22:59:09 -0800

An Execution Mandate defines what delegated authority looks like. This post builds the control plane that makes it operational: how mandates are issued and held as authoritative artifacts, how authority is evaluated continuously rather than at gates, how governance crosses organizational boundaries, and where enforcement lands in practice.

About

Sat, 21 Feb 2026 00:00:00 +0000

I’m Karl McGuinness, a product and technology leader with 25+ years of experience building mission-critical, internet-scale identity and infrastructure platforms. At Okta, I spent over a decade helping modern enterprises and the broader industry treat identity as foundational infrastructure.

I specialize in product architecture, the intersection of product strategy and system design. I translate ambiguous requirements into durable product structures: domain boundaries, APIs, platform extensibility, and investment sequencing that keep teams fast today and options open later.

Welcome to Control Plane

Mon, 28 Apr 2025 23:22:40 -0700

Identity is getting weird again, and in a good way.

This blog is where I post hot takes, field notes, and analysis on identity, security, and agentic systems. Some posts will be tactical. Some will be opinionated. Some will be me zooming out and asking, “are we solving the right problem at all?”

Lately I keep coming back to one thing: most of our stack is great at deciding who can get in, and still pretty weak at governing what autonomous systems should keep doing over time.