Recent content on Control Plane by Karl McGuinness
The question worth asking about AAuth is not only whether the protocol is good. Kerberos won because of everything around the protocol: SSPI and GSS-API hid the mechanism from application developers, the LSA owned keys and ticket lifecycle, machine accounts existed as a side effect of domain join, Active Directory shipped the KDC by default, and SPNEGO made rollout incremental. Mapping that stack…
Agent runtimes naturally create the first trustworthy evidence about an instance, which gives them the default position in agent identity. Runtime proof and enterprise binding are still separate jobs. In heterogeneous enterprises, a binding layer can map evidence from many runtimes into durable Agent and Agent Deployment records and supply that governed context to credential issuers and resources.…
Agent task authority is scattered across four de facto records: harness permission prompts, OAuth grants, IAM roles, and change tickets. Each performs a real job, but none is a general, portable system of record for approved work. An action click is not task approval, a grant is not a task lifecycle, and an identity role is not a reason for one undertaking. The missing object is an approved-task…
The control-points series argues that distribution determines defaults and standard seams determine whether those defaults remain contestable. MCP adds the clock. It launched with a specification, SDKs, a distributed host, and reference servers, and one developer could run the whole loop before the ecosystem coordinated. Mature authorization and governance followed the adoption pressure. The…
Cross App Access is not twenty-five generally available integrations. It is three different things at three different stages: a stable MCP authorization extension, a live Claude and Okta beta, and a partner graph whose broader product rollout is still under way. That distinction makes the strategic result clearer. The launch coalition moves protocol coordination from each buyer to the vendors…
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…
Model routers and customer-controlled agent state are now concrete product architectures, but they do not make every model interchangeable or every memory store strategic. The important boundary is narrower. Task checkpoints are operational state, transcripts are evidence, embeddings are derived indexes, and model-generated memories are untrusted proposals. Canonical institutional knowledge…
Delegated work forces four separate continuity questions: request provenance, identity attribution, target-applicable authority, and continuing work justification. Their answers compose through a common boundary contract: authoritative sources, bound and correlated evidence, explicit lifecycle semantics, local decisions, and declared failure behavior. Current proposals fill different parts of that…
Continuity Is Not One Thing argues that delegated work poses four independently governed continuity questions. This companion carries the parts built to be revised rather than to last: a vocabulary that separates facts from evidence, artifacts, authorities, decisions, and state; a twelve-question rubric a working group can apply to any proposal without accepting anyone’s architecture; worked…
The enterprise agent control stack is not one product or one call chain. It is a set of independently governed answers: which instance is running, whose Agent it is, which deployment was approved, why its current work remains authorized, what an issuer may project, how credentials are acquired and presented, whether a resource permits one concrete action, and which evidence proves the joins…
The least-privilege MCP series ends on a gap: token-side and resource-side authorization both work per call, and neither names the task the user approved. This essay applies Mission-Bound Authorization at the MCP boundary. The Mission is the durable approved task, tokens and PDP decisions are projections of it, tool discovery and invocation and approval line up against it, expansion routes through…
Least privilege scopes what an agent may do, one tool call at a time. But a perfectly authorized agent can still be compromised by what it is allowed to see. Least exposure is the broader control: task-scoped minimal disclosure for prompt context, retrieved documents, tool schemas, secrets, business rules, approval context, memory, and downstream responses. Because the model is untrusted…
Authorization looks the way it does because each generation solved the question its era made urgent, and deferred one question that someone else was always carrying: what approved work is this, and is it still on? Purpose was not absent. A second stack of tickets, purchase orders, workflows, and approval systems held it locally, and people carried it between systems. UMA decoupled…
A handbook that ends on its own argument has not concluded, it has just stopped. This chapter is the conclusion: what survives if OAuth disappears (nearly everything: the layer, the laws, the vocabulary, the object), where the layer sits operationally (the control plane for delegated authority, mapped concept by concept with the disciplines that keep the framing honest), and the judgment a reader…
An architecture that only answers its own questions is untested. This chapter runs the handbook against five outside framings: Simon Willison’s lethal trifecta, the threat model that defines what makes agents dangerous. Patrick Parker’s Seven Laws of AIdentity, mapped law by law with coverage and caveats stated rather than claimed whole. OWASP’s agentic threat taxonomy and LLM…
Designing Mission-Bound Authorization establishes the architecture: the object, the laws, the framework, and the staged adoption path. This chapter is the build. Five parts carry the five controls at implementation depth: the approval that creates a Mission, the authority that binds it to agent instances and delegates, the per-action enforcement that polices it, the lifecycle that governs it over…
The AI agent auth best-practices draft names the Mission and declares its translation into authorization out of scope. This chapter is that translation, at architecture depth: the problem in one screen, the vocabulary, the missing layer, the five laws, the reference security architecture, and the canonical picture. Part 1 is the joint between the card model and the protocol. Part 2 defines the…
Enterprises already run a mature delegated-authority architecture. It is called expense governance, and payments spent fifty years hardening it: purpose-issued instruments, approvals bound to what the approver was shown, delegation that only narrows, a network that authorizes every transaction, and cancellations, disputes, and statements that close the loop. This chapter walks that world one…
The whole handbook on one page, in reading order: the cover, the five chapters, the companions, and the six appendices. Print for a paginated PDF, or fetch the Markdown rendition.
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…
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…
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…
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…
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…
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…
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…
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…
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…
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 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 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.
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…
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…
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 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.
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.
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.
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.
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…
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.
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…
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.
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.
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.
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.
Karl McGuinness Previously SVP & Chief Product Architect @ Okta Standards IETF OAuth WG · OpenID Foundation Focus Identity strategy, product architecture, agent-native world Currently Advising identity startups 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…
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…