Give the Agent an Identity

Vocabulary for this episode

This episode has the highest jargon density in the series, most of it borrowed from identity engineering. None of it is optional — the words are load-bearing — but none of it requires prior knowledge either.

Three terms this series coins, because the standard vocabulary does not separate things that must be separated:

Authority Matrix — the artifact mapping each consequential action to its principal, authority source, resource binding, ceiling, lifetime, enforcement point, and required evidence.

Zero standing high-consequence authority — the achievable version of "zero standing privilege." The agent may hold standing permission to authenticate and read its work. It holds no standing permission to move money.

Enforcement context versus evidence context — the split between what a credential must carry to allow an action and what the audit trail must carry to explain it. Conflating them is the most common identity design error in agent systems.

Who this episode is for, and what you will own

More than any other episode, this one looks like it belongs to someone else. It does not. Identity infrastructure belongs to the platform team; the decisions that infrastructure implements do not.

Every item in the right column is a statement about accountability. None of them can be inferred from a working system, because a working system produces no evidence that its accountability is inadequate. That evidence arrives during the first investigation.

Platform builds the identity system. You decide what it must be able to prove.

Where this sits in the series

• Episode 01Bounds what one run may cause
• Episode 02Defines the world it reasons in
• Episode 03 — this oneEstablishes whose authority it carries, and whether anyone can prove it afterward
• Episode 04States what still holds under attack
• Episode 05Proves all four remain true in production

The three artifacts couple tightly, and the coupling is worth stating precisely:

The envelope says a refund may be issued. The manifest says which payment system it reaches. The matrix says whose authority moved the money, and how you prove that afterward.

Two mechanisms carry forward directly. Episode 01's consequence classes become an identity-layer control10 — a run that cannot establish authorizing basis drops from C3 to C2. And Episode 02's run attestation becomes one link in this episode11's evidence chain: the manifest attests to the world, the matrix attests to the authority, and a correlation identifier stitches both to the business outcome.

01The actor field

The instinct is to say the service account is not a real identity. That is rhetorically satisfying and technically wrong.

A service account is an identity. It authenticates. It appears in access reviews. It can be assigned permissions and revoked. The problem is not its existence but its shape.

In most agent deployments it is shared across runs, long-lived, scoped to the union of every task any agent performs, unbound to the specific case at hand, and unable to carry the context that made the action legitimate.

A service account can identify the caller. It cannot, by itself, explain the action.

That gap has four operational consequences, and each compounds as the fleet grows.

Revocation becomes all-or-nothing. Disabling one misbehaving agent disables every agent sharing the credential. On the day you most need a precise instrument, you have a blunt one.

Least privilege becomes arithmetically impossible. The account must hold the union of every permission any consumer requires. Add a fifth agent and the account gets broader. It never gets narrower, because narrowing it breaks something.

Incident scope becomes unbounded. A compromised credential implicates every action it ever took. The investigation cannot narrow, because nothing in the record distinguishes one agent's actions from another's.

Approval becomes decorative. A human authorizes an action in one system while the target system records the service account. The two are connected only by a timestamp and someone's recollection of what they were looking at.

None of these are identity-infrastructure problems. They are product problems, because each one is a decision about what the business must be able to prove afterward — and nobody but product is going to make that decision.

02Identity is not authority

The word identity is doing the work of six different questions in most agent conversations. Separating them is the whole of this episode.

The error most teams make

An earlier draft of this series made a mistake worth naming, because it is the mistake nearly everyone makes on the first pass.

It treated the customer as the delegating subject — as though the agent acted on the customer's behalf in the OAuth sense.

But a customer disputing a charge does not possess the merchant's refund authority. They cannot delegate what they never held. The customer initiates the task and is affected by its outcome. The authority to move money belongs to Billing Operations, exercised under refund policy v11, and in exception cases granted by a named reviewer.

A request can initiate an action without authorizing it.

This distinction is not pedantic. It determines what your logs mean.

If the system records the customer as the authorizing party, the audit trail asserts that the customer approved a merchant disbursement. That is false. It will not survive a financial controls review, and the person who has to explain it will not be the engineer who configured the token exchange.

The test to apply: for every action, ask whether the party recorded as authorizing it could have performed that action themselves, with their own credentials, on that day. If no, they did not authorize it. They requested it.

03Choose the authority model

A common claim is that delegation is the correct default. That is too broad, and the breadth hides the actual product decision.

Agent actions derive authority from at least five distinct sources. Choosing among them is a business decision that determines what your identity infrastructure must support.

The warning · Impersonation produces logs that are confidently false. The record states that a human performed an action an autonomous system performed. Six months later, in an investigation, that is worse than an ambiguous log — because it asserts something untrue with full system authority. Someone will build a conclusion on it.

The refund agent uses three of these models simultaneously, which is typical and worth making explicit rather than letting it happen by accident:

• Reading the caseown-principal, scoped to the assigned case
• Refunding within ceilingpolicy-authorized
• Refunding above ceilingapproval-derived

Use delegation when authority genuinely derives from a user. Use an agent principal when it derives from organizational policy. Do not disguise one as the other.

Getting this wrong is less a security failure than an accounting failure. The system will faithfully record authority flowing from a party who never held it, and it will do so consistently, at scale, for months.

04Who authorized the authorizer?

Here is a gap that survives in almost every agent identity design, including the first draft of this one.

The matrix says exception refunds above ₹2,000 require approval from a "named reviewer." That sounds rigorous. Then nobody asks the next four questions.

Does that reviewer actually hold ₹8,400 refund authority? In most organizations, human approval limits exist — in a delegation-of-authority policy, a finance manual, or an ERP configuration. Agent approval flows are frequently built without reference to any of them. A support lead who can personally approve ₹5,000 ends up approving ₹8,400 through the agent, because the agent's approval interface has no limit of its own.

How is that authority verified at approval time? Usually it is not. The approval service checks that someone with the reviewer role clicked approve. It does not check that this specific person holds this specific amount of authority for this specific category of expenditure.

What happens when they change roles? Human authority is revoked through HR processes and access reviews. Agent approval routing is typically configured once and pointed at a group, a rota, or worse, a list of names in a config file. The person who left in March may still be an eligible approver in August.

Can the approver approve their own escalation? If an approval routes to whoever is on shift, and the agent escalated a case that person was already working, the reviewer is approving their own work. In a human process this is usually prevented by segregation of duties. In an agent process it is usually not prevented at all, because nobody modeled it.

The principle

Approval-derived authority inherits the approver's limits. If the approver's own authority is not modeled, the approval is a rubber stamp with a name attached to it.

The delegation chain does not begin at the agent. It begins at whoever the organization actually authorized to move that much money, and the agent's approval flow is one more hop in a chain that already existed before anyone built an agent.

What the matrix must record

What you own: finding out whether a human approval limit exists for this category of action, and insisting the agent's approval path respect it. This is usually a thirty-minute conversation with Finance that nobody has had, and it frequently discovers that the agent's exception ceiling was chosen by an engineer who picked a round number.

The question to ask: "If a human did this manually, who would have to sign off, and up to what amount?" Then check whether the agent's approval path routes to that person, respects that limit, and reads that roster.

05Grant authority per action

Once the authority source is settled, the question becomes what the agent actually holds while it runs.

Zero Trust supplies the shape of the answer. NIST SP 800-207 defines zero trust as concepts designed to enforce accurate, least-privilege per-request access decisions, with access rules made as granular as possible1.

More useful than the principle is the architecture. NIST separates three components: the policy engine, which makes the ultimate decision to grant access; the policy administrator, which establishes or shuts down the communication path and generates any session-specific credential; and the policy enforcement point, which enables, monitors, and terminates the connection.

The placement · The agent is not the policy engine. It is the subject of a decision made elsewhere. An agent that evaluates its own permissions has no meaningful permissions. It should receive a grant that already encodes the decision.

Zero standing high-consequence authority

Zero standing privilege is often asserted as the controlling principle. In practice it is unattainable and unnecessary. Most production agents need standing ability to authenticate, consume from a queue, emit telemetry, and read their assigned work.

The goal is not zero standing access. It is zero standing high-consequence authority.

Just-in-time access grants time-limited, task-specific permissions only when needed and revokes them immediately afterward, minimizing the window in which elevated access can be exploited2. The stronger variant issues ephemeral credentials generated per session and de-provisioned on completion.

This maps unusually well onto agents, because Episode 02 already defined the run as a bounded unit with a start, a completion condition, and a maximum duration. That is exactly the shape just-in-time access assumes.

The cost, stated honestly

Just-in-time grants are not free, and a review that ignores this will produce a design engineering quietly abandons.

For a refund agent issuing one payment per run, the cost is negligible. For an agent making forty consequential calls a minute, it is a design constraint.

The mitigation is scoping, not abandonment. Grant per action class bounded to the run rather than per individual call. Batch where the consequence class is uniform. Keep the tight per-action grant for the irreversible step Episode 01 identified, which is usually one step, not forty.

06Where the constraint lives

The matrix specifies that the refund grant is bound to case, transaction, and amount. It does not specify how. That distinction matters enormously, because a broad bearer token plus a system-prompt instruction can satisfy the requirement on paper while satisfying nothing in reality.

Product specifies the required constraint. Engineering selects the pattern.

The one unacceptable answer is enforcement in the agent's own reasoning — the same behavioral-versus-structural distinction Episode 02 drew about policy delivered as context, and the one Episode 04 builds its entire compromise analysis on.

The mediating gateway row deserves a note, because it is the honest answer for most enterprises. Your payment system probably cannot evaluate a custom claim saying "case 9912 only." A gateway that holds the broad credential, validates the narrow context, and then calls the broad API is a legitimate structural control — provided the agent cannot reach the broad API directly. That proviso is the whole control, and it belongs in the manifest's denied list from Episode 02.

07Read authority is not free

Here is a tension between this episode and Episode 04 that is worth resolving openly rather than leaving for a reader to notice.

Section 05's table grants standing read authority to the agent's assigned case, billing events, and dispute history, on the grounds that reads are "bounded, low consequence."

Episode 04 then argues that reading private data is one of three conditions that make an agent acutely dangerous — private data, untrusted content, and an outbound channel. Under that analysis, read authority is not low consequence at all. It is exactly half of an exfiltration path.

Both are correct, and the resolution is that "consequence" means two different things.

So the standing-read grant is defensible only when the outbound side is structurally bounded. Read authority and egress authority are not independent decisions, even though they are configured in different systems by different teams.

What this changes in the matrix

Read grants get three properties they usually do not have:

Scope, not just permission. "Read billing events" is too broad. "Read billing events for the assigned case" is the grant. If the enforcement point cannot express the scope, a mediating gateway must.

Sensitivity class. Not all reads are equal. Reading a dispute description and reading a stored payment instrument are different exposures, and only one of them belongs in an agent's standing authority.

A stated pairing with egress. The matrix should record, next to each read grant, what the manifest's egress policy is. Broad standing reads with an open egress allowlist is the combination to catch in review, and neither artifact catches it alone.

A read grant is only as bounded as the egress policy it sits next to. Review them in the same conversation or you will approve each one reasonably and end up with an unreasonable pair.

What you own: deciding which reads are genuinely required, at what scope, and insisting the review looks at read authority and egress together rather than in two separate meetings six weeks apart.

08What identity proves, and what it does not

Workload identity systems establish which workload is calling. SPIFFE assigns each workload a SPIFFE ID and issues an SVID — an X.509 certificate or JWT — that the workload uses to authenticate to other workloads3. To minimize exposure from a leaked key, private keys and certificates are short-lived and rotated frequently3 and automatically. The infrastructure generates these on the workload's behalf rather than requiring it to hold a long-term secret4.

It is tempting to claim this lets a downstream system verify the manifest's image digest, policy version, and network posture. It does not — not by itself. Three things are being conflated:

Standard workload identity delivers the first. The second requires additional attestation evidence, claims, or admission controls. The third requires a policy decision.

The manifest declares the intended world. Workload identity authenticates the calling workload. If access decisions depend on properties like image digest or manifest version, those properties must be separately attested and carried into the decision.

Two calibrations worth stating so nobody over-reads the guarantee. Credential lifetime is an operator configuration, not a specification property — state it as a choice your platform team makes, not a default you inherit. And short lifetimes reduce the revocation window without eliminating the need for an emergency path: a compromised credential remains dangerous for its remaining validity, and trust-bundle changes may require immediate action regardless.

Agent identity as a governed principal

Platforms are now formalizing this specifically for agents. Microsoft Entra Agent ID introduces agent identity as an identity construct for AI agents, extending existing capabilities such as Conditional Access and identity governance5.

The credential design is worth noting precisely. Authentication credentials are configured on the blueprint, which uses them to acquire tokens on behalf of agent identities; credentials do not reside on the agent identity6 itself. The blueprint authenticates with its own credential and obtains an exchange token for a specific child agent identity6.

That separation is the point: **the thing that is the agent and the thing that carries authority are deliberately different objects.**

But the maturity should not be overstated. Conditional Access targeting of agents is in preview, and a substantial set of familiar controls does not apply to agent identities at all — multifactor authentication, authentication strength, device compliance, approved client apps, session controls, sign-in frequency7, and location conditions.

The strategic read for an AI PM: enterprise identity providers are moving to treat agents as governable principals, which means agent access will increasingly face the same access-review and lifecycle machinery as employee access. But the control surface is thinner than the human equivalent today, so more of the burden currently falls on the grant itself rather than on conditional policy around it.

Plan for that to shift. A design that puts everything in the grant will still work when conditional controls mature. A design that assumes conditional controls exist today will not work now.

09Preserve the evidence chain

Here is where identity designs most often go wrong: they try to put the entire provenance record inside the credential.

Tokens should be minimal, audience-bound, short-lived, and limited to what the resource server needs to make a decision. Loading them with case IDs, model versions, manifest versions, and approval references creates propagation, privacy, and size problems — and puts business context in front of systems that have no need for it.

Put enough context in the credential to enforce the action. Put enough evidence in the audit trail to explain it. Do not turn the token into the audit log.

Two surfaces, cleanly separated:

Enforcement context — what the target system needs to allow or deny: agent principal, audience, operation, resource binding, amount ceiling, expiry, and an approval or authorization handle.

Evidence context — what the organization needs to reconstruct the action: run ID, agent and model version, manifest version, case ID, policy version, initiator, approval record, tool request, and authoritative outcome.

The two are joined by a stable correlation identifier that appears in both.

The ledger correction

A tempting accountability claim is that a refund can be traced "from the payment ledger alone." That is both unrealistic and undesirable.

A payment ledger should record the transaction, amount, execution principal, timestamp, idempotency reference, and outcome. It should not carry delegation chains, model versions, or support reasoning. Forcing it to do so couples unrelated systems and pushes sensitive context into a financial record that has its own retention rules and its own audience.

The correct standard is a correlated chain across authoritative systems:

This extends the receipt discipline from Episode 02 rather than duplicating it. The manifest attests to the world; the matrix attests to the authority; a correlation identifier stitches them to the business outcome.

The practical test: hand someone a correlation ID and ask them to reconstruct the action without asking anyone a question. If they need to ask a human what happened, the chain has a gap, and the gap is where the investigation will stall.

On delegation chains as evidence

RFC 8693 defines the act claim as a means to express that delegation has occurred and identify the acting party. The outermost act claim represents the current actor, while nested claims represent prior actors, with the least recent most deeply nested8.

The specification then says something that changes the design:

RFC 8693 · Prior actors are informational only. For the purpose of applying access control policy, the consumer of a token must only consider the token's top-level claims and the party identified as the current actor by the act claim. Prior actors identified by any nested act claims are informational only and are not to be considered in access control decisions.

A delegation chain is evidence of how authority travelled. It is not proof that every delegation was valid.

The RFC also defines may_act, which states that one party is authorized to become the actor and act on behalf of another — usable by the authorization server to determine whether the requested delegation should be permitted at all8. That is the pre-authorization primitive, and it sits at issuance rather than at consumption.

The product implication: the protocol can preserve delegation, but only policy can make the delegation valid. Each exchange requires its own evaluation.

10Multi-agent attenuation

An orchestrator dispatching to sub-agents raises the stakes on everything above, because the easy path silently destroys the properties you just built.

Two models exist. Propagation hands the sub-agent the parent's credential — simple, and it means the sub-agent inherits the parent's full authority regardless of its task, with the target system unable to distinguish them. Attenuated delegation issues the sub-agent a derived credential with strictly narrower authority.

Four invariants should hold, and none of them are enforced by any protocol automatically:

1. Authority never increases down the chain. A sub-agent cannot hold permissions its parent lacked.
2. Lifetime never extends down the chain. A derived grant expires no later than its parent.
3. Audience narrows at each hop. A credential usable against multiple unrelated services can be redirected even when its permissions are otherwise tight.
4. The chain is recorded as evidence, not consumed as authorization. Per RFC 8693, the current actor governs the decision; prior actors are informational8.

The third invariant is the one most often missed. Narrow permissions on a broadly scoped audience still leave a redirection path — the permission says what may be done, the audience says where, and tightening only one of them is half a control.

The fourth is where teams over-trust the protocol. Token exchange can issue broader authority if the authorization server permits it. Attenuation is a policy property that must be configured and tested, not a protocol guarantee.

The most common accidental violation of rule one: giving a sub-agent its own service account "for simplicity." This breaks the chain and grants authority the parent never held, and it usually happens during a sprint where the token exchange was the blocker and someone found a workaround.

11When the initiator is another agent

Section 02's initiator field quietly assumes a human or a schedule started the run. In any multi-agent system, that assumption fails immediately, and the failure is not obvious because the field still contains a valid value.

An orchestrator dispatches to a refund sub-agent. What is the initiator?

The naive answer is the orchestrator. That is true and useless. It tells you which process began this run and nothing about why the work exists or who is answerable for it.

Two facts, not one

Multi-agent systems need the initiator split into two fields that are frequently identical in single-agent systems and never identical in multi-agent ones:

The root initiator must propagate unchanged through every hop. It is the only field that answers "why does this work exist?" — and it is the field an investigation actually needs.

The failure when this is missing: an investigation traces a refund to an orchestrator, traces the orchestrator to a queue, traces the queue to a batch job, and stalls. The chain is complete and explains nothing, because at no point does anything say a customer disputed a charge on July 14th.

Three rules

The root initiator propagates unchanged. It is copied down every hop, never regenerated. A sub-agent that mints a fresh root initiator has severed the chain.

The proximate initiator is recorded per hop. This is what reconstructs the topology when something goes wrong in the middle.

Depth is bounded and recorded. An agent that can dispatch to agents that can dispatch to agents needs a maximum depth, enforced structurally. Without it, one malformed task can produce a chain nobody designed, and the fan-out bound Episode 01 set becomes the only thing standing between you and an incident.

Where authority actually comes from

This is the part teams get wrong under time pressure.

Authority does not derive from the chain. It derives from the same five models in section 03, evaluated fresh at each hop. A sub-agent issuing a refund is policy-authorized under refund policy v11 — exactly as it would be if a human had dispatched it. The orchestrator's involvement is evidence of how the work arrived, not the basis on which it is permitted.

The chain explains how the work got here. Policy decides whether it may proceed. Never substitute the first for the second.

What you own: deciding that root initiator is a required field, that it propagates, and that no agent may act on the strength of "an orchestrator asked me to." If your matrix has one initiator field, it works today and breaks the first time you add a second agent.

12The identity nobody decommissions

Human identities have a lifecycle everyone understands. Someone joins, gets provisioned, changes roles, gets re-reviewed, leaves, gets deprovisioned. It is imperfect but it exists, it has an owner, and it runs on a schedule.

Agent identities usually have half of one. They get created. Nothing else is defined.

What accumulates

Orphaned identities. The agent was deprecated in March. Its identity still exists, still authenticates, still holds whatever grants it was given. Nobody disabled it because nobody owned it, and the deprecation ticket said "remove the service" rather than "remove the principal."

Permission accretion. Every incident where the agent needed one more permission added one more permission. None were ever removed, because removing a permission requires knowing it is unused, and nobody measures that.

Ownership decay. The identity was provisioned by an engineer who has since changed teams. During an access review the owner field points at a person who has no idea what it is, so they approve it, because the alternative is finding out.

Version sprawl. Agent v1, v2, and v3 each have identities. v3 is in production. v1 and v2 still authenticate.

What the matrix must specify

The one that pays for itself immediately: grants that expire by default.

If every standing grant carries a renewal date, permission accretion self-corrects — unused permissions lapse silently, used ones get re-justified by someone who knows why. Without expiry, the only mechanism that removes a permission is someone deliberately auditing for it, which happens after the incident that made it interesting.

An agent identity with no decommission trigger is permanent. Every one you create is a standing grant you have promised to review forever, and nobody is reviewing them.

What you own: the review cadence, the accountable owner, and the decommission trigger. Platform can build all three. None of them can be inferred, because a working agent produces no signal that its identity has outlived it.

The question to ask in the review: "When this agent is retired, what specifically removes its ability to authenticate, and who confirms it happened?" If the answer is a person's good intentions, write it down as a finding.

13Validate, revoke, degrade — and count the cost

Episode 02 established that a specification which cannot block a run is documentation. Identity requires the same discipline, plus one thing the manifest did not need: a way to stop a run already in flight.

Validation before execution

The fourth row carries forward Episode 02's most useful mechanism. Degraded mode is not failure — it is the run continuing at a lower consequence class. An agent that cannot establish authorizing basis drops from Act to Propose. It still investigates, still produces a recommendation, still delivers value. It no longer produces irreversible effects on unverified authority.

The last row is the coupling to Episode 01's idempotency argument, restated at the identity layer: a resumed run must not assume its previous grant went unused.

Count the refusal cost

Same discipline as Episodes 01 and 02, and the same reason: a validation table with eight refusal conditions and no capacity conversation is not a control design, it is an unplanned load transfer.

Three questions per row:

1. How often will this fire at forecast volume?
2. Who receives the work, and do they know?
3. Is this a rare platform incident or a routine event dressed as an exception?

The rows most likely to surprise you are authority source not determinable and evidence sink unreachable. Both look like rare infrastructure failures. Both turn out to fire regularly in the first month, because the authorization service and the audit pipeline are newer than the systems around them.

If a refusal condition fires more often than the receiving team can absorb, fix the dependency or widen the bound with a compensating control. Leaving it is choosing to degrade the product while the dashboard stays green.

Revocation

The question a reviewer will ask during an incident is narrow: **what can a human do in the next sixty seconds to stop this specific agent?**

The answer is determined entirely by choices made at design time.

Revocation granularity is decided at identity design time. If the credential is shared, so is the kill switch.

Three granularities should be available, each without affecting other agents:

If your architecture can only offer "disable the service account," you have one blunt instrument for a fleet, and you will hesitate to use it — which means in practice you have none.

Short credential lifetimes help but do not substitute. Expiry handles the leaked credential. It does not handle the agent misbehaving right now, within its valid window, which is the case you are actually worried about.

Test all three in a drill. A revocation path that has never been exercised is a claim, not a control. Episode 04 makes the same argument about interruption, and for the same reason.

14The confused deputy

One failure mode deserves its own treatment, because agent systems are structurally prone to it in a way ordinary software is not.

The confused deputy problem occurs when an entity that lacks permission to perform an action coerces a more-privileged entity into performing it, exploiting the trust placed in that entity9's identity.

An agent is a nearly ideal confused deputy. It holds real authority. It acts on instructions. It processes untrusted input — customer messages, documents, retrieved content, tool outputs. Any of those can attempt redirection, and the agent has no reliable way to distinguish a legitimate instruction from an injected one.

AWS's mitigation illustrates the principle rather than supplying the mechanism. The external ID is controlled by the calling service, unique per customer, and checked in the trust policy, ensuring the party controlling the role is the party making the request9. The transferable idea is that authority should be bound to the context for which it was issued, so a privileged intermediary cannot redirect it toward a different customer or resource.

Applied to the refund agent: a grant issued for case 9912 and transaction T17 is invalid for any other case or transaction. Manipulation may change what the agent attempts. It cannot change what the grant authorizes.

The question is not whether the agent can be manipulated. It is whether a manipulated agent holds a grant that authorizes the manipulated action.

That reframing is the bridge into Episode 04, which assumes manipulation has already succeeded and asks what still holds.

15Translating this to your product

The refund agent makes authority legible because money forces the question. Every agent has the same six roles whether or not anyone has named them.

The generalizable questions, whatever you build:

1. For each action, could the party recorded as authorizing it have done it themselves that day? If no, they initiated rather than authorized.
2. Does a human authority limit already exist for this action, and does the agent's path respect it?
3. What does the agent hold standing, and is any of it high-consequence?
4. Can you stop one agent without stopping all of them?
5. Hand someone a correlation ID — can they reconstruct the action without asking a human?

16The artifact

17How to run the review

Ninety minutes. This is the episode where product cannot proceed alone — whoever owns identity infrastructure must be in the room, and for section 04 you need someone from Finance or whoever owns your delegation-of-authority policy.

Minutes 0–10 · Frame it. Read the actor field opening aloud. State the goal: by the end, every consequential action has a named authority source and a reconstructible evidence path.

Minutes 10–25 · Roles. For each consequential action, who is the business subject, who initiated it, what workload acted, whose policy authorized it? Are any of these the same party by accident rather than design? Is anything modeled as user-delegated when the user never held that authority?

Minutes 25–35 · The approver. Does a human authority limit exist for this action? Where is it written? Does the agent's approval path respect it, read a live roster, and prevent self-approval? This is the segment most likely to discover something nobody knew.

Minutes 35–50 · Grants. What standing authority exists, and is any of it high-consequence? Is each write grant bound to case, resource, amount, audience, and time? Walk the read grants alongside the manifest's egress policy. Which actions have no grant at any layer, and is that list as long as it should be?

Minutes 50–60 · Enforcement. For each constraint, which enforcement point applies it? Is any constraint enforced only in the agent's reasoning or system prompt? For the mediating gateway pattern — can the agent reach the broad API directly?

Minutes 60–70 · Evidence. From a correlation ID, can you reconstruct initiator, authority basis, agent version, world configuration, approval, and outcome? Which system holds each piece? Where does the chain break?

Minutes 70–80 · Delegation and revocation. Does authority strictly narrow at each hop? Does audience narrow? What stops this run, this version, this identity — each independently, within a minute? When was that last tested?

Minutes 80–90 · Lifecycle and the confused deputy. Who owns this identity, when is it reviewed, what retires it? And: if untrusted input manipulated the agent into attempting a different action, which grant would authorize it?

Leave with: a completed action grant table, a named approver population with a verified ceiling, a refusal-cost owner per condition, three tested revocation paths, and a decommission trigger.

18Anti-patterns

• "The agent has a service account."It has an identity too coarse to attribute, revoke, or scope. Name what is actually missing rather than denying the account is an identity.
• "The agent acts on behalf of the customer."Only if the customer held that authority. For a merchant-issued refund, they did not.
• "The agent runs as the user."Impersonation. The log confidently asserts something false.
• "A named reviewer approves exceptions."Does that reviewer hold that authority themselves? Verified against what, at what moment?
• "We rotate quarterly."Rotation cadence is not lifetime. A ninety-day credential is useful to an attacker for ninety days.
• "Approval is logged in our system."Then approval and action live in separate systems joined by a timestamp. Bind approval to the action intent and derive the grant from it.
• "Reads are low risk."Read authority plus outbound reach is an exfiltration path. Review them together.
• "Sub-agents inherit the parent token."Authority stops attenuating and the chain flattens at the first hop.
• "The orchestrator authorized it."The orchestrator dispatched it. Policy authorizes it, evaluated fresh at this hop.
• "The delegation chain proves authorization."RFC 8693 says the opposite — prior actors are informational and must not factor into access control.
• "The agent checks whether it's allowed."The agent is the subject of a decision, not the policy engine.
• "We can disable the service account."Which disables every agent using it. That is not a kill switch, it is an outage.
• "The identity is owned by the platform team."Named individual, or nobody.
• "We'll add identity before GA."Every integration built against a shared service account must be rebuilt when it is removed, and none of them will be scheduled.

19What product owns

Identity infrastructure belongs to platform teams. Eight decisions do not.

1. Authority source. Does each action derive from organizational policy, the agent's own permissions, a named approval, or a user's delegated authority?
2. Business subject and initiator. Who is affected, and what began the run — recorded as distinct facts, with root and proximate initiator separated.
3. Approver authority. Whether a human limit exists for this action, and whether the agent's approval path respects it.
4. Action grant. The exact resource, operation, ceiling, audience, and lifetime permitted — including which reads, at what scope.
5. Evidence requirement. What must be reconstructible, and which system holds each piece.
6. Degraded behavior. What the run may still do when authority evidence is incomplete, expressed as a consequence class.
7. Revocation objective. What must be stoppable, at what granularity, within what time — and tested.
8. Identity lifecycle. Who owns it, how often grants are re-justified, and what retires it.

None require identity expertise. All determine whether the system is governable.

The envelope bounds what may happen. The manifest defines the world. The matrix determines whose power is exercised inside it — and whether anyone can prove it afterward.

The line

A service account can identify the caller. It cannot, by itself, explain the action.

A request can initiate an action without authorizing it.

Approval-derived authority inherits the approver's limits. If the approver's own authority is not modeled, the approval is a rubber stamp with a name attached.

Put enough context in the credential to enforce the action. Put enough evidence in the audit trail to explain it.

The protocol can preserve delegation. Only policy can make it valid.

Revocation granularity is decided at identity design time. If the credential is shared, so is the kill switch.

20The AI PM page

Field artifact · Episode 03 · print this

Before your team provisions an identity

How to use this. The Authority Matrix is what your team produces together. This page is what you bring to the room. Block 2 is the meeting — and unlike Episodes 01 and 02, you cannot run it alone. Bring identity infrastructure, and bring whoever owns your delegation-of-authority policy.

1 · Decisions you own

2 · Questions you must get answered

1. For each action — could the party we record as authorizing it have done it themselves, with their own credentials, that day? If no, they initiated. Fix the record.
2. Does a human authority limit already exist for this action, written down somewhere? Find it before you set the agent's ceiling.
3. Is the approver roster live from the identity provider, or a list someone maintains? Static lists outlive the people on them.
4. Can the approver approve their own escalation?
5. What does the agent hold standing, and is any of it high-consequence?
6. Which reads are standing, and what is the egress policy sitting next to them? Ask both in the same breath.
7. Which constraints are enforced in the agent's reasoning rather than at a gateway? Those are preferences.
8. What stops this run, this version, this identity — separately, in sixty seconds? When was that last tested?
9. Hand someone a correlation ID: can they reconstruct the action without asking a human?
10. When this agent is retired, what removes its ability to authenticate, and who confirms it?

3 · Assumptions to test

• That a service account is enough because it appears in access reviews.
• That the customer requesting the action is the customer authorizing it.
• That a named approver holds the authority the approval implies.
• That the approver list reflects who works here now.
• That rotation cadence is the same thing as credential lifetime.
• That reads are low risk independent of what the agent can reach.
• That a sub-agent's authority narrowed because the protocol supports narrowing.
• That the orchestrator's dispatch is an authorization.
• That the delegation chain proves each delegation was valid.
• That disabling the service account is a usable kill switch.
• That someone will notice when this identity outlives the agent.

4 · Conversations to schedule

5 · Signals this work was skipped

• Nobody can name where the human approval limit is written down.
• The approver list is a config file rather than a live identity-provider roster.
• Read grants and egress policy are reviewed in separate meetings.
• “Attenuation” is described as something the protocol does on its own.
• The only revocation path is disabling the service account.
• The identity has an owning team but no owning person.
• The actor field on a consequential action reads like a service account name.
• An approval and the action it authorized are joined only by a timestamp.
• Identity is scheduled as work to do “before GA.”

What you leave with

A completed grant table. A named approver population with a verified ceiling and its source document. A refusal-cost owner for every condition. Three revocation paths with drill dates. A decommission trigger.

One line to carry out: a service account can identify the caller. It cannot explain the action.

→Next · Contain the Compromise

Three artifacts now govern the run. The envelope bounds consequence. The manifest constructs the world. The matrix establishes authority and evidence.

Each assumes the system behaves roughly as designed — that the agent follows instructions, the harness enforces policy, the sandbox holds, and the grant is used as issued.

Episode 04 removes that assumption.

Assume untrusted input has redirected the agent. Assume the sandbox has been escaped. Assume a grant has leaked while still valid. Assume the tool contract has been bypassed.

What still holds?

That question separates a control from a hope. A ceiling enforced at the payment gateway holds when the agent is compromised. The same ceiling in a system prompt does not. A case-bound grant holds when the agent is manipulated. A broad bearer token does not.

Episode 04 works backward from compromise to identify which controls survive it, and rebuilds the boundary so that a failure at any single layer does not become an organizational incident.

Episodes 01 through 03 design for a system that works. Episode 04 designs for the day it does not.