Erik Caldwell
Connect on LinkedIn
Menu

The Topic Catalog · 14

Agent Identity & Authorization

Last updated · 8 min read

14.1 Non-Human Identity & Workload Identity for Agents

Priority: Must Understand

Executive Definition: Non-Human Identity (NHI) and workload identity are the discipline of giving every AI agent, service account, and automated workload its own cryptographically verifiable identity (distinct from any human user's identity) so that every action an agent takes can be tied to a specific, authenticated, and revocable identity rather than a shared API key or a borrowed human credential. This is the foundational layer beneath the strategic question every executive must be able to answer: who authorized this AI to take this action, with this data, using these systems, at this time?

Why It Matters: Most enterprises already have more non-human identities (service accounts, API keys, bots) than human ones, and agentic AI is accelerating that ratio sharply: each agent, sub-agent, and tool connection is a new identity that needs provisioning, credential rotation, and offboarding, typically without a mature governance process behind it. Treating an agent as "just another service account using a shared key" collapses the ability to attribute, scope, or revoke its access independently, which is precisely what an incident response process needs to do quickly.

What I Need to Understand:

  • The core requirement is a unique, verifiable identity per agent (not per application, not shared across agents) so that authentication, authorization, and audit logs can all resolve to a specific actor.
  • Open standards are emerging specifically for workload identity, the Secure Production Identity Framework for Everyone (SPIFFE) and its runtime implementation SPIRE, and are being extended to cover AI agents, alongside vendor-specific offerings such as Microsoft Entra Agent ID, which issues and manages identities for agents the way Entra ID does for human users.
  • Agent identity needs a lifecycle like human identity: provisioning, credential rotation, permission review, and deprovisioning when an agent or its task is retired: most organizations currently have no formal process for any of these stages for agents.
  • Delegation matters: an agent frequently needs to act "on behalf of" a specific human user, which requires the agent's own identity to be distinguishable from, but linkable to, the human who authorized it (see Delegated Authorization topic).
  • This is a governance gap today, not a solved problem: most enterprises can enumerate their human users far more completely than they can enumerate their active AI agents and what each one can access.

Questions I Should Be Able to Ask My Team:

  1. Can we produce a complete inventory today of every AI agent operating in our environment and the distinct identity/credentials each one uses?
  2. When an agent takes an action, does our logging capture the agent's own identity, or only a shared service-account or API-key identity that could belong to any of several agents?
  3. What is our process for revoking a single compromised or retired agent's access without disrupting every other agent that shares its credentials?

Technologies / Standards / Companies to Know: SPIFFE/SPIRE (open standard for workload identity, CNCF); Microsoft Entra Agent ID; HashiCorp Vault (workload identity integration); broader "non-human identity" (NHI) security vendor category (e.g., Astrix, Entro, Token Security).

Recommended Learning:

Time Investment: 1 hour

14.2 Delegated Authorization, OAuth & Just-in-Time Access

Priority: Should Understand

Executive Definition: Delegated authorization is the mechanism by which an agent is granted permission to act on a specific human's or system's behalf: using standards like OAuth 2.1 rather than embedding a standing credential in the agent itself: scoped to a specific task and time window rather than granted as a permanent, broad credential. Just-in-time (JIT) access extends this by granting elevated permission only for the duration of a specific approved action, then automatically revoking it. Together these are the practical answer to: who authorized this AI to take this action, with this data, using these systems, at this time?: because the authorization is explicit, scoped, time-bound, and attributable to a human or policy decision.

Why It Matters: The default failure mode in early agent deployments is over-broad, standing credentials: an agent given a long-lived API key with wide scope "to make things work," which then becomes the blast radius if the agent is hijacked or the credential leaks. OAuth-based delegation and JIT access shrink that blast radius to the specific task, the specific human who authorized it, and the specific time window, and both the MCP authorization specification and enterprise IT are actively converging on this pattern as the expected baseline in 2026.

What I Need to Understand:

  • Delegated authorization means the agent gets a scoped, revocable token tied to a specific user's consent for a specific purpose: not the user's actual password or a permanent admin key.
  • Just-in-time access means the elevated permission exists only for the window needed to complete the approved action, then expires automatically, rather than persisting indefinitely on the chance it's needed again.
  • The MCP specification has its own evolving authorization framework (built on OAuth 2.1 patterns) governing how MCP clients and servers negotiate what an agent is allowed to do: know whether your MCP integrations implement current-generation authorization or none at all.
  • Multi-agent and multi-tool systems raise a specific delegation problem: when Agent A calls Agent B which calls a tool, whose authorization applies at each hop, and does the original human's consent scope carry through correctly: this "chained delegation" is an active design challenge, not a solved one.
  • This is the layer where the strategic question becomes operational: a well-designed system should be able to answer, for any single agent action, exactly which human or policy decision authorized it, with what data scope, and for how long.

Questions I Should Be Able to Ask My Team:

  1. For each of our agents, is access granted as a standing credential or as a scoped, time-bound, delegated token tied to a specific authorization event?
  2. Do our MCP or tool integrations implement current OAuth-based authorization, or are they relying on static API keys with broad, undifferentiated scope?
  3. In a multi-agent workflow, can we trace a downstream tool call back to the original human authorization that should have scoped it, or does delegation get "flattened" into a shared service identity somewhere in the chain?

Technologies / Standards / Companies to Know: OAuth 2.1 and the IETF OAuth working group; Model Context Protocol authorization specification; enterprise identity providers extending delegated-access patterns to agents (Microsoft Entra, Okta, Auth0/Okta CIC).

Recommended Learning:

Time Investment: 2-3 hours

14.3 Least Privilege, Transaction Limits & Audit Attribution

Priority: Must Understand

Executive Definition: This is the operational discipline that turns identity and delegated authorization into enforceable controls: scoping every agent to the minimum permissions it needs (least privilege), capping the size or consequence of any single autonomous action (transaction limits), and ensuring every action an agent takes is logged with enough detail to answer, after the fact, exactly who and what authorized it (audit attribution). It is the last line of defense when prevention fails: the control that limits damage and enables accountability once an agent has been hijacked or has erred.

Why It Matters: Security shifts fundamentally once AI systems can act rather than merely generate text: a wrong sentence in a chat is a quality problem, but an agent with unnecessary write access to a financial system, an uncapped ability to send emails or move funds, or actions logged only under a shared service account is an incident waiting to happen with no clean way to trace it back. These three controls are what make the answer to "who authorized this AI to take this action, with this data, using these systems, at this time?" something your organization can actually produce on demand, rather than a question you can only ask rhetorically after the fact.

What I Need to Understand:

  • Least privilege for agents means scoping to the specific task, not the broadest role a human in that job function might plausibly need: an agent's permission set should typically be narrower than the equivalent human employee's, because it acts without the judgment a human would apply in ambiguous cases.
  • Transaction limits (dollar caps, rate limits, record-count limits, requiring human approval above a threshold) bound the damage a single hijacked or erroneous agent action can cause, independent of whether the underlying prompt injection or goal hijacking was caught.
  • Audit attribution requires that logs capture the specific agent identity, the specific delegated authorization that permitted the action, the data accessed, and the time (not just "the AI system did X") or post-incident investigation and regulatory response both stall.
  • Industry frameworks (e.g., Fintech Open Source Foundation (FINOS)'s Agent Authority Least Privilege Framework, aimed at financial services) are starting to formalize this as a control category with concrete mitigations, not just a best-practice slogan.
  • These controls should be treated as mandatory for any agent with write access to production systems, financial systems, or customer data: read-only or low-consequence agents warrant a lighter touch, and over-applying heavy controls everywhere slows adoption without improving actual risk posture.

Questions I Should Be Able to Ask My Team:

  1. For our highest-risk agents (financial, customer data, production systems), what is the actual permission scope granted versus the minimum the task requires, and who last reviewed that gap?
  2. What hard transaction or action limits exist for each agent that can take a consequential action, and what happens when that limit is hit: does it fail safe or escalate to a human?
  3. If asked today, could we produce a complete audit trail for any single agent action, showing the specific agent identity, the authorization that permitted it, and the data touched, or would that investigation hit a dead end at a shared credential or generic log entry?

Technologies / Standards / Companies to Know: FINOS AI Governance Framework (Agent Authority Least Privilege Framework); Microsoft Entra Agent ID (permission scoping and tool binding); enterprise SIEM/logging platforms extended to capture per-agent audit trails.

Recommended Learning:

Time Investment: 2-3 hours