Non-Human Identity for AI Agents: Workload ID + Tokens 2026

Q: What exactly is a non-human identity, and why has it become the 2026 problem?

A non-human identity (NHI) is any principal in your systems that is not a human — a service account, a workload identity, an OAuth client, an API key, a machine certificate, an agent runtime. NHI has existed forever, but 2026 is the year it became the top enterprise security priority for three reasons. First, the multiplier: an agent runtime in 2026 has fifty to several hundred tool integrations, and the same agent process serves dozens of users in parallel — the blast radius of a single shared admin credential is now enormous, where in 2022 a microservice with three downstreams was a manageable risk. Second, the lifecycle: agents act on tasks lasting minutes to hours, and their credentials must rotate every few minutes for short-lived TTL to be the security guarantee — the quarterly rotation cadence that just-about-survived microservices is dangerous for agents. Third, the breach data: Astrix, Oasis, Entro, and Token raised mega-rounds in late 2025 and Q1 2026 specifically because every CISO knows their NHI inventory is wrong; the OWASP NHI Top-10 released January 2026 reads like a list of incidents enterprises have already had; Cloudflare's January 2024 incident and several 2025 SaaS-supply-chain incidents traced back to leaked or over-scoped non-human credentials. The architectural answer is the same shape as workload identity for microservices but extended for two new properties: on-behalf-of-user delegation, and per-task capability-token mint. This piece walks through the full reference architecture.

Q: Should the agent act as its own principal or on behalf of the user, and what determines the choice?

Almost always both, simultaneously, with the choice made per task. Agent-as-principal is the right shape for infrastructure-class agents — nightly reconciliation agents, security-monitoring agents, CI/CD agents — where there is no originating user and the agent is the principal. The credential carries only the agent's identity and authorises against the agent's allowed-scope envelope. On-behalf-of-user is the right shape for user-facing agents — a sales-engineer agent acting for a specific salesperson, a finance agent acting for a specific accountant — where downstream services must authorise against the user's permissions, not the agent's, and the audit log must attribute the action to the originating user. The OAuth 2.0 token-exchange (RFC 8693) flow with the `act` actor claim encodes this: the token has the user's effective scope, but the agent appears as a co-principal in the JWT. Hybrid is the production reality — the same agent runs both modes, dispatched by the task descriptor at the planner-to-executor boundary. The wrong answer, and the one almost every early-stage team picks, is agent-only with admin scopes — because it is so much easier to give the agent admin Salesforce than to plumb on-behalf-of through every flow. The reason you do the harder thing is that the easier thing is what the breach narrative ends with: every action attributed to "the agent", no per-user blast-radius bound, no compliance attribution.

Q: What is a capability token, and what claims must it carry?

A capability token is a short-lived JWT — typically TTL ≤ 5 minutes — that the agent presents to a downstream service to authorise a single specific task. Five claims do the architectural work. The `sub` claim is the agent's workload identity (the SPIFFE ID, the Entra AppRegistration object ID, the GCP service account email). The `act` claim (RFC 8693 actor claim) is the user the agent acts on behalf of, present only in on-behalf-of mode. The `scope` claim is the explicit list of tools and resources this token is good for, derived by the policy engine from the task descriptor — not a static envelope, but per-task. The `exp` claim is in the next 5 minutes. The `aud` claim names the specific downstream service — a token for Salesforce is not good for Stripe, even when the agent has scope on both. The runtime never decides scope: the agent runtime presents its workload-identity assertion plus the user's delegation token plus the task descriptor to the STS, and the STS — in concert with the policy engine — mints the token at the minimum scope policy permits. If the agent's planner has been steered by injection into asking for scope outside the task envelope, the policy engine refuses, the executor never gets a token, and the lateral move is logged. The 5-minute TTL covers ≈95% of agent traffic without mid-task refresh complexity, is short enough that a stolen token expires before an attacker can chain it, and is supported by every modern identity provider.

Q: How does workload identity (SPIFFE / WIF / IRSA) actually work, and what does it replace?

Workload identity replaces the long-lived credential the runtime holds (env vars, mounted secrets, embedded API keys) with a short-lived assertion derived from attested platform properties. SPIFFE/SPIRE is the canonical implementation: the SPIRE agent on each node attests properties of the running workload (Kubernetes namespace + service account + pod label, Nomad allocation, AWS instance role, GCP service account binding) to the SPIRE server, which issues an X.509 SVID or JWT-SVID identifying the workload. The workload presents this identity to anything that needs to authenticate it — the secrets manager, the STS, an mTLS-protected upstream service — and that thing validates the identity against the SPIRE trust bundle. The identity is short-lived (typically 1 hour with auto-rotation), so theft of the assertion has a small window. Cloud-native equivalents do the same shape: Azure Workload Identity Federation lets a Kubernetes-pod-issued OIDC token federate to an Entra App Registration; GCP Workload Identity Federation lets external workloads (GitHub Actions, Auth0, AWS) federate to a GCP service account; AWS IAM Roles Anywhere lets workloads outside AWS present an mTLS certificate from a private CA and assume an IAM role. What workload identity replaces is the long-lived secret entirely — the runtime never holds a credential it can leak, only an identity that unlocks credentials at task boundary. This is the foundational primitive of NHI Stage 2; without it, no other pattern in this architecture is durable.

Q: How do I actually shrink the scope of an existing over-scoped agent without breaking it?

Shrink incrementally with telemetry, not by guesswork. The empirical method is four-stage. First, instrument: log every tool call the agent makes with the tool name, resource pattern, and downstream result — 30 days of production traffic gives you the actual usage profile. Second, derive the minimum-viable scope from the usage data: the policy engine config that includes only the tool-and-resource pairs the agent actually exercised, plus a small allowance for known periodic operations the 30-day window may have missed. Third, deploy the new scope in shadow-deny mode: the policy engine evaluates the new tighter envelope, and any tool call that the new envelope would have refused logs a "would-have-denied" event without actually denying — you collect a list of false-positive denials and either expand scope or fix the agent's behaviour. Fourth, after a 7-14 day shadow-deny window with no significant false-positive rate, flip to enforce. NHI inventory tools (Astrix, Oasis, Entro, Token) automate steps one and two for managed integrations — they observe usage on Salesforce, GitHub, Snowflake, and emit "right-sized scope" recommendations directly. Manual right-sizing across thirty downstream services takes a quarter; tool-assisted right-sizing takes weeks. The forcing function is the metric: track "tool-and-resource pairs in scope but unused in 30/60/90 days" as a fleet-wide metric, set a target (typically <10% unused), and right-sizing becomes a continuous process rather than a project.

Q: How does NHI compose with prompt-injection defence, and which one is more important?

Both are necessary; neither is sufficient alone, and they protect against different layers of the same attack. Prompt-injection defence (input-side) tries to prevent the planner from being steered — input filtering, retrieved-content sanitisation, structured-output mediation, the dual-LLM pattern. Even with best-in-class input defence, prompt injection in 2026 has a non-zero residual success rate — every published red-team result shows some attacks succeed. NHI is the output-side defence: even when the planner is successfully steered, the executor's per-task scope envelope makes the steering's blast radius irrelevant. If the task is "summarise this document" and the capability token authorises only `documents:read`, no amount of injection can drain Stripe — the token simply doesn't have the scope, the policy engine refuses to mint one, the downstream rejects the call. The two patterns are layered: prompt-injection defence reduces how often steering succeeds; NHI bounds what successful steering can do. A team that ships only prompt-injection defence has a thin layer between the model and admin scope; a team that ships only NHI has a defence that holds but logs many attempted-and-refused lateral moves. The mature posture in 2026 ships both, plus the [defence-in-depth approach from the OWASP LLM Top-10](/en/blog/owasp-llm-top-10-2026-architecture-level-mitigations-mapped-to-each-risk). The cheap way to summarise the relationship: prompt-injection defence is the firewall, NHI is the network segmentation — you want both.

Q: How do I handle long-running tasks that exceed the 5-minute capability-token TTL?

Refresh by going back to the STS with the original workload identity and original user delegation, never by extending the existing token. The flow is: the executor detects that the current token will expire within a refresh window (typically 60 seconds before `exp`), the executor presents the agent's workload-identity assertion plus the original user delegation token plus the unchanged task descriptor to the STS, and the STS mints a new 5-minute token at the same scope. The original delegation token holds a longer TTL (hours, not minutes) precisely so that mid-task refresh is possible without the user needing to re-authenticate. Three discipline points matter. First, scope cannot escalate at refresh — the STS validates that the requested scope at refresh is a subset of the originally authorised scope; an executor whose planner has been compromised mid-task cannot use refresh as a privilege-escalation primitive. Second, refresh must be tied to the original user delegation, not to the executor's session state — if the user has been deactivated or logged out mid-task, the next refresh refuses, and the long-running task halts mid-flight. Third, the original delegation token itself must be revocable — if the security team detects an incident, revoking the user's delegation immediately cuts off every long-running task that depends on it, regardless of how many capability tokens those tasks have minted. The revocation propagates within seconds, and the architectural commitment is that no agent ever holds a credential long enough to outrun a revocation.

Q: What goes in the audit record, and how does it join to downstream SaaS audit logs?

The audit record is per-task and immutable. Eight fields do the architectural work: the task ID; the agent identity and version (so a regression in a new agent version is attributable); the user ID and the delegation token ID (joinable to the user's session log); the task descriptor (the natural-language or structured task description that triggered scope mint); the scope claim that was actually minted; the list of tool calls the executor made, with arguments hashed (not stored — args may contain PII or secrets) and result codes captured; the downstream audit IDs returned by each SaaS (Salesforce login history record, Snowflake QUERY_HISTORY row, Stripe event ID, GitHub audit log entry); start and end timestamps. The record lives in an append-only WORM-protected store (S3 Object Lock Compliance, Azure Immutable Blob, GCP Bucket Lock); tampering after the fact is not architecturally possible. The cross-system join works because the JWT actor claim that the agent presents to Salesforce is the same actor claim that appears in Salesforce's login-history audit log — every downstream that the agent touches must preserve the actor claim in its audit log, and 2026's agent-friendly SaaS providers all do (this is now a procurement criterion, not an aspiration). The record is forwarded to the SIEM for anomaly detection and sampled into the continuous-eval pipeline for drift monitoring. The OpenTelemetry GenAI semantic conventions — `gen_ai.tool.call` spans with `gen_ai.user.id` and `gen_ai.agent.id` attributes — cover the agent-internal half; the SaaS-side audit logs cover the downstream half. The architectural property the audit gives you is post-incident closure: when (not if) an incident happens, you can answer "what scope was active, what was attempted, what was actually called, what data left the building" in minutes, not weeks.

Q: How do I extend NHI to vendor agents, BYO-agents, and SaaS-built-in agents?

Three patterns cover the third-party landscape. First, OAuth-with-scopes for vendor agents: the vendor's agent (Salesforce Agentforce, ServiceNow Now Assist, a third-party finance-reconciliation agent) registers as an OAuth client in your IdP (Okta, Entra, Auth0), you grant per-scope consent, and every action carries an OAuth token bound to the vendor's registered client identity — the IdP is the choke point for scope expansion, revocation, and audit, and the vendor never holds a long-lived enterprise credential. Second, workload-identity federation for vendor cloud presence: when the vendor's runtime is in their cloud, federate it through Azure WIF, GCP WIF, or AWS IAM Roles Anywhere — the vendor's native identity (Auth0 SAML, GitHub Actions OIDC, vendor SPIFFE SVID) is exchanged for a short-lived enterprise credential at task boundary, avoiding the long-lived API key entirely. Third, SaaS-app-to-SaaS-app via the IdP: when one SaaS's built-in agent calls another SaaS, route through the IdP rather than letting the SaaS-to-SaaS connection be managed by a user pasting an API key — Okta Identity Governance, Entra Cross-Tenant Access, and Auth0 Marketplace all support this in 2026; pick one and force it. The dominant tail-risk that remains is supply-chain compromise of the vendor itself: short-TTL federation tokens (1-hour, not 90-day), per-tenant isolation in the vendor's runtime, and continuous monitoring of vendor token usage with anomaly detection are the controls. This pairs with [AI supply-chain security](/en/blog/supply-chain-security-ai-sbom-model-provenance-huggingface-pickle-exploits-2026) and the [zero-trust-AI posture](/en/blog/zero-trust-ai-systems-architecture-mtls-spiffe-egress-allowlist-2026); without those, third-party-agent risk is unbounded.

Satyam Kumar

Back to Blog

cyber-security-patterns

Non-Human Identity for AI Agents — Workload Identity, Capability Tokens, and the End of the Shared Service Account (2026)

By Satyam KumarJune 4, 202629 min read

non-human-identity nhi-top-10 workload-identity spiffe-spire azure-wif gcp-wif aws-iam-roles-anywhere oauth-token-exchange rfc-8693 capability-tokens on-behalf-of-delegation agent-credentials scope-policy-engine opa-cedar secrets-rotation service-account-anti-pattern ai-agent-security zero-trust-agents llm-agent-architecture ai-incident-response-2026

Non-Human Identity for AI Agents — Workload Identity, Capability Tokens, and the End of the Shared Service Account (2026)

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

Non-Human Identity for AI Agents — Workload Identity, Capability Tokens, and the End of the Shared Service Account (2026)

Frequently Asked Questions

Share this article

Comments

Leave a comment