--- title: "Resilient Cyber Podcast Prep" date: "2026-05-06T00:00:00-08:00" lastmod: "2026-05-06T00:00:00-08:00" description: "Prep doc for Resilient Cyber interview on IAM for agentic AI. Audience: Chris (host) and listeners (CISOs, identity architects, security leaders)." summary: "Resilient Cyber Prep: Karl McGuinness The host\u0026rsquo;s framing is already aligned with your thesis: we built AuthN/AuthZ for human-paced execution; agents remove presence, pacing, and natural scope-limiting; the frontier is delegation, not stronger credentials. Don\u0026rsquo;t re-prove the gap, build on it.\nLive Reference Card Use this when the recording is rolling. Everything else is depth on these few lines.\nThe arc, in one breath Agents don\u0026rsquo;t need your passport. They need your authority. And that authority has to be governed across the stay, not just verified at the entry.\n" --- # Resilient Cyber Prep: Karl McGuinness The host's framing is already aligned with your thesis: *we built AuthN/AuthZ for human-paced execution; agents remove presence, pacing, and natural scope-limiting; the frontier is delegation, not stronger credentials.* Don't re-prove the gap, build on it. --- ## Live Reference Card {#live-card} Use this when the recording is rolling. Everything else is depth on these few lines. ### The arc, in one breath > *Agents don't need your passport. They need your authority. And that authority has to be governed across the stay, not just verified at the entry.* ### Top 5 soundbites (drop in any context) 1. *"Identity establishes who. Not why."* 2. *"The gap was invisible because humans were closing it."* 3. *"Zero Trust for humans centered on identity. Zero Trust for agents has to center on delegated authority."* 4. *"It's not a tuning failure. It's a category failure."* 5. *"Mission is the authority clock. PAM is the credential governor."* ### Top 5 pushback responses (one breath each) | Chris says... | You say... | |---|---| | "Doesn't Zero Trust handle this?" | Identity is necessary, not sufficient. ZT for agents has to center on delegated authority. | | "Doesn't IGA / PAM / JIT solve this?" | They reduce blast radius. They don't answer the mission question. Composing request-scoped controls can't produce a mission-scoped one. | | "What about CAEP?" | CAEP is a propagation rail. It needs an authoritative source of mission state to emit from. That source doesn't exist today. | | "Aren't AAuth / AgentPass solving this?" | Mission-as-prose, not mission-as-authority-model. Correlation interop, not enforcement interop. | | "Each vendor handles tokens responsibly" | The issue isn't running islands well. It's whether the islands have to exist at all. | ### Closing line > *We spent the last decade building better ways to verify who is at the door. The next decade is about governing what they are authorized to do once they are inside.* --- ## Trigger Index {#trigger-index} What Chris says, where to look. | If Chris pivots to... | Open... | |---|---| | Structural gap, "core problem agents expose" | [§3 Spine, Beat 1](#beat-1) + [§7 #1](#tlp-1) | | Identity for agents | [§3 Beat 2](#beat-2) + [§7 #5](#tlp-5) | | Zero Trust, NIST 800-207, continuous evaluation | [§6 ZT reframe](#sec-6) + [§7 #3](#tlp-3) | | "We already have IGA / PAM / JIT / scopes" | [§7 #4 (category failure)](#tlp-4) | | NHI / agent identity vendors | [§7 #4](#tlp-4) + [§15 Don't Say](#sec-15) | | Recent breaches, OAuth islands, supply chain | [§7 #10](#tlp-10) + [§13 CISO takeaways](#sec-13) | | OAuth standards, your IETF work | [§8.4 Open-World OAuth](#tt-owo) + [§16 Standards](#sec-16) | | AAuth / AgentPass / MCP | [§7 #9](#tlp-9) + [§8.2 MBOAuth](#tt-mboauth) | | Mission Shaping, "where the field needs work" | [§7 #7](#tlp-7) + [§8.3 Mission Shaping](#tt-shaping) | | "How do we make this safe" / containment | [§7 #8](#tlp-8) + [§8.3](#tt-shaping) | | Mandate Service / Mission Authority | [§7 #9](#tlp-9) + [§3 Beat 3](#beat-3) | | Revocation, lifecycle | [§7 #6](#tlp-6) + [§3 Beat 3](#beat-3) | | What CISOs do this quarter | [§13 CISO takeaways](#sec-13) | | "What gives you hope" | [§17 where field goes next](#sec-17) | | Closing thoughts | [§18 closing lines](#sec-18) | --- ## Table of Contents {#toc} 1. [Live Reference Card](#live-card) — top-of-doc cheat sheet 2. [Trigger Index](#trigger-index) — navigate fast 3. **[§3 The Spine](#sec-3)** — TL;DR of the Power of Attorney series 4. [§4 Macro Frame](#sec-4) — four series, four layers 5. [§5 60-Second Arc](#sec-5) 6. [§6 Zero Trust Reframe](#sec-6) 7. **[§7 Top 10 Thought Leadership Points](#sec-7)** — what to steer toward 8. **[§8 Talk Tracks per Series](#sec-8)** — deep references 9. **[§9 Pushback Quick-Fire](#sec-9)** — grouped, scannable 10. [§10 Soundbite Library](#sec-10) — by topic 11. [§11 Connective Tissue](#sec-11) — bridges between topics 12. [§12 Key Analogies](#sec-12) 13. [§13 CISO Takeaways](#sec-13) — Monday-morning answer 14. [§14 Persona One-Liners](#sec-14) 15. [§15 Don't Say](#sec-15) — careful framings 16. [§16 Standards Specifics](#sec-16) — only if asked 17. [§17 Where Does The Field Go Next](#sec-17) 18. [§18 Closing Lines](#sec-18) 19. [§19 If You Read One](#sec-19) — for listeners after the show 20. [§20 References](#sec-20) — all linked posts and series --- ## §3. The Spine: TL;DR of the Power of Attorney series {#sec-3} The three-part series — *[You Don't Give Agents Credentials. You Grant Them Power of Attorney][s-poa]* — is the foundational argument. **This is the spine of the entire podcast.** Three beats: name the gap, introduce the missing primitive, build the control plane that governs it. If the conversation drifts, return here. ### The arc in one line > *Agents don't need your passport. They need your authority. And that authority has to be governed across the stay, not just verified at the entry.* --- ### Beat 1 — The Gap *(Part 1: [Agents Don't Need Your Passport][p-passport])* {#beat-1} > *At a glance: IAM has answered three questions for two decades. Agents introduce a fourth that has no first-class owner because humans were closing it implicitly through presence, pacing, and natural scope-limiting.* #### The foundational assumption > IAM systems governing enterprise access today were designed around a foundational assumption: **humans execute actions.** A person authenticates, crosses a boundary, acts, and stops. The security boundary and the execution boundary were the same thing because **presence and pacing enforced both.** **Agents remove those constraints.** They don't stop when the task ends. Credentials don't expire when purpose does. --- #### The four IAM domains (one without a first-class owner) | Domain | Question | Time scope | |---|---|---| | Identity | *Who is acting at this boundary?* | session start | | Access | *May this request proceed?* | request time | | Delegation | *What may this actor do on behalf of another?* | the handoff | | **Authority (Power of Attorney)** | ***May this actor continue to act, and how?*** | **spans execution** | > **Identity establishes who. Authority establishes whether and how an actor may continue.** The conceptual stack: - **Authority** is the conceptual domain. - **Mandate** is the concrete artifact that carries and enforces it. - **Power of Attorney** is the legal analogy that makes both legible. --- #### The human was the governance layer no control modeled For two decades, three implicit constraints did the work that no formal control had to: - **Presence** — a person at a keyboard who stops - **Pacing** — a session that ends when the laptop closes - **Natural scope-limiting** — when the meeting ends, the activity ends Sessions terminate because humans close their laptops. Behavioral baselines calibrate to human-paced patterns. Access reviews reflect what a person needs right now. **The controls held not because they were particularly sophisticated, but because the human brought presence, pacing, and natural scope-limiting that the controls never had to formally represent.** The gap is not new. Norm Hardy named the underlying capability-security problem (the *confused deputy*) in 1988. Park and Sandhu's UCON model named the ongoing-governance gap in 2004 and called it *continuity obligations*. The theory was right. **Deployment was never urgent because humans were closing the gap for free.** --- #### Why agents break the model Agents provide none of what humans provided: - **No closing-the-laptop signal** for a completed task. They don't stop when the mission ends. - **Behavioral baselines fail in both directions.** Either they generate constant noise from machine-paced volume, or they learn to ignore agent activity, removing the last behavioral fallback. - **Sub-agents inherit access implicitly and in full.** Human identity systems were never designed for principals that chain. - **Provisioning agents as humans** transfers entitlements without the presence, pacing, or accountability those controls were built around. --- #### The two anti-patterns the industry keeps repeating **Impersonation** *(the agent acts as the user)*: > Impersonation conflates identity with authority. The agent does not need to be the user. It needs a bounded mandate to act for the user, scoped to a specific purpose, revocable independently of the user's credentials, and traceable as a distinct principal in audit logs. **Credential vaulting / NHI / PAM** *(the agent's secrets are governed)*: > The credential carries no connection to the purpose that justified issuing it. PAM and NHI controls govern the credential. **Nothing governs the mission.** --- #### Agents are neither humans nor workloads Workload identity (SPIFFE-style) is a closed-world model that assumes you know every system the workload will call. Agents work in open worlds, given a destination rather than a track. > Workloads run on pre-defined tracks. Agents are taxis discovering routes in real time. The open-world paradox: - **Restrict the agent to pre-mapped resources** and it can't do the job it was built for. - **Give it broad credentials** to navigate freely, and exposure scales with every action it takes. Neither model fits. That's why both fail in production today. --- #### What existing controls capture vs what they miss | Control | What it captures | What it doesn't | |---|---|---| | Access tokens | access at a boundary | *why* execution was initiated, or when it should end | | Credential lifecycle | the credential clock (rotation, refresh) | the mission clock, which doesn't reset when credentials do | | JIT | a credential window | mission state. The window is a *proxy* for mission duration, not a *measure* of it | | CAEP | propagation of state changes | the authoritative source of mission state to emit from | --- #### Mission authority vs delegation authority The fourth domain has two orthogonal failure modes: | Failure mode | The question it answers | |---|---| | **Mission authority** | *Do the purpose and conditions that justified the original grant still hold?* | | **Delegation authority** | *Is the chain from the current agent to the originating human grant intact and unattenuated?* | **They fail independently.** A structurally valid delegation chain can carry a mission that has already lapsed. A valid mission can be served by a chain whose originating principal has changed. --- #### Three structural delegation gaps in the current stack These are delegation authority failures specifically: - **Scope amplifies without attenuation.** Every delegation hop is a potential amplification point. Token exchange's `act` claim is advisory, not enforced. - **Chains lack traceability.** There's no provable lineage back to a human grant. Audit logs reconstruct it after the fact, not before. - **Context isn't re-evaluated at each hop.** The conditions that justified the original delegation aren't checked downstream. These map to one missing capability: **provenance for authority** the way SLSA provides provenance for builds. Every delegation hop should attest to the authority it received and what it passed forward. --- #### The right question at each hop The question each hop should ask is **not** *what authority do I hold?* It is: ***Does the original purpose still justify extending this authority, to this actor, right now?*** Short-lived credentials and scoped permissions don't encode that question, let alone answer it. Each delegation decision should reflect current conditions, not those that existed when the original mandate was issued. --- #### Two case studies that show the gap manifest - **Code agent (ghost execution).** A CFO approves a research agent at 2:00 PM. The board concludes at 2:05. The agent's token is valid until 2:00 AM. Token valid. JIT granted. CAEP firing. Audit clean. **The mission ended at 2:05 PM and nothing in the stack can see it.** That's an agent executing with valid credentials in service of a mandate that has already expired. - **Procurement taxi (open-world failure).** An agent discovers a supplier portal that wasn't on the pre-approved list. Treat it as a workload and the agent fails the task. Treat it as a human and you grant broad credentials. Neither model lets you scope a one-time attenuated mandate to one resource for the duration of one call. --- #### Beat 1 soundbites > *A delegation chain with no traceable human grant is not governance. It is inherited trust.* > *Delegation without attenuation, traceability, and context re-evaluation is not governance. It is accidental trust propagation.* > *The gap is not in your controls. The gap is in what your controls were built to govern.* > *We've been building better passports, more precisely stamped. The agent ecosystem doesn't need a better passport. It needs a different artifact entirely.* --- ### Beat 2 — The Missing Primitive *(Part 2: [From Passports to Power of Attorney][p-poa])* {#beat-2} > *At a glance: When a person delegates a task to an agent, they aren't sharing identity. They're granting Power of Attorney. The artifact is the Execution Mandate.* #### Identity vs authority When a person delegates a task to an agent, they aren't sharing identity. They're granting Power of Attorney. The agent isn't the user. The agent is a delegate acting under bounded authority. | Question | Artifact | |---|---| | *Who is presenting this token?* | Credential | | *Under whose authority is this token being used, for what purpose, within what bounds?* | Mandate | Different questions. Different artifacts. --- #### Power of Attorney has four dimensions - **Purpose** — the why - **Scope** — bounded resources and conditions - **Time** — when it's valid - **Conditions** — what makes it valid You can grant medical PoA without financial. Limited financial without real estate. It's scoped to *why* someone may act, not just which actions are technically possible. **It's revocable independently of credentials.** You can also only grant authority you actually hold. A manager who has read access to HR records but doesn't own them can't grant modify authority to a delegate. That distinction (resource-owner consent vs delegating-principal intent) is structural to PoA and largely missing from OAuth. --- #### The artifact: the Execution Mandate A durable, governable authority object with five properties: | Property | What it carries | |---|---| | **Purpose** | Why this execution exists. The business or task reason. | | **Scope** | Bounded resources, audiences, allowed actions. | | **Conditions** | What makes the mandate valid. Risk thresholds, environment, budget. | | **Lifecycle** | Start, end, suspension, termination. Independent of token expiry. | | **Provenance** | Chain of delegation back to a human grant. Cryptographically attestable. | **Critical:** the mandate must be cryptographically bound to the tokens it governs. Otherwise, advisory mandates devolve into audit logs that nobody enforces. --- #### Two failure modes the mandate makes visible | Failure | Example | Today's IAM | |---|---|---| | **Conflicted reviewer** | A reviewer assignment is created mid-flight, after the agent has already accessed material under a now-conflicted purpose | Not an IAM event. Nothing in the stack can see it. | | **Delegated approver** | The General Counsel recuses from a matter and delegates approval to outside counsel; the chain back to the user shifts under the agent's feet | Not an IAM event. | A mandate object surfaces both as first-class lifecycle events. --- #### Format options The format is secondary. The object model is what matters. - **Signed JWT** — broad enterprise tooling, online attenuation, easiest starting point - **Macaroons** — HMAC-chained caveats, structural attenuation, weaker auditability - **Biscuit** — Datalog-based conditions, expressive, smaller ecosystem --- #### Why this isn't just OAuth scopes plus expiration | OAuth scopes + expiration | Execution Mandate | |---|---| | Flat permission labels | Structured purpose with provenance | | Time window | Lifecycle state machine | | Don't survive delegation | Carry through hops with attenuation | | Revocation acts on tokens | Termination acts on the mission | | Captures *what* is allowed | Captures *why* it is authorized | #### Beat 2 soundbite > *A passport lets you cross a border. A Power of Attorney lets you act after crossing it.* --- ### Beat 3 — The Control Plane *(Part 3: [Governing the Stay, Not Just the Entry][p-stay])* {#beat-3} > *At a glance: A mandate checked only at issuance is a declaration, not a mandate. The agent has to be governable across the entire stay through a Mission Authority Service.* #### Defining the artifact isn't enough A mandate checked only at issuance is a declaration, not a mandate. The agent has to be governable across the entire stay, not just at the entry. That requires four things: - **Mission Authority Service (MAS)** — owns mandate state as a first-class artifact - **Continuous authority evaluation** — asks whether execution should still continue - **Cross-domain propagation** — when the agent crosses a trust boundary - **Runtime enforcement** — pause, unwind, or terminate when the business reason ends --- #### Continuous authority evaluation, in practice Synchronous round-trip on every API call doesn't scale. The pattern is hybrid: - **Synchronous checks** for high-value or irreversible actions (the *commit boundaries*) - **Signal-driven termination** (CAEP-style) for high-volume calls where the mission can declaratively end Reversibility is declared at mandate issuance, not inferred by the orchestrator at runtime. **Saga pattern for unwinding.** When a mandate ends mid-execution, the orchestrator runs compensating actions to reverse partial work, the way distributed transactions handle aborts. **Cascade revocation.** When the parent mandate ends, derived sub-agent authority terminates regardless of whether any individual credential remains valid. This is what makes provenance load-bearing. Without an attestable delegation chain, there's nothing to cascade through. --- #### Where MAS doesn't belong | Wrong home | Why | |---|---| | **Orchestrator** | Authority dies with the runtime: no cross-session, no cross-domain, no IAM or audit visibility. | | **Authorization Server** | Overloads it with durable authority ledger, lifecycle state machine, approval evidence, delegation graph, and policy compilation. None of which the AS was built for. | | **PDP** | Reconstructed context at decision time is not a first-class authority record. | The cleaner end state is a separate state owner the rest of the stack composes around. --- #### The existing stack composes around it | Component | Role | |---|---| | SPIFFE | software identity | | PAM | credential governor | | PDP | request-time decision | | CAEP | propagation rail | | IGA | provenance / review | | **MAS** | **the missing state owner** | > *Mission is the authority clock. PAM is the credential governor. Different roles. Different services.* > *Mission is what the existing stack has been simulating from credentials, tokens, and audit logs. It's the thing agents have made it impossible to keep simulating.* --- #### Three authority questions the MAS owns - **Who issues the mandate?** The originating human grant or its authorized delegate. - **Who owns ongoing state?** The MAS, not the AS, not the orchestrator. - **Who can revoke?** The mandate issuer, business event triggers, or risk signals, independent of the credential layer. > *A mandate that does not specify its failure semantics is not a governance layer.* --- ### The spine, in three sentences > **Agents don't need your passport.** > **They need your authority.** > **And that authority has to be governed across the stay, not just verified at the entry.** ### Tight versions for mid-conversation **One-breath reframe:** > Identity, access, and delegation each correctly answer their own question. None of them ask whether the mission behind a request should still be running. That fourth question, authority, has no first-class occupant in the IAM stack. Humans were closing it implicitly through presence, pacing, and natural scope-limiting. Agents remove all three. **The zinger** *(if Chris asks "what is the industry getting wrong")*: > The IAM stack has no durable, independently revocable authority object for delegated machine missions. We've been simulating it from credentials, tokens, and audit logs. Agents make that simulation visibly fail. --- ## §4. Macro Frame: Four Series, Four Layers {#sec-4} There are four series on the blog, and together they're one argument structured as four layers of an architecture. | Layer | Series | What it covers | |---|---|---| | **Authority governance** | *[Power of Attorney][s-poa]* | The missing layer in IAM. Names the gap, proposes the Execution Mandate. | | **Semantic translation** | *[Mission Shaping][s-shaping]* | The hardest unsolved problem: turning approved intent into bounded authority. Most deployments skip it. | | **Protocol** | *[Mission-Bound OAuth][s-mboauth]* | What the answer looks like inside OAuth. Ends with the series turning against itself. | | **Substrate** | *[Open-World OAuth][s-owo]* | The protocol primitives that have to work before any of the higher layers matter. | The four series form a stack. The headline: stronger credentials, tighter scopes, faster JIT don't close the gap because they're answering a request-scoped question. The gap is mission-scoped. --- ## §5. The 60-Second Arc {#sec-5} If Chris asks an open-ended question and you want to lay out the full architecture quickly: > The way I think about it is four layers. > > Underneath everything is **the protocol substrate**. OAuth was built for a closed world. Agents push it into an open one, where they discover resources at runtime. Substrate work is fixing that. > > Above the substrate is the **protocol-layer attempt** at agent governance. Mission-Bound OAuth, AAuth, AgentPass. Each tries to bind a token to a purpose and a lifecycle. They're meaningful progress. They're transports. > > Above that is the **semantic translation** layer: turning approved human intent into a bounded, machine-evaluable authority object. That's mission shaping, and it's the hardest unsolved problem. Most deployments skip it. > > And above all of that is the **authority governance** layer. The Execution Mandate. The Mission. The thing that owns the answer to *should this still be running.* That's the layer the IAM stack doesn't have a first-class occupant for. Not because the stack failed. Because humans were closing that gap implicitly through presence, pacing, and natural scope-limiting, and agents removed all three. > > Stronger credentials, tighter scopes, faster JIT, fine-grained PDPs, CAEP. They're all valuable. They all answer the same kind of question: *is this request permitted right now.* The agent question is different. *Should this mission still be running at all.* Composing request-scoped controls cannot produce a mission-scoped control. That's not a tuning failure. It's a category failure. --- ## §6. Zero Trust: The Deeper Reframe {#sec-6} **Use this if Chris brings up Zero Trust. Likely he will. Reframe the audience's mental model rather than introducing a new one.** ### The deeper break > The deeper break is not just that agents are non-human. It's that **identity is no longer a sufficient proxy for authority.** > Context tells you *what is happening*. Authority tells you *what is permitted*. ### The questions shift Zero Trust worked when identity, device, session, and network context approximated expected behavior. With agents, a valid identity can produce an invalid action. | ZT for humans | ZT for agents | |---|---| | Who is this? | Under whose authority is this agent acting? | | Is the device healthy? | What was approved? | | Does this session look normal? | What are the delegation bounds? | | | What is the lineage across sub-agents and tools? | | | Is that authority still valid right before the action becomes real? | Identity is still necessary. It is no longer enough. > **Zero Trust for humans centered on identity. Zero Trust for agents has to center on delegated authority.** **Line to land:** *Context tells you what is happening. Authority tells you what is permitted.* --- ## §7. Top 10 Thought Leadership Points (steer toward these) {#sec-7} These are the points only you are making clearly enough to claim. If Chris gives you an open question, push toward one of these. ### Quick lookup | # | Claim | Best when Chris says... | |---|---|---| | [1](#tlp-1) | Structural gap, humans were closing it | "core problem agents expose" | | [2](#tlp-2) | Four IAM questions, not three | "what's missing from IAM" | | [3](#tlp-3) | ZT for agents = delegated authority | "Zero Trust" | | [4](#tlp-4) | Category failure, not tuning failure | "we already have IGA / PAM / JIT" | | [5](#tlp-5) | Agents need authority, not identity | "what's the alternative to vaulting credentials" | | [6](#tlp-6) | Mandate at issuance only is a declaration | "revocation, lifecycle, CAEP" | | [7](#tlp-7) | Mission Shaping is the unsolved problem | "where does the field need work" | | [8](#tlp-8) | Survivable incorrectness, not perfection | "how do we make this safe" | | [9](#tlp-9) | Mission right object, MBOAuth wrong home | "your IETF work, AAuth, standards" | | [10](#tlp-10) | OAuth islands, application adjacency | "recent breaches, RFPs" | Each point below has the deeper framing, a concrete example, the soundbite, the natural follow-up move, and the response if Chris pushes back. --- ### #1. The structural gap was always there. Agents made it visible. {#tlp-1} For two decades, three things were doing implicit governance work that no formal control modeled. **Presence:** a person at a keyboard, then stops. **Pacing:** a session has a natural rhythm and ends with closing the laptop. **Natural scope-limiting:** when the meeting ends, the activity ends. The IAM stack assumed all three. Park and Sandhu's UCON model named this missing layer in 2004 ("continuity obligations"). The theory was right then. Deployment was never urgent because humans were closing it for free. **Make it concrete:** A CFO approves a research agent at 2:00 PM to pull pre-IPO financials. The board concludes the topic at 2:05. The agent's token is valid until 2:00 AM. Token: valid. JIT: granted least privilege. CAEP: firing as designed. Audit log: clean. The agent polls for twelve hours. The breach is structurally invisible because no layer in the stack was built to ask whether the mission behind the request should still be running. **Land it:** *"The gap was invisible because humans were closing it."* **Take it next:** Pivot to the four-question model ([#2](#tlp-2)). The structural gap is vague until you name what's missing. **If pushed back ("but humans also caused breaches"):** Yes. Humans caused *targeted* breaches inside an envelope humans were defining. The gap that matters now is *structural invisibility at machine speed*. Different problem class. **Source:** *[Agents Don't Need Your Passport. They Need Your Authority][p-passport]* --- ### #2. There are four IAM questions, not three. Authority is the missing fourth. {#tlp-2} For two decades the stack has answered three questions cleanly. *Who is acting* (identity, owned by AuthN). *What are they allowed to do* (access, owned by PDPs). *Who delegated the rights* (delegation, owned by token exchange). Agents introduce a fourth: *should this execution still be running at all.* This question has no first-class occupant. **Make it concrete:** Identity is evaluated at session start. Access is evaluated at request time. Delegation is evaluated at the handoff. None of those time scopes match an agent's lifecycle. An agent survives across token refreshes, sub-agent delegation, and trust boundary crossings. The fourth question requires a component built for that lifetime, and there isn't one. **Land it:** *"Identity, access, and delegation each correctly answer their own question. None of them ask whether the mission behind a request should still be running."* **Take it next:** Either go to category failure ([#4](#tlp-4)) or to architectural placement ([#9](#tlp-9)). **If pushed back ("CAEP solves this"):** CAEP is a propagation rail. It needs an authoritative source of mission state to emit from. Continuous *access* evaluation is not continuous *authority* evaluation. **Source:** *[Agents Don't Need Your Passport][p-passport]* --- ### #3. Zero Trust for humans centered on identity. Zero Trust for agents has to center on delegated authority. {#tlp-3} Zero Trust worked when identity, device, session, and network context were good-enough proxies for *what is this person trying to do*. The implicit assumption was that a known identity, on a healthy device, in a normal-looking session, taking an action, was probably aligned with what the user intended. That assumption holds for humans. It breaks for agents. **Make it concrete:** The questions Zero Trust was built to answer no longer carry the load. *Who is this? Is the device healthy? Does this session look normal?* For agents, the questions become: *Under whose authority is this agent acting? What was approved? What are the delegation bounds? What is the lineage across sub-agents and tools? Is that authority still valid right before the action becomes real?* **Land it:** *"Context tells you what is happening. Authority tells you what is permitted."* **Take it next:** Bridge to the missing primitive ([#5](#tlp-5)). **If pushed back ("Zero Trust isn't dead, just extended"):** Agreed. I'm not killing it. I'm naming what it doesn't carry. ZT for humans was right. ZT for agents has to extend the model to delegated authority as a first-class signal. --- ### #4. Composing request-scoped controls cannot produce a mission-scoped control. That's a category failure. {#tlp-4} The instinct when something doesn't work is to layer more controls. The IAM stack has been doing that for a decade. JIT narrows credential lifetime. RAR captures purpose at issuance. Short-lived tokens reduce blast radius. Fine-grained PDPs resolve whether an action may happen. CAEP propagates state changes. PAM governs credential vaulting. Each one is correct for what it does. None of them, alone or composed, produces a mission-state owner. **Make it concrete:** A scheduled credential rotation fires at 3 AM. The agent now holds fresh, valid credentials for a mission that was cancelled at 2 PM. JIT didn't catch it because JIT's window is a proxy for mission duration, not a measure of it. RAR didn't catch it because RAR captured purpose at issuance, not in flight. CAEP didn't catch it because no upstream system told CAEP the mission ended. Every layer worked correctly. The stack still failed. **Land it:** *"It's not a tuning failure. It's a category failure."* **Take it next:** Move to the missing primitive ([#5](#tlp-5)). **If pushed back ("but JIT/PAM/CAEP help, you're being unfair"):** Agreed. They reduce blast radius, which is real value. But blast radius reduction is not authority governance. **Source:** *[Agents Don't Need Your Passport][p-passport]* --- ### #5. Agents don't need your identity. They need your authority. {#tlp-5} When a person delegates a task to an agent, they aren't sharing identity. They're granting Power of Attorney. The agent isn't the user. The agent is a delegate acting under bounded authority. PoA has four dimensions: purpose, scope, time, conditions. It's scoped to *why* someone may act, not just which actions are technically possible. **Make it concrete:** The Execution Mandate carries five things: purpose (the why), scope (bounded resources and conditions), lifecycle (start, end, suspension, termination semantics), conditions (what makes it valid), and provenance (chain back to a human grant). It's revocable independently of any token. It survives across token refreshes. It can be terminated when the business reason ends, regardless of how many credentials are still technically valid. **Land it:** *"Zero Trust is the badge. Power of Attorney is the work order. The badge stays valid after the work order is closed."* **Take it next:** Deepen with [#6](#tlp-6) (mandate-at-issuance is a declaration) or [#9](#tlp-9) (where Mission lives). **If pushed back ("isn't this just OAuth scopes plus expiration?"):** Scopes are flat permission labels with no purpose, no provenance, no lifecycle beyond expiration. PoA is the structured combination of all four. **Source:** *[From Passports to Power of Attorney][p-poa]* --- ### #6. A mandate that is checked only at issuance is not a mandate. It is a declaration. {#tlp-6} Most enforcement in the IAM stack happens at the boundary, at request time. That worked when sessions were short and humans were watching. Agents run long after the boundary. They survive across token refreshes, across sub-agent delegations, across trust boundary crossings. Without continuous authority evaluation, you get ghost execution. **Make it concrete:** Continuous authority evaluation isn't synchronous round-trip at every API call. It's hybrid: synchronous checks for high-value or irreversible actions (the commit boundaries), and signal-driven termination (CAEP-style) for high-volume calls where the mission can declaratively end. The MAS emits the signal. The existing infrastructure consumes it. **Land it:** *"A board meeting conclusion is not a system event."* **Take it next:** Use this to set up the architectural question ([#9](#tlp-9)). **If pushed back ("that's just CAEP"):** CAEP is the rail. Mandate state is the cargo. CAEP needs an authoritative source emitting "the mission ended." **Source:** *[Governing the Stay, Not Just the Entry][p-stay]* --- ### #7. Mission Shaping is the hardest unsolved problem in agentic IAM. Most deployments skip it. {#tlp-7} A user approves an objective: "pull the customer escalation history, draft a response, and send it to me before anything goes out." That's intent. Something has to compile that intent into something a control plane can evaluate. Most current deployments skip the compilation step. The agent gets a broad token, infers its own boundaries from the prompt, and the system trusts it to stay inside them. **Make it concrete:** The closest historical precedent is Internet Explorer's Trusted Sites zones. Browsers were the first mainstream open-world agents. Zone classification was the shaping step. It was always the weak point. Everything ended up in Trusted Sites. The agent ecosystem is rerunning that experiment, with prompt injection in the role of malicious sites. **Land it:** *"That is not governance. That is optimism."* **Take it next:** Move to the dual-layer architecture ([#8](#tlp-8)). **If pushed back ("AI alignment / RLHF handles this"):** Constitutional alignment shapes the model's behavior. Mission shaping shapes the *authority envelope* the model is allowed to act within. Different layers. **Source:** *[The Mission Shaping Problem][p-shaping-problem]* --- ### #8. Survivable incorrectness, not semantic perfection. Containment is co-equal with shaping. {#tlp-8} Even a perfectly shaped Mission can fail. Quiet scope expansion. Multi-agent delegation. Headless execution. Stale state. Open-world runtime redirection. Perfect fidelity isn't achievable at agent scale. The right design principle is a system that stays governable when the model is partial or wrong. **Make it concrete:** Containment is the operational resilience layer. Narrow tool discovery envelopes. Strong tool mediation through trusted adapters. Short-lived attenuated credentials. Boundary observation that doesn't rely on agent self-report. Irreversible-action gates. The threat is *authorized misuse by the agent itself*, with valid credentials, in service of injected or misaligned intent. The attack surface is the context window, not network ingress. **Land it:** *"Perfect semantic fidelity is not achievable at the scale and openness of real agent deployments. Survivable failure is."* **Take it next:** Land an honest deployment guidance: for some task classes, containment-first is the right architecture today. For others, *don't run it agentically yet.* **If pushed back ("this sounds like security theater on top of authorization"):** Mission shaping is the policy layer. Containment is the operational layer. Security theater is doing one and calling the system safe. **Source:** *[Mission Shaping Is Not Enough][p-shaping-not-enough]* --- ### #9. The Mission is the right object even if Mission-Bound OAuth is the wrong home. {#tlp-9} I've published the protocol-layer answer. I've also published the argument against it. The Mission is directionally right. Putting it inside the AS may not be. The AS becomes a durable authority ledger, lifecycle state machine, approval evidence store, delegation graph authority, policy compilation checkpoint, runtime governance anchor, all at once. The cleaner end state is a separate **Mission Authority Service** the rest of the stack composes around. **Make it concrete:** The MAS owns approval evidence, lifecycle policy, delegation graphs, and the compiled authority model. The AS issues tokens consistent with MAS state. Gateways and PDPs enforce. Runtime executes. SPIFFE handles software identity. PAM handles credentials. PDPs decide. CAEP propagates. IGA reviews. Mission is the missing state owner. **Land it:** *"Mission has to live somewhere as a durable control-plane object, or the rest of the stack is only simulating authority governance."* **Take it next:** This is the natural place to talk about IETF work, AAuth, AgentPass, MCP. **If pushed back ("vendors will never agree on a separate MAS"):** They don't have to from a clean sheet. The pattern emerges incrementally. AgentPass already has an `Authority` entity. AAuth has a Mission concept now. The convergence is happening. **Source:** *[Why Mission-Bound OAuth Might Be the Wrong Answer][p-wrong-answer]*, *[AAuth Now Has a Mission Layer][p-aauth-mission]*, *[AgentPass and the Missing Mission Layer][p-agentpass]* --- ### #10. Application adjacency is the new lateral movement. The market doesn't need better-run OAuth islands. {#tlp-10} Every new SaaS integration creates an OAuth island: an app-specific system for long-lived delegated access, with its own client, credential, grant, renewal, and governance lifecycle. Each island is independently sane. The aggregate is **authorization bankruptcy**: more long-lived delegated access than the enterprise can inventory, review, rotate, or revoke before the next wave is in production. **Make it concrete:** Vercel April 2026: three hops through already-granted application access. No firewall bypass. Gainsight: 285 tokens, some dating to October 2017, eight years of exposure. Nudge data on a typical 1,000-person org: 16 OAuth grants per employee, four of them carrying data-sharing permissions. The fix is OAuth federation: issuer-signed assertion in, local access token out. RFC 7523 is mature today. **Land it:** *"Enterprises think they centralized trust when they bought SSO. They centralized login. Long-lived delegated access kept proliferating underneath it."* **Take it next:** Make this the actionable CISO close. Specific RFP language and vendor security review questions. **If pushed back ("but each vendor handles tokens responsibly"):** The issue isn't whether each vendor runs their island well. It's whether the island has to exist at all. **Source:** *[Enterprise SaaS Needs OAuth Federation Now][p-federation]* --- ## §8. Talk Tracks per Series (deep references) {#sec-8} Each series has a spoken-language track. Consistent structure: **use when** trigger at top, three or four sub-beats, line to land at the bottom. --- ### §8.1 Series 1 — *[You Don't Give Agents Credentials. You Grant Them Power of Attorney.][s-poa]* {#tt-poa} **Use when:** Chris asks about the structural gap, the foundational frame, or "what's the core problem agents expose." #### The opening scene A CFO approves a research agent at 2:00 PM. The board concludes at 2:05. Token valid until 2:00 AM. The agent polls for twelve hours. Every control green. **The mission ended at 2:05 PM and nothing in the stack can see it.** That's *ghost execution*, and the breach is structurally invisible. #### Beat A — The fourth question IAM has been answering three questions for two decades. *Who* (identity), *what* (access), *who delegated* (delegation). Agents introduce a fourth: *should this execution still be running at all.* No first-class occupant in the stack. Humans were closing the gap implicitly through presence, pacing, and natural scope-limiting. Agents remove all three. #### Beat B — The Execution Mandate If credentials don't carry mission authority, what should? The Execution Mandate: a governed object with purpose, scope, conditions, lifecycle, and provenance back to a human grant. Power of Attorney is the analogy. PoA is scoped to *why* someone may act, not just which actions are technically possible. #### Beat C — The control plane Defining the artifact isn't enough. *A mandate that is checked only at issuance is not a mandate. It is a declaration.* The agent has to be governable across the stay: continuous authority evaluation, cross-domain propagation, runtime enforcement that can pause, unwind, or terminate. **Line to land:** *Zero Trust is the badge. Power of Attorney is the work order. The badge stays valid after the work order is closed.* **Posts in this series:** - [Agents Don't Need Your Passport. They Need Your Authority][p-passport] - [From Passports to Power of Attorney][p-poa] - [Governing the Stay, Not Just the Entry][p-stay] --- ### §8.2 Series 2 — *[Mission-Bound OAuth][s-mboauth]* {#tt-mboauth} **Use when:** Chris asks about protocol-layer solutions, OAuth, your standards work, or AAuth. #### The frame The Power of Attorney series defines *what* the missing layer is. The Mission-Bound OAuth series asks *what does that look like if you have to build it inside OAuth.* #### Beat A — The architecture The Mission becomes a durable authority object at the AS, bounded by purpose, governed across its lifecycle, revocable by business event, and enforced across every token derived from it. **OAuth answers whether a request is permitted right now. Mission-Bound OAuth asks whether the delegation should still be running at all.** #### Beat B — The authentication-layer companion A Mission needs a starting point. When a user is present, authentication is the moment to capture purpose. OIDC Client Context for the bootstrap. ID-JAG (the IETF spec I'm a co-author on) for projecting a reduced Mission view across downstream authorization domains. Authentication handles bootstrap. The Mission stays at the AS. #### Beat C — Does it survive a protocol change AAuth is Dick Hardt's draft for an agent-native authorization protocol. Question: does the cleaner protocol shape eliminate the need for a Mission-like object, or just become a better substrate for the same model? Answer: the second one. The framing is **Mission governance on OAuth** vs **Mission governance on AAuth**. #### Beat D — The series turned against itself Mission-Bound OAuth might be putting the right object in the wrong place. The AS becomes a governance engine, lifecycle controller, and mission ledger all at once. The cleaner end state is a separate Mission Authority Service that OAuth consumes, not the other way around. **The Mission is the right object even if Mission-Bound OAuth is the wrong home.** **Line to land:** *A token answers "is this request permitted right now." A Mission answers "should this delegated mission be running at all." Composing a hundred request-scoped controls does not produce a mission-scoped control.* **Posts in this series:** - [Mission-Bound OAuth (architecture)][p-mboauth] - [Client Context and ID-JAG for Mission-Bound OAuth][p-client-context] - [Mapping Mission Architecture to AAuth][p-aauth-map] - [Why Mission-Bound OAuth Might Be the Wrong Answer][p-wrong-answer] --- ### §8.3 Series 3 — *[Mission Shaping][s-shaping]* {#tt-shaping} **Use when:** Chris asks "where does the field most need work," "what's the hard part standards bodies aren't solving," or "how do we make this safe." #### The setup A manager tells an agent, "pull the customer escalation history, draft a response, and send it to me." That's intent. Something has to turn that intent into something a control plane can evaluate. In most current deployments, that step is implicit, local, or delegated to the agent itself. **That is not governance. That is optimism.** #### Beat A — The shaping problem Approved intent is not authority. The system has to compile ambiguous human intent into a bounded, governable artifact. Most deployments skip the compilation step. Closest historical precedent: IE Trusted Sites zones. Browsers were the first mainstream open-world agents. Zone classification was the shaping step. It was always the weak point. Everything ended up in Trusted Sites. #### Beat B — Shaping is not enough Even a perfectly shaped Mission can fail. Quiet scope expansion. Multi-agent delegation. Headless execution. Stale state. Open-world runtime redirection. **Containment is not a fallback. It is the co-equal operational resilience layer.** In some real deployments, it's the more important one. #### Beat C — The design principle The right principle is **survivable incorrectness**. Not a system that's always semantically correct, but a system that stays governable when the semantic model is partial or wrong. Perfect fidelity is not achievable at agent scale and openness. Survivable failure is. **Line to land:** *You can have a perfectly specified deployment with a mission_ref on every token, lifecycle management at the AS, verified actor continuity across every hop, and still have no idea whether the agent is operating within the bounds the user actually intended.* **Posts in this series:** - [The Mission Shaping Problem][p-shaping-problem] - [Mission Shaping Is Not Enough][p-shaping-not-enough] --- ### §8.4 Series 4 — *[Open-World OAuth][s-owo]* {#tt-owo} **Use when:** Chris asks about OAuth, MCP, agent protocols, your IETF drafts, or "what's broken at the substrate level." #### The frame The fourth series is the floor. None of the higher-layer governance work matters if the protocol substrate doesn't function for agents. #### Beat A — Why closed-world OAuth was a feature OAuth became the default language of API authorization because it worked well in a closed world. The client knew the AS. The RS knew which issuers it trusted. **Closed-world OAuth was a feature, not a flaw. It's why OAuth succeeded.** #### Beat B — Agents invert the assumption Agents discover tools and protected APIs as they go. They encounter ASes and RSes that were not wired into the client at deployment time. They turn one user task into a chain of runtime decisions across systems that may not share prior trust. #### Beat C — The substrate gaps Progress: Protected Resource Metadata in RFC 9728 lets agents learn from a 401 challenge. Client ID Metadata Document anchors client identity in DNS without pre-registration. Two of the remaining gaps I'm fixing personally. PRM today requires exact URL match (breaks APIs protecting multiple paths under one policy). And there's no mechanism for the AS to confirm which `resource` binding it actually honored. *Discovery finds the resource. The token request declares it. The token response should confirm it.* #### Beat D — Even with substrate fixed, you still need Mission Agent authorization only works when both layers hold. Fix the substrate, and you still need a Mission layer above it. Build a Mission layer, and it doesn't matter if the substrate can't tell the agent which resource it just discovered. **Resource semantics are not Mission semantics.** **Line to land:** *Closed-world OAuth was a feature, not a flaw. Agents make it operationally bankrupt. The market doesn't need better-run OAuth islands. It needs vendors to stop building them.* **Posts in this series:** - [OAuth for Open-World Ecosystems][p-owo-1] - [Open-World OAuth Still Needs Mission Shaping][p-owo-2] --- ## §9. Pushback Quick-Fire {#sec-9} When Chris pushes back, hit back tight. Each response is one or two sentences max. ### Zero Trust **"Doesn't Zero Trust handle this? We have continuous evaluation, device health, session signals."** > Zero Trust worked when identity, device, session, and network context approximated expected behavior. With agents, a valid identity can produce an invalid action. Identity is necessary; it's no longer enough. ZT for humans centered on identity. ZT for agents has to center on delegated authority. ### IGA / PAM / JIT / NHI **"Doesn't IGA + PAM + JIT solve this?"** > They reduce blast radius, which is real value. They don't answer the mission question. JIT issues a credential window. A mission issues a governed purpose. Composing request-scoped controls can't produce a mission-scoped one. **"Isn't this just NHI? We have vendors for that."** > NHI vendors govern credentials. Credentials are not the problem. The credential carries no connection to the purpose that justified issuing it. What the agent holds is not the gap; the gap is that nothing in the stack owns mission state. ### CAEP / Continuous Evaluation **"What about CAEP and continuous authorization?"** > CAEP is a propagation rail. It needs an authoritative source of mission state to emit from. Continuous *access* evaluation is not continuous *authority* evaluation. The mission layer is what's missing upstream of CAEP, not downstream. ### Approval / HITL **"Can't we just put a human in the loop for every action?"** > At machine speed, that creates approval fatigue. Approval fatigue produces rubber-stamping. Rubber-stamping produces broader grants. Broader grants reintroduce standing access. The intent was to constrain; the operational outcome is the opposite. ### Audit / Logs **"Audit logs prove governance."** > Provenance is post-hoc reconstruction. Attenuation is pre-execution containment. Logs tell you how the chain expanded; they don't stop the chain from expanding. Transparency is not the same as containment. ### Scopes **"OAuth scopes plus tighter scoping is enough."** > Scopes are flat permission labels at a point in time. They have no lifecycle, no purpose binding, and no provenance. Stacking more scopes doesn't make them PoA. ### Standards / Protocols **"AAuth or AgentPass already solves this."** > Meaningful progress. Each has a notion of an authority object now. But mission-as-prose is not mission-as-authority-model. Approved-tool lists are permission sets, not bounded authority envelopes. Correlation interop is here. Enforcement interop isn't. **"Vendors will never agree on a separate Mission Authority Service."** > They don't have to from a clean sheet. The pattern is emerging incrementally. AgentPass has an `Authority` entity. AAuth has a Mission concept. Mission-Bound OAuth has the AS holding it temporarily. Convergence is happening. ### AI Alignment **"AI alignment / RLHF handles this."** > Constitutional alignment shapes the model's behavior. Mission shaping shapes the *authority envelope* the model is allowed to act within. Different layers. Alignment is necessary. It isn't sufficient when the agent has live credentials. ### Vendor / Market **"Each vendor handles tokens responsibly."** > The issue isn't whether each vendor runs their island well. It's whether the island has to exist at all. The market doesn't need better-run islands. It needs vendors to stop building them. ### Skepticism **"This sounds like security theater on top of authorization."** > The opposite. Mission shaping is the policy layer. Containment is the operational layer. Security theater is doing one and calling the system safe. The argument is you need both, and most deployments are doing neither. **"But humans also caused breaches."** > Yes. Humans caused *targeted* breaches inside an envelope humans were defining. The gap that matters now is *structural invisibility at machine speed*. Different problem class. --- ## §10. Soundbite Library {#sec-10} Pick what feels natural in the moment. ### Foundational - *"When an agent acts on your behalf, it does not need your identity. It needs your authority."* - *"Identity establishes who. Not why."* - *"The gap was invisible because humans were closing it."* - *"Agents don't need your passport. They need your authority."* - *"The gap is not in your controls. The gap is in what your controls were built to govern."* ### Zero Trust reframe - *"Zero Trust for humans centered on identity. Zero Trust for agents has to center on delegated authority."* - *"Context tells you what is happening. Authority tells you what is permitted."* - *"Identity is still necessary. It is no longer enough."* - *"Zero Trust is the badge. Power of Attorney is the work order."* ### Category failure - *"It's not a tuning failure. It's a category failure."* - *"Composing components that each answer 'is this request currently permitted?' does not produce a component that can answer 'should this execution still be running?'"* - *"A time window is a proxy for mission duration, not a measure of it."* ### Mandate / Power of Attorney - *"A mandate that is checked only at issuance is not a mandate. It is a declaration."* - *"An agent that can rewrite its own mandate has no mandate at all."* - *"A board meeting conclusion is not a system event."* - *"A passport lets you cross a border. A Power of Attorney lets you act after crossing it."* - *"A delegation chain with no traceable human grant is not governance. It is inherited trust."* ### Mission Shaping - *"That is not governance. That is optimism."* - *"Approved intent is not authority."* - *"Perfect semantic fidelity is not achievable at the scale and openness of real agent deployments. Survivable failure is."* - *"Containment is not a fallback. It is the co-equal operational resilience layer."* ### MAS / architecture - *"Mission has to live somewhere as a durable control-plane object, or the rest of the stack is only simulating authority governance."* - *"Mission is the authority clock. PAM is the credential governor."* ### CISO / OAuth islands - *"Enterprises think they centralized trust when they bought SSO. They centralized login while long-lived delegated access kept proliferating underneath it."* - *"Agents do not simply make the old model noisier. They make it operationally bankrupt."* - *"Federate the grant, keep the token local."* --- ## §11. Connective Tissue (transitions) {#sec-11} Use when Chris pivots and you need a bridge sentence. **Zero Trust → architecture:** > "Once you accept that identity is no longer a sufficient proxy for authority, the next question is what *does* carry authority. That's where the four series come in." **PoA → Mission-Bound OAuth:** > "Once you accept there's a missing layer, the next question is where it lives. The first place I tried to put it was OAuth." **Mission-Bound OAuth → Mission Shaping:** > "Even if you nail the protocol layer, there's a harder problem upstream of it. Approved intent is not authority. That's Mission Shaping, and most deployments skip it." **Mission Shaping → Open-World OAuth:** > "And the substrate has its own problems. The protocol layer assumed a closed world. Agents broke that assumption." **Closing the loop back to PoA:** > "Agent authorization only works when all four layers hold. Substrate, protocol, semantic translation, governance. The piece the industry is least focused on is the top one. That's the layer humans were closing implicitly." --- ## §12. Key Analogies {#sec-12} Use whichever lands. - **Passport vs Power of Attorney.** Passport gets you across the border. PoA governs what you do after crossing it. - **Badge vs work order.** Zero Trust is the badge. The badge stays valid after the work order is closed. - **Train vs taxi.** Workloads run on pre-defined tracks. Agents are taxis discovering routes in real time. - **Closing the laptop.** Humans naturally end sessions. Agents have no equivalent signal. - **Application adjacency.** The new lateral movement primitive. Once standing OAuth grants exist across apps, lateral movement is an authorization problem, not a network problem. - **OAuth islands.** Every SaaS integration becomes its own app-specific system for long-lived delegated access. - **SLSA for authority.** What SLSA is for build provenance, the mandate is for authority provenance. --- ## §13. CISO Takeaways (the "what do I do Monday" answer) {#sec-13} If Chris pushes for actionable guidance: 1. **Stop buying better-run OAuth islands.** Make OAuth federation an RFP requirement. *"Issuer-signed assertion in, local access token out."* For workloads, RFC 7523 is mature today. See *[Enterprise SaaS Needs OAuth Federation Now][p-federation]*. 2. **Inventory long-lived delegated grants like standing privileged access.** Vercel, Gainsight, GitHub Heroku/Travis: three hops through already-granted application access. Application adjacency is the new lateral movement. 3. **For agentic deployments, separate three controls explicitly.** Identity (who), access (may this proceed), authority (should this still be running). Most stacks today only have the first two. 4. **Ask vendors where the mission state lives.** "In the orchestrator" → authority dies with the runtime. "In the token" → conflating projection with the governed object. --- ## §14. One-Liners by Listener Persona {#sec-14} - **CISO:** *"You bought SSO and thought you centralized trust. You centralized login. Long-lived delegated access kept proliferating underneath it."* - **Zero Trust practitioner:** *"Zero Trust for humans centered on identity. Zero Trust for agents has to center on delegated authority."* - **Architect:** *"Don't standardize protocol projections before the authority record is stable. AAuth, OAuth, AgentPass, those are transports. Mission is what they project."* - **Standards watcher:** *"Mission correlation is interoperable today. Mission meaning is the next standardization target, and it's harder than it looks."* - **Practitioner:** *"You can have a perfectly specified deployment with a mission_ref on every token, and still have no idea whether the agent is operating within the bounds the user actually intended."* --- ## §15. Don't Say / Careful Framings {#sec-15} - Don't pitch "Mission-Bound OAuth" as the answer. Frame Mission as the *object*; OAuth, AAuth, and AgentPass as *projections of it*. See *[Why Mission-Bound OAuth Might Be the Wrong Answer][p-wrong-answer]*. - Don't say "Mission lives in the AS." Overloads the AS with governance responsibilities it shouldn't carry. - Don't claim semantic perfection is the goal. The principle is **survivable incorrectness**. Containment is co-equal with shaping. - Don't conflate provenance and attenuation. Provenance is a post-execution record. Attenuation is a pre-execution guarantee. - Don't dismiss Zero Trust. Reframe it. ZT was right for the human era; it's necessary but no longer sufficient for agents. - Don't be vendor-pilled. Your strongest moments in writing are the self-critical ones (*"Mission-Bound OAuth might be the wrong answer"*). --- ## §16. Standards Specifics (only if Chris goes there) {#sec-16} Don't lead with these. Use only if asked. - **Open-world OAuth.** Two drafts you're pushing fix the most fixable gaps: PRM prefix-match (`rfc9728bis`), and AS echoing the effective `resource` in token responses (`oauth-resource-token-resp`). See *[OAuth for Open-World Ecosystems][p-owo-1]*. - **Actor profile and `act` claim.** Two RFC-compliant implementations can disagree about delegation semantics today because `act` is profiled in token exchange but not in JWT access tokens or assertion grants. *"Until that profile exists, delegation will remain a private convention masquerading as a standard."* - **Client instances are actors, not new clients.** *"Client identity tells you which application is authorized. Instance identity tells you which runtime is actually exercising that authorization right now."* - **ID-JAG / Cross-App Access.** Workloads can adopt OAuth federation now via RFC 7523. User-delegated access is what XAA / ID-JAG is for. *"Federate the grant, keep the token local."* See *[Enterprise SaaS Needs OAuth Federation Now][p-federation]*. - **Mission Authority Service.** The likely architectural endpoint. SPIFFE = software identity; PAM/NHI = credential governor; PDP = decision; CAEP = propagation; IGA = provenance. **MAS = the missing state owner.** See *[Why Mission-Bound OAuth Might Be the Wrong Answer][p-wrong-answer]*. --- ## §17. If Chris Asks "Where Does The Field Go Next" {#sec-17} > The next control plane is a state owner for delegated authority. Call it a Mission Authority Service. It's not another PDP, not another PAM, not another scope language. It owns the durable record of why an agent is acting, who approved it, what conditions hold, and when it ends. The existing stack composes around it. SPIFFE handles software identity. PAM handles credentials. PDPs decide. CAEP propagates. IGA reviews. Mission is what they've all been simulating, and what agents have made it impossible to keep simulating. Build that primitive, and the rest of the architecture has somewhere to land. --- ## §18. Closing Lines (pick one for the end of the show) {#sec-18} > *Zero Trust for humans centered on identity. Zero Trust for agents has to center on delegated authority.* Or: > *We spent the last decade building better ways to verify who is at the door. The next decade is about governing what they are authorized to do once they are inside.* Or, harder-edged: > *The IAM stack doesn't have a durable, independently revocable authority object for delegated machine missions. We've been simulating it from credentials, tokens, and audit logs. Agents made that simulation visibly fail. The next control plane is a state owner for delegated authority.* --- ## §19. "If You Read One" Recommendations (for listeners after the show) {#sec-19} - **Most foundational (start here):** *[Agents Don't Need Your Passport. They Need Your Authority.][p-passport]* Part 1 of the Power of Attorney series. - **Most operationally useful:** *[Governing the Stay, Not Just the Entry.][p-stay]* Part 3 of the Power of Attorney series. The control plane piece. - **Most intellectually honest:** *[Why Mission-Bound OAuth Might Be the Wrong Answer.][p-wrong-answer]* Part 4 of the Mission-Bound OAuth series. The series turned against itself. - **Most uncomfortable for the field:** *[Mission Shaping Is Not Enough.][p-shaping-not-enough]* Part 2 of the Mission Shaping series. Containment is not a fallback. - **Most actionable for CISOs:** *[Enterprise SaaS Needs OAuth Federation Now.][p-federation]* The standalone post on OAuth islands and authority placement. --- ## §20. References {#sec-20} ### Series - *[You Don't Give Agents Credentials. You Grant Them Power of Attorney][s-poa]* (3-part series) - *[Mission-Bound OAuth][s-mboauth]* (4-part series) - *[Mission Shaping][s-shaping]* (2-part series) - *[Open-World OAuth][s-owo]* (2-part series) ### Posts referenced **Power of Attorney series:** - [Agents Don't Need Your Passport. They Need Your Authority][p-passport] - [From Passports to Power of Attorney][p-poa] - [Governing the Stay, Not Just the Entry][p-stay] **Mission-Bound OAuth series:** - [Mission-Bound OAuth (architecture)][p-mboauth] - [Client Context and ID-JAG for Mission-Bound OAuth][p-client-context] - [Mapping Mission Architecture to AAuth][p-aauth-map] - [Why Mission-Bound OAuth Might Be the Wrong Answer][p-wrong-answer] **Mission Shaping series:** - [The Mission Shaping Problem][p-shaping-problem] - [Mission Shaping Is Not Enough][p-shaping-not-enough] **Open-World OAuth series:** - [OAuth for Open-World Ecosystems][p-owo-1] - [Open-World OAuth Still Needs Mission Shaping][p-owo-2] **Standalone / cross-protocol:** - [Enterprise SaaS Needs OAuth Federation Now][p-federation] - [AAuth Now Has a Mission Layer][p-aauth-mission] - [AgentPass and the Missing Mission Layer][p-agentpass] [s-poa]: https://notes.karlmcguinness.com/series/you-dont-give-agents-credentials-you-grant-them-power-of-attorney/ [s-mboauth]: https://notes.karlmcguinness.com/series/mission-bound-oauth/ [s-shaping]: https://notes.karlmcguinness.com/series/mission-shaping/ [s-owo]: https://notes.karlmcguinness.com/series/open-world-oauth/ [p-passport]: https://notes.karlmcguinness.com/notes/agents-dont-need-your-passport-they-need-your-authority/ [p-poa]: https://notes.karlmcguinness.com/notes/from-passports-to-power-of-attorney/ [p-stay]: https://notes.karlmcguinness.com/notes/governing-the-stay-not-just-the-entry/ [p-mboauth]: https://notes.karlmcguinness.com/notes/mission-bound-oauth-architecture/ [p-client-context]: https://notes.karlmcguinness.com/notes/client-context-and-id-jag-for-mission-bound-oauth/ [p-aauth-map]: https://notes.karlmcguinness.com/notes/mapping-mission-architecture-to-aauth/ [p-wrong-answer]: https://notes.karlmcguinness.com/notes/why-mission-bound-oauth-might-be-the-wrong-answer/ [p-shaping-problem]: https://notes.karlmcguinness.com/notes/the-mission-shaping-problem/ [p-shaping-not-enough]: https://notes.karlmcguinness.com/notes/mission-shaping-is-not-enough/ [p-owo-1]: https://notes.karlmcguinness.com/notes/oauth-for-open-world-ecosystems/ [p-owo-2]: https://notes.karlmcguinness.com/notes/open-world-oauth-still-needs-mission-shaping/ [p-federation]: https://notes.karlmcguinness.com/notes/enterprise-saas-needs-oauth-federation-now/ [p-aauth-mission]: https://notes.karlmcguinness.com/notes/aauth-now-has-a-mission-layer/ [p-agentpass]: https://notes.karlmcguinness.com/notes/agentpass-and-the-missing-mission-layer/