Six articles. One through-line. Here's the scaffold.
Provisioning and Lifecycle
Recall the core problem from 3.1: agents don't have HR records. They get created, they get credentials, and unless someone builds the offboarding process explicitly, they persist indefinitely — with access scoped for a task that ended months ago.
Agent identity — A machine principal created to represent an AI agent's actions in a system, distinct from the service account it superficially resembles. When it comes up: When a buyer says "we're just using service accounts for our agents." That's the moment to ask when those accounts were last rotated and who owns them. Don't confuse with: Workload identity. Workload identity is infrastructure-bound and relatively static. Agent identity is task-bound and dynamic — the agent may spin up, complete a workflow, and need to be deprovisioned within hours.
Orphaned agent credential — An active credential attached to an agent that is no longer in use, still holding whatever permissions it was granted at creation. When it comes up: Any conversation about agent sprawl or post-deployment governance. The question "how many agents do you have running right now?" almost always produces a number that's wrong. Don't confuse with: Orphaned user accounts. The risk profile differs: orphaned user accounts are dormant. Orphaned agent credentials may still be callable by other systems.
If you remember nothing else: Agents need lifecycle management built like HR offboarding: explicit termination, a named owner, a scheduled review.
Authentication and Delegation
The 3.2 argument was precise: delegation chains break accountability. When a human authorizes an agent, and that agent calls a tool, and that tool calls another service, the original authorization is three hops away from the action being taken.
Delegation chain — The sequence of principals through which an authorization passes before an action executes: user → agent → tool → downstream service. When it comes up: When a buyer describes a multi-agent workflow and hasn't thought about what happens when one link in the chain is compromised. Don't confuse with: OAuth delegation specifically. OAuth delegation is a protocol mechanism. A delegation chain is the architectural reality that mechanism creates — and it can exist without OAuth.
Client credentials flow — The OAuth grant type agents use when acting autonomously, without a user present to authorize in real time. When it comes up: When the conversation turns to "how does the agent prove it's allowed to do this?" The answer, in most current implementations, is a client secret — which is a credential that can be stolen. Don't confuse with: Authorization code flow. That flow assumes a human in the loop. Client credentials assumes no human. The security model is fundamentally different.
If you remember nothing else: The agent is always acting on someone's behalf. The question is whether the system knows whose behalf, and whether that authorization is still valid.
Permission Scoping
3.3 located the scoping problem in the architecture itself. Agents request broad scopes because they're built to handle uncertainty. Least privilege requires knowing in advance what you'll need. Agents, by design, often don't.
Scope creep — The accumulation of permissions beyond what a specific task requires, typically because agents are provisioned with broad access to avoid runtime failures. When it comes up: When a buyer says their agents "just need read access to everything." That's not least privilege; that's least friction. Don't confuse with: Privilege escalation. Scope creep is passive — it happens at provisioning. Privilege escalation is active — it happens at runtime, often through exploitation.
JIT elevation — Just-in-time permission grant: the agent requests a specific permission at the moment it needs it, the request is evaluated, and the permission expires when the task completes. When it comes up: When you're explaining how to operationalize least privilege for agents without breaking workflows. JIT elevation is the mechanism that makes dynamic scoping possible. Don't confuse with: Least privilege as a static state. Least privilege is the principle; JIT elevation is one implementation of it for workloads where access needs are unknown in advance.
If you remember nothing else: Least privilege for agents is a runtime capability. Most organizations haven't built it yet.
Attack Surface and Blast Radius
3.4 was the threat model article. The central claim: agent credentials expand the attack surface in ways that don't map cleanly to existing threat models, because agents can act at machine speed across multiple systems simultaneously.
Blast radius — The scope of damage possible if an agent credential is compromised: every system the agent has access to, every action it can take, at the speed it can execute them. When it comes up: When a buyer is focused on agent capability without thinking about agent compromise. "What happens if this credential leaks?" is the question that opens this conversation. Don't confuse with: Blast radius in infrastructure (a misconfigured firewall rule, a misconfigured S3 bucket). The agent version is dynamic — it depends on what the agent is doing at the moment of compromise, not just what it has access to.
Prompt injection — An attack in which malicious content in the agent's environment manipulates the agent's behavior, hijacking its actions using the agent's own credentials. When it comes up: When a buyer assumes that because the agent's identity is controlled, the agent's behavior is controlled. Prompt injection breaks that assumption. Don't confuse with: SQL injection or traditional input validation attacks. The attack surface is the agent's reasoning, not a query parser.
If you remember nothing else: A compromised agent credential is worse than a compromised user credential, because the agent doesn't get tired, doesn't get suspicious, and doesn't call IT.
Observability and Accountability
3.5 and 3.6 together made a single argument: existing audit infrastructure wasn't designed for agents, and the gap isn't cosmetic. Attribution — knowing who is responsible for an action — breaks down when the actor is an agent operating on delegated authority three hops from the original authorization.
Agent trace — A structured record of an agent's decision path: what it was asked to do, what tools it called, what data it accessed, and what it returned — distinct from a simple log of API calls. When it comes up: When a buyer asks "how do we know what the agent did?" An audit log tells you an API was called. An agent trace tells you why. Don't confuse with: Audit log. An audit log records that an event occurred. An agent trace records the reasoning that produced it. Compliance and incident response increasingly require the latter.
Non-repudiation — The property that an action can be attributed to a specific principal in a way that cannot be denied after the fact. When it comes up: In any conversation about accountability for agent actions, especially in regulated environments. If an agent takes a harmful action, who signed for it? Don't confuse with: Authentication. Authentication proves identity at the moment of access. Non-repudiation proves that a specific identity took a specific action — and that the record can't be altered. In agent systems, the delegation chain complicates both.
If you remember nothing else: Your buyer's compliance team will eventually ask who is accountable for what the agent did. The answer has to be a person, not a process.
Architectural Frameworks
3.7 was the positioning article. The argument: identity infrastructure positioned as a login provider is underutilized in an agentic world. The control plane framing is where to take the conversation.
Control plane — The layer of infrastructure that governs what agents are allowed to do, as distinct from the data plane where they do it. Identity infrastructure is the natural control plane for agentic systems. When it comes up: When you're repositioning from "the thing that handles SSO" to "the thing that decides what every agent in the environment is allowed to do." Don't confuse with: API gateway. An API gateway enforces policy at the network layer. A control plane sets the policy — it's upstream of enforcement.
MCP (Model Context Protocol) — An emerging standard for how AI agents communicate with tools and services, with identity and authorization implications that are still being worked out in the spec. When it comes up: When a technically sophisticated buyer asks how agent authorization integrates with their AI infrastructure. MCP is where the conversation about standardization currently lives. Don't confuse with: A finished standard. MCP's authorization model has open questions. The spec exists; the implementation patterns are still forming.
If you remember nothing else: Every AI deployment needs a control plane. The question is whether identity infrastructure owns it or whether the AI team builds one ad hoc.
Vocabulary Mapping
| AI Term | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Agent identity | A principal representing an autonomous AI agent's actions in a system | Service account | Service accounts are static and infrastructure-bound; agent identities are dynamic and task-scoped, potentially provisioned and deprovisioned within a single workflow |
| Agent authorization | The permissions an agent holds to act on behalf of a user or system, often persisting across sessions | OAuth delegation | OAuth delegation assumes a user authorizes a specific scope at a specific moment; agent authorization may persist across sessions and tasks without the user present |
| JIT elevation | A runtime permission grant that activates when needed and expires when the task completes | Least privilege | Least privilege is a design principle applied at provisioning; JIT elevation is the runtime mechanism that implements it for workloads where access needs are unknown in advance |
| Agent trace | A structured record of an agent's decision path, tool calls, and data access | Audit log | Audit logs record that an event occurred; agent traces record the reasoning that produced it — the distinction matters for incident response and for regulators who want to know what decision drove the action |
| Workload identity | In AI contexts, often used interchangeably with agent identity — incorrectly | Machine identity / service account | Workload identity is scoped to infrastructure components (containers, VMs, functions); agent identity is scoped to tasks and workflows. Conflating them produces governance gaps when agents outlive the infrastructure they run on |
| Non-repudiation (agent) | The ability to attribute a specific agent action to a specific human principal after the fact, through the full delegation chain | Non-repudiation (user) | In human systems, non-repudiation is well-understood; in agent systems, the delegation chain complicates attribution — the agent acted, but tracing accountability back to a human requires the full chain to be logged and intact |
Source Index
Ordered by how often the concept comes up in discovery — not by section number.
3.7 — "Control Plane or Login Provider? Positioning Identity Architecture for AI" Useful for: Repositioning conversations. Read this before any call where you expect to spend time explaining why identity infrastructure is relevant to an AI initiative. The control plane framing is the one that lands with both technical buyers and their leadership.
3.4 — "Blast Radius: Attack Surface Expansion in Multi-Agent Architectures" Useful for: Security-led conversations and calls where a CISO or security architect is in the room. The blast radius concept makes the risk concrete without requiring the buyer to understand agent architecture first.
3.2 — "The Delegation Chain: How AI Agents Authenticate and What Goes Wrong" Useful for: Technical buyers who are already building agentic workflows. It explains why their current approach (service accounts, static credentials) breaks down at scale.
3.3 — "Scope Creep at Scale: Permission Management in Agentic Workflows" Useful for: Governance and least-privilege conversations. The JIT elevation framing gives you a concrete mechanism to point to, not just a principle to invoke.
3.5 — "The Accountability Gap: Why Audit Logs Weren't Built for Agents" Useful for: Regulated-industry accounts. The gap between audit logs and agent traces is one that compliance teams haven't thought through yet — and it's a gap that opens a real conversation about what "accountability" means when the actor is a machine.
3.6 — "Agent Traces and the Non-Repudiation Problem" Useful for: Follow-on to 3.5. Read this if the accountability conversation goes deep — specifically if the buyer starts asking about incident response or regulatory examination scenarios where someone needs to answer for what the agent did.
3.1 — "Who Speaks for the Agent? Provisioning Machine Identity in Agentic Systems" Useful for: Calls where the buyer is early in their AI journey and hasn't thought about agent governance at all. It establishes why the problem exists. Use it when you need to slow a conversation down.
The Call Posture
Every AI capability a buyer is excited about is also an authorization problem they have not fully thought through yet — and that is where the conversation goes next.
Not as a warning. As an opening.