Giving Agents Their Own Identity, Not Your Credentials

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.

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.

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.”

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.

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.

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.

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.

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.

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.

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.

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.

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.