Non-Human Identity for Agentic Systems: Delegation, Scoping, and the End of Static Service Accounts

The first time an agent in production exfiltrates data using its own legitimately issued credentials, the postmortem will not read like a credential theft incident. It will read like an authorization design failure, because that is what it is. The industry spent a decade hardening human authentication — phishing-resistant MFA, conditional access, device posture — and then handed agentic systems the keys with a static client secret in a Kubernetes Secret and a scope list copied from a Stack Overflow answer. In 2026, the gap between how we authenticate humans and how we authorize the LLM-driven processes acting on their behalf is the dominant identity risk in most enterprise estates.

Non-human identity (NHI) is not new — service accounts, workload identities, and machine certificates have existed forever. What is new is that the workload is now a probabilistic reasoner that decides at runtime which tools to call, with what arguments, against which tenant’s data. The control surface that used to be a developer writing deterministic code is now a model selecting from a tool registry mid-conversation. The IA and AC families were not written with that in mind, but they map onto it cleanly if you do the work.

Why service-account thinking fails for agents

A traditional service account has three properties that agentic systems violate. First, its caller is deterministic — the same code path produces the same API call. Second, its scope is static — you provision it once for a known set of operations. Third, its blast radius is bounded by the application’s own logic. None of these hold when the principal is an agent.

An agent’s tool selection is conditioned on attacker-influenceable input the moment it ingests an email, a ticket, a PDF, or a webpage. Prompt injection is not a content-filtering problem; it is a confused-deputy problem in the classic Hardy sense. The agent holds authority the user granted it, and an attacker who controls part of the context can redirect that authority. If the credential bound to the agent is a long-lived OAuth client credential with mail.read, files.readwrite.all, and sites.read.all, the model is one cleverly crafted invoice away from being a data exfiltration tool that authenticates correctly the entire way.

Delegation chains, not service accounts

The correct primitive is a delegation chain that preserves both the originating user and the intermediate agent identities, with scopes that narrow at each hop. OAuth 2.0 token exchange (RFC 8693) and the act/may_act claims in JWTs exist precisely for this. A workable chain looks like this:

1. User authenticates with phishing-resistant credentials and receives a token bound to a session and device (IA-2, IA-5).
2. The orchestrator exchanges that token for a downstream token whose act claim names the agent’s workload identity, with scopes reduced to what this task plausibly needs.
3. Each tool invocation triggers another exchange, narrowing further — files.read scoped to a specific drive ID, valid for sixty seconds, audience-bound to the target resource server.

The resource server now sees a token that says, in effect, “user U, acting through agent A, acting through tool T, may read this one resource for the next minute.” That is auditable (AU-2, AU-3, AU-12), revocable, and amenable to anomaly detection. It is also incompatible with the way most teams ship agents today.

Workload identity, not secrets in vaults

The agent itself needs an identity that is not a secret you can steal. SPIFFE/SPIRE issuing X.509 SVIDs or JWT-SVIDs to the orchestrator pod, attested by the platform, is the floor. On confidential-compute platforms — TDX, SEV-SNP, Nitro Enclaves — you can bind the identity to a measured workload via remote attestation, so a token is only issued if the running image, model weights hash, and tool registry hash match an approved manifest. That gets you SC-12, SC-13, and SI-7 in a way that a HashiCorp Vault AppRole login simply does not, because the AppRole secret is exfiltratable and the attestation evidence is not.

Scoping the tool registry

Identity is half the problem. The other half is what the agent is allowed to do once authenticated. Treat the tool registry as a policy boundary, not a convenience layer. Every tool needs:

• A declared input/output schema with server-side validation, not just a function signature handed to the model.
• A risk tier — read-only metadata, read user data, write user data, write tenant data, write across tenants — with tier transitions requiring step-up authentication or human-in-the-loop approval.
• Per-tool rate and volume budgets enforced at the gateway, not in the prompt. “Do not read more than fifty files” in a system prompt is a suggestion; an egress proxy that 429s the fifty-first call is a control.

Detection that actually fires

Log the full chain. The audit record for a tool call should carry the user subject, the agent workload ID, the model and version, the prompt hash, the tool name, the arguments, the resource identifier, and the parent trace ID. Anomaly detection then has something to work with: a user whose agent suddenly calls files.search with adversarial-looking queries, a workload identity attesting from an unexpected node, a tool argument distribution that diverges from baseline. Without the chain, your SIEM sees an OAuth app reading files, which it has been doing all year.

What to stop doing

Stop minting tenant-wide application permissions for agent platforms because the vendor’s quickstart asked for them. Stop putting a single client secret behind the entire agent fleet. Stop treating prompt-injection mitigations as a substitute for authorization. The model will be jailbroken; the question is what the token in its hand can do when it is.

Identity for agentic systems is an authorization problem dressed as an authentication problem. The teams that survive the next round of incidents will be the ones who shortened token lifetimes, narrowed scopes per call, attested their workloads, and made every tool invocation a first-class auditable event — before the board asked them to.