Agent identity is the least glamorous decision in an agentic build and the one most likely to hurt you later: when an AI agent runs on a human’s borrowed session, API key, or OAuth token, every action it takes is legally and forensically that person’s action, its access is whatever that person accumulated over years, and the only off switch also switches off the human.
This is not a hypothetical concern for some future fleet of autonomous agents. It is the default state of most agent deployments right now, because the fastest way to get an agent working is to paste in a key that already works. The infrastructure world spent the last decade solving the same problem for services — short-lived certificates, token exchange, federation — and in 2026 the major identity vendors began shipping agent-specific versions of that machinery.
This playbook covers why borrowed credentials fail, why agents are a third identity category distinct from both humans and classic service accounts, the named mechanisms that already exist (SPIFFE and SPIRE, workload identity federation, GitHub App installation tokens, AWS IAM Roles Anywhere, RFC 8693 token exchange), and a decision matrix that maps five agent access patterns to an identity mechanism, a revocation path, and an audit granularity. It pairs with our agentic RBAC design patterns guide deliberately: RBAC governs what an identity may do once it exists — this post is about how that identity gets issued, scoped, rotated, and revoked in the first place.
Key takeaways
- 01
Borrowed credentials fail three ways at once.An agent on a human’s session or API key mis-attributes every action to a person, runs over-scoped by default, and cannot be revoked without locking that person out of their own accounts.
- 02
Agents are a third identity category.Not human, not classic service account. Microsoft’s Entra documentation now carves agents out explicitly: they make dynamic decisions and adapt behavior, so identity must be issued per run and scoped per task.
- 03
The mechanisms already exist and are shipping.SPIFFE/SPIRE issues auto-rotating SVIDs on workload attestation; workload identity federation eliminates key files; GitHub App tokens expire in 1 hour; AWS IAM Roles Anywhere trades an X.509 cert for 15-minute-to-12-hour credentials.
- 04
Delegation is not impersonation — RFC 8693 encodes the difference.Token exchange carries a subject token (who the work is for) and an actor token (who is doing it), plus an audience parameter that restricts where the minted token is valid. Agent chains need all three.
- 05
Audit must name the run, not the bot.A log line that says ‘the automation user did it’ is not reconstructible after an incident. Per-run correlation IDs, actor-plus-subject pairs, and parent-child lineage for sub-agents are the bar — with revocation measured in minutes.
01 — The Failure ModeBorrowed credentials fail three ways at once.
Walk through what actually happens when an agent inherits a human’s credentials — a session cookie lifted from a browser profile, a personal API key pasted into an environment variable, or an OAuth token granted to “you” that a background process now replays.
First, attribution collapses. Every record the agent creates, every email it sends, every deletion it performs is logged as the human whose credential it holds. When something goes wrong at 2 a.m. on a Saturday, the audit trail points at a person who was asleep. There is no way, from the logs alone, to separate what the human did from what the agent did — which means there is no way to scope an incident, satisfy a compliance review, or defend the human.
Second, scope is inherited, not designed. A human account accumulates access over years — old projects, admin roles granted for one migration and never removed, personal repositories next to production ones. The agent gets all of it. The task needed read access to one CRM module; the credential carries write access to the entire org. Classic personal access tokens are the sharpest version of this: before fine-grained scoping, a single token could reach every repository its owner could.
Third, revocation takes the human down too. The only way to cut off an agent holding your session or key is to kill the session or rotate the key — locking you out of your own accounts mid-incident, breaking every other integration that shared the credential, and turning a contained problem into an outage. Anything that cannot be revoked independently was never really under control.
And the definition of “credential” is wider than most teams assume. This week’s Amp release made the point concretely: a durable webhook URL that triggers an agent functions as a credential — anyone holding the URL can invoke the agent — which is why Amp’s own docs treat those URLs as secrets and sign the payloads, as we covered in our breakdown of Amp’s event-driven orbs. Identity for agents is not just “which API key” — it is every artifact that grants the power to act.
The trap in one sentenceA borrowed credential makes the agent indistinguishable from its human — which is precisely the property you never want. Attribution, scoping, and revocation all depend on the agent being a separate, named principal whose access can be granted, narrowed, and destroyed without touching anyone else.
02 — Identity TaxonomyAgents are a third identity category.
Most 2026 coverage lumps everything non-human into one “non-human identity” bucket. That framing hides the decision that matters. In practice there are three categories with different lifecycles, and the tooling built for the first two fails on the third.
The scale problem is real regardless of whose count you trust. Per the Cloud Security Alliance’s May 2026 whitepaper on non-human identity governance, non-human identities — service accounts, API keys, OAuth tokens, machine certificates, agent credentials — outnumber human users by an average of 45:1 across enterprises, rising to 144:1 in cloud-native environments. Worth noting: different summaries of the CSA’s own research circulate different headline figures for this problem, which is itself a tell for how unsettled the industry’s accounting of its non-human population still is. Treat any single ratio as directional; the direction is unambiguous.
Microsoft’s Entra documentation puts the operational gap plainly: “It’s also hard to track when a workload identity is created or when it should be revoked.” That sentence describes classic service accounts. Agents make it worse, and Microsoft now says so explicitly — its workload-identity docs carve out AI agents as a distinct category of machine identity: “Unlike traditional workloads that execute predetermined logic, AI agents make dynamic decisions and adapt behavior.”
Category 01
Human identity
Interactive · MFA · session-bound
Built around a person who can answer a prompt: passwords, MFA challenges, conditional access, re-authentication on risk signals. None of that machinery fires when the caller is a process — there is nobody to approve the push notification.
Traditional IAM’s home turf
Category 02
Service account
Long-lived · few · rarely rotated
Predetermined logic, stable scope, a handful per system. The classic failure is the forgotten key — powerful, unowned, unrotated for years — but at least the behavior behind it is static and reviewable.
Classic non-human identity
Category 03
Agent identity
Dynamic · many · issued per run
Agents decide what to do at runtime, spawn sub-agents, and multiply faster than any review cycle. Identity has to be issued per run, scoped per task, expire on its own, and die without collateral damage to a human or a fleet.
Entra Agent ID · CSA agentic IAM
The vendor proof that this third category is real: Microsoft Entra Agent ID — documentation first published April 14, 2026 and updated June 24, 2026 — is a shipping identity framework specifically for AI agents, layered on Entra, speaking OAuth 2.0, MCP, and A2A. Its design choices read like a checklist of everything borrowed credentials get wrong: “agent identity blueprints” mint individual agent identities from templates with tracked parent-child relationships, so one policy governs every instance spawned from the same template; third-party agents built on non-Microsoft platforms — Microsoft names AWS Bedrock and n8n — can be brought under the same governance via an auth SDK sidecar or standard workload identity federation. Licensing is its own snapshot-in-time detail (full functionality sits behind Microsoft 365 E7 or an E5 add-on, with standalone Entra tiers below that), but the architectural signal matters more than the packaging: Microsoft decided agents need their own principal type.
The same conclusion is coming from the standards side. NIST’s zero-trust architecture guidance treats every machine-to-machine call as requiring explicit authorization regardless of network position — no implicit trust for being “inside the VPC” — which is the baseline assumption every mechanism in the next section builds on.
03 — Named MechanismsThe mechanism shelf: short-lived beats long-lived, everywhere.
None of this requires inventing anything. Four families of mechanism, all shipping today, already issue exactly the kind of credential an agent should hold: short-lived, workload-scoped, audit-attributable, and revocable on their own.
SPIFFE / SPIRE — identity from attestation, not secrets
SPIFFE (Secure Production Identity Framework For Everyone) issues short-lived cryptographic identity documents called SVIDs — X.509 certificates or JWTs — to workloads. The decisive property is that issuance is tied to workload attestation: SPIRE verifies what the workload actually is at runtime, rather than trusting whoever holds a pre-provisioned secret. SVIDs rotate automatically, and trust domains can federate across organizations. For agents, that means the identity follows the running process, not a string in an env file.
Workload identity federation — the end of the key file
Google Cloud’s workload identity federation lets an external workload — on-prem, another cloud, a CI/CD runner, an AI agent — present a credential from its own identity provider, which Google’s Security Token Service validates and exchanges for a short-lived Google Cloud token. No long-lived service-account key file is ever distributed. It federates against AWS, Azure, Active Directory, GitHub and GitLab OIDC, Kubernetes, Okta, and any generic OIDC or SAML 2.0 provider, and supports both direct IAM grants to the federated identity and service-account impersonation.
"Service account keys are powerful credentials, and can present a security risk if they are not managed correctly."— Google Cloud IAM documentation, workload identity federation
AWS IAM Roles Anywhere — certificates in, sessions out
AWS’s version replaces the long-lived Access Key ID and Secret Access Key pair with an X.509 certificate presented by the workload, exchanged for temporary STS credentials valid from 15 minutes up to 12 hours. The supporting Credential Helper is under active development inside this year’s window — v1.8.0 (March 5, 2026) added ML-DSA post-quantum signature support, and v1.8.4 (June 9, 2026) patched security vulnerabilities — a useful signal that cert-based machine credentials are a maintained, first-class path, not a legacy corner.
GitHub App installation tokens & fine-grained PATs
GitHub offers the most concrete everyday example. A GitHub App installation access token expires one hour after issuance, can never exceed what the app itself was granted, and can be scoped down further at request time — to a subset of repositories (up to 500) and a subset of permissions. GitHub has also introduced a stateless installation token format that replaces the old opaque 40-character string with a self-describing, verifiable credential. Fine-grained personal access tokens complete the picture for human-adjacent automation: 30-day default expiry, extendable to 366 days (or “never,” where org policy permits), scoped to a single user or org and to named repositories — unlike classic PATs, which granted blanket access to everything their owner could reach.
Two adjacent playbooks pair with this shelf. Rotation cadence and storage for whatever secrets remain is covered in our secrets management and API key rotation reference, and for a concrete consumer-facing version of “hand the agent a scoped credential instead of your login,” see how 1Password brokers credentials for agentic browsing.
GitHub App token
Installation token lifetime
1hr
Expires one hour after issuance, capped at the app’s own grants, and downscopable at request time to specific repositories (up to 500) and permissions.
Stateless verifiable format
AWS IAM Roles Anywhere
Minimum session lifetime
15min
An X.509 certificate is exchanged for temporary STS credentials valid from 15 minutes to 12 hours. No long-lived access-key pair is ever distributed.
Helper v1.8.4 · Jun 2026
Fine-grained PAT
Default expiration
30d
Scoped to one user or org and to named repositories and permissions; extendable to 366 days, or ‘never’ where org policy allows — versus classic PATs’ blanket reach.
Classic PATs: blanket access
04 — On-Behalf-OfDelegation is not impersonation.
The hardest agent-identity case is the most common one: an agent acting on behalf of a specific human. Get this wrong and you are back to the borrowed-credential trap with extra steps. The formal machinery for getting it right has existed since January 2020: RFC 8693, OAuth 2.0 Token Exchange — a Standards Track RFC defining an HTTP/JSON protocol for trading one security token for another.
RFC 8693 draws exactly the distinction this post is about. Impersonation means the new token’s holder becomes indistinguishable from the original subject, taking on all of its rights — the protocol-level formalization of the trap in Section 01. Delegation means the acting party keeps its own separate identity while exercising rights granted by the subject — it acts as an agent of the subject rather than becoming it. The request format encodes the difference structurally: a required subject_token identifies who the request is on behalf of, and an optional actor_token identifies who is actually making the call. Both identities survive into the minted token, which is what makes the downstream audit trail reconstructible.
The third piece is the audience parameter: the client names the specific downstream service the token is being requested for, and the authorization server mints an audience-restricted token valid there and nowhere else. An agent that needs to read a calendar gets a token the CRM will reject. Notably, RFC 8693 leaves the token formats themselves out of scope — it is a protocol shell, which is why Google, Microsoft, GitHub, and HashiCorp each implement the pattern with their own token types. The pattern transfers; the strings do not.
On the broader OAuth front, precision matters: OAuth 2.1 is still a draft, not a ratified RFC. It consolidates OAuth 2.0 with PKCE and native-app guidance, removes the implicit grant entirely, eliminates the resource-owner password grant, and makes PKCE mandatory for every authorization-code client. Directionally it is where agent-facing OAuth deployments should already be — but cite it as a draft, because that is what it is.
The Cloud Security Alliance’s agentic IAM paper (August 2025) pushes one step further for multi-agent systems: Decentralized Identifiers plus Verifiable Credentials as the identity anchor, with just-in-time credentials valid for narrow windows — its worked example is a 15-minute credential scoped to a single action on specific resources. Its rationale is the same gap RFC 8693 exists to close: traditional OAuth and SAML assumptions fall short because they lack secure, traceable delegation where agents act on behalf of users while keeping accountability chains intact — a gap that off-the-shelf OAuth deployments frequently leave unwired for agent chains even though the spec support exists.
Where RBAC fitsThese are complementary layers, not competing ones. This playbook covers how an agent identity is
issued, scoped, rotated, and revoked. Our
agentic RBAC design patterns post covers what that identity may
do once it exists — roles, permission boundaries, and approval gates. You need both: perfect RBAC on a borrowed credential still mis-attributes every action, and a perfectly-issued identity with sloppy permissions is just a well-labeled skeleton key.
05 — Decision MatrixFive access patterns, one table.
Vendor documentation explains each mechanism in isolation; nobody lines them up against the access patterns real agent deployments actually have. The matrix below is our mapping: for each of the five ways an agent typically obtains access, the identity mechanism that fits, the credential lifetime you should expect, the revocation path when something goes wrong, and the audit granularity you get for incident reconstruction.
Agent identity decision matrix: five agent access patterns mapped to the identity mechanism that fits, typical credential lifetime, revocation path, and audit granularity. Compiled by Digital Applied from GitHub, Google Cloud, AWS, Microsoft Entra, SPIFFE, IETF RFC 8693, and Cloud Security Alliance documentation, retrieved July 2026.| Access pattern | Identity mechanism | Typical credential lifetime | Revocation path | Audit granularity |
|---|
| CI/CD pipeline agent | Workload identity federation over OIDC, or a GitHub App installation token | ~1 hr (installation token); STS-issued short-lived | Disable the app installation or the federation pool — no shared secret to hunt down and rotate | Per-run correlation: pipeline run ID tied to each token issuance |
|---|
| Human-delegated agent | RFC 8693 token exchange: subject token + actor token, audience-restricted | Session-bound; expires with the delegation | Invalidate the user’s subject token or the agent’s actor token independently — neither locks out the other | Actor-plus-subject pair recorded on every downstream call |
|---|
| Autonomous scheduled agent | Its own workload identity: SPIFFE/SPIRE SVID or a cloud-managed identity, issued on attestation | Minutes to hours; SVIDs rotate automatically | Revoke the SVID or deny the attestation — no human account is touched | Per-certificate serial / per-invocation identity in every log line |
|---|
| Sub-agent spawned by a parent | Child identity with a verifiable link to the parent (CSA delegation chains; Entra agent identity blueprints) | Per-task; CSA’s worked example is a 15-min window | Kill the child credential without touching the parent — or revoke the parent to invalidate the chain | Per-child ID with parent lineage — multi-agent incidents stay reconstructible |
|---|
| Third-party / webhook-triggered agent | Signed webhook payload verified at ingress, then exchanged for a short-lived, downscoped token | Per-invocation | Rotate the webhook secret; deny-list the compromised signature | Per-payload signature hash plus the issued-token record |
|---|
Two readings of this table are worth making explicit. First, the lifetime column trends toward zero as autonomy rises: the less a human is in the loop at trigger time, the shorter the credential should live, because there is nobody watching to notice misuse in real time. Second, every revocation path in the table shares one property — it never requires locking a human out. That is the single test that tells you whether an agent has its own identity or is wearing someone else’s.
06 — Kill SwitchesRevocation in minutes, audit by the run.
Issuing the right credential is half the job. The other half is being able to destroy it fast and reconstruct what it did. The CSA’s May 2026 whitepaper sets a concrete bar for the first part: time-to-revoke measured in minutes, achieved through pre-authorized, automated revocation workflows triggered by exposure signals — not a ticket in a queue waiting for someone to manually deprovision an account. Its broader governance model has three parts: formal identity lifecycle management with assigned ownership for every non-human identity, zero standing privilege (just-in-time, task-scoped access with automatic expiry), and cryptographic workload attestation — naming SPIFFE/SPIRE specifically as the replacement for static API keys.
On the audit side, the bar is attribution to a specific agent run. A log line saying that the automation user did a few thousand things last Tuesday is not an audit trail; it is a confession that you cannot reconstruct the incident. The mechanisms in this playbook each carry their own answer — correlation IDs on CI runs, actor-subject pairs on delegated calls, certificate serials on SVIDs, lineage links on sub-agents, signature hashes on webhook invocations — and the vendor platforms are converging on the same requirement: Microsoft’s Entra Agent ID documentation states: “All agent authentication and activity is logged for compliance and audit.” It ships a dedicated agent sign-in and audit log surface, separate from human sign-in logs. What to actually record, and how to structure it so it survives an incident review, is the subject of our agent audit trail design guide.
CSA on multi-agent accountabilityThe Cloud Security Alliance’s agentic IAM guidance is blunt on the two rules that keep agent fleets governable: “Grant agents only the minimum access required for their specific task.” And for the multi-agent case: “Sub-agents spawned by a parent agent are separate instances, each with a unique ID, but with a verifiable link back to the parent.” Unique identity per instance, cryptographic lineage across the chain. That combination is what turns a swarm incident from an anonymous blob into a reconstructible sequence.
07 — ImplementationA pragmatic rollout order.
You do not need SPIFFE in production by Friday. The failure mode to avoid is the opposite one: treating agent identity as a someday project while agents multiply on borrowed keys today. The sequence below is the order we use in client engagements, cheapest and highest-leverage first.
Week one
Inventory before mechanism
List every credential an agent currently holds — keys, tokens, sessions, and webhook URLs (they count). For each: whose is it, what can it reach, who owns its lifecycle, and how would you revoke it alone. The unowned entries are your risk register.
Start with ownership
First replacement
Kill the long-lived keys
CI/CD and cloud access convert fastest: swap stored secrets for OIDC-based workload identity federation and GitHub App installation tokens. No agent rewrite required — the platform mints short-lived credentials and the pasted keys get deleted.
Federation + app tokens
Human-delegated agents
On-behalf-of, audience-restricted
Where an agent acts for a specific user, move to RFC 8693-style token exchange: subject token plus actor token, audience-restricted to the one service the task needs. The agent stops being the user and starts acting for the user — visibly, in every log.
Token exchange
Multi-agent systems
Lineage from day one
Give every spawned sub-agent its own identifier with a verifiable link to its parent, and pre-authorize the revocation workflow before you need it. Retrofitting lineage onto a running fleet after an incident is the expensive version.
Parent-child IDs
The interpretive point behind the sequence: agent identity is following the same arc service identity followed a decade ago, but compressed. Static keys gave way to short-lived certificates and federation for services over roughly ten years of painful migrations; agents are being pushed down that same path in quarters, not years, because the population is growing at machine speed and the actors behind the credentials make their own decisions. Our projection is that within a few product cycles, “give the agent its own identity” stops being an architecture choice and becomes a platform default — Entra Agent ID’s blueprints and GitHub’s stateless verifiable tokens are early versions of exactly that — and the differentiator shifts to the operational layer: who owns each identity, how fast revocation fires, and whether the audit trail names runs or blobs.
This matters most where agents touch systems of record. A CRM agent that can rewrite pipeline data on a borrowed admin login is the exact scenario the borrowed-credential trap describes — which is why identity design is part of every build in our CRM automation practice, and why broader agent governance — identity, permissions, audit, rollback — anchors our AI transformation engagements. The teams that get this right early ship agents faster, not slower, because every new agent lands on rails that already exist.
08 — ConclusionThe test is revocation.
Agent identity, July 2026
If you can’t revoke the agent without locking out a human, the agent doesn’t have an identity.
Everything in this playbook compresses into that one test. Borrowed credentials fail it by construction: attribution points at a person, scope was accumulated rather than designed, and the kill switch takes the human down with the agent. Separate, per-run identity passes it — and the machinery is not speculative. SPIFFE SVIDs, workload identity federation, GitHub App installation tokens, AWS IAM Roles Anywhere, and RFC 8693 token exchange are all shipping, documented, and in production at scale for services already.
The direction of travel is unambiguous even where the statistics are not. Non-human identities already outnumber humans by an order of magnitude on any count in circulation, the major identity vendors have begun treating agents as their own principal type, and the industry bodies converge on the same three-part prescription: owned lifecycles, zero standing privilege, and attestation-based issuance. What is still scarce is teams actually wiring it up before the incident instead of after.
Start with the inventory, kill the long-lived keys, and make every new agent land on its own identity by default. The cost is a few unglamorous engineering days now. The alternative is explaining to an auditor why the log says a sleeping employee deleted the production data — and why turning the agent off also turned off the employee.
![\"Google](\"https://www.gstatic.com/devrel-devsite/prod/v303cfab58e2ecfbd382191434137bc118fc92bc795e9241c9d005d07c4d0550a/clouddocs/images/lockup_dark_theme.svg\"\n)
\n ![\"\"\n](\"https://docs.cloud.google.com/_static/clouddocs/images/icons/categories/security-and-identity-color.svg\"\n){kind=icon}
\n