Essays and field notes on identity as infrastructure: authentication, authorization, delegation, and authority governance
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 one projection of that model rather than its home.
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 Context carries purpose and approval input when the user is present, and ID-JAG carries reduced Mission projections across same-IdP trust domains.
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.
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.