Delegated Authority

8 Articles

Authorization Is the Other Half of Executable Intent

Evals Made Intent Executable for Verification. A Mission Makes It Executable for Authorization.

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.

Agentic Identity Authorization Delegated Authority AI Agents Evals Standards

Re-Subjecting Is a Mint, Not an Attenuation

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.

Agentic Identity ID-JAG Identity Chaining Transaction Tokens OAuth Delegated Authority IAM XAA Standards

Authorization Denied Is No Longer Enough

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.

Authorization AuthZEN Agentic Identity Delegated Authority IAM OAuth Standards Mission Shaping

Sessions Are Not Missions

Why Agent Harnesses Cannot Own the Mission Layer

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.

Agentic Identity Delegated Authority IAM OAuth Authorization Security Architecture Sessions MCP

Client Context and ID-JAG for Mission-Bound OAuth

Series Mission-Bound OAuth Part 2 of 4

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.

Agentic Identity Delegated Authority IAM OAuth OpenID Connect Authorization ID-JAG

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

Series You Don't Give Agents Credentials. You Grant Them Power of Attorney. Part 1 of 3

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.

Agentic Identity Delegated Authority IAM OAuth Authorization Security Architecture

From Passports to Power of Attorney

Series You Don't Give Agents Credentials. You Grant Them Power of Attorney. Part 2 of 3

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.

Agentic Identity Delegated Authority IAM OAuth Authorization Security Architecture

Governing the Stay, Not Just the Entry

Series You Don't Give Agents Credentials. You Grant Them Power of Attorney. Part 3 of 3

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.

Agentic Identity Delegated Authority IAM Authorization Security Architecture