Non-human identities for AI agents without static keys

Non-human identities (NHIs) are accounts and credentials used by workloads, automation and AI agents. An agent differs from a conventional script because it may select tools dynamically, form a plan and execute a sequence based on untrusted text.

A long-lived API key with broad privilege is particularly dangerous here. Prompt injection can turn an interpretation error into a real business operation.

Give every agent an identity

Do not share one ai-service account across environments and tasks. Every agent needs a distinct identity, owner, purpose, environment and tool set. This limits blast radius and enables credible audit.

Separate runtime identity from deployment pipelines and administrators. Compromising an agent should not permit changes to its code, policies or logs.

Use short-lived credentials

Prefer workload identity, federation and tokens issued for minutes. Restrict audience, scope, resource, environment and delegation. A secret stored in a prompt, configuration file or agent memory will eventually appear in a log or response.

OAuth 2.0 Security BCP provides guidance for token protection, exact redirect URIs and abuse prevention. In agent systems, a token must not be forwarded automatically to an arbitrary tool server.

Make user delegation explicit

An agent acting on a person’s behalf should receive permission for a particular operation and period, not a copy of the entire user session. Retain the user, agent and target service as distinct identities in the chain.

Financial operations, publishing, data deletion and permission changes should require independent authorisation or confirmation. Text in a message or document is not user consent.

Enforce policy at the tool

The tool layer must validate parameters, resources and policy outside the LLM. Prefer narrow business operations over a general execute_sql. Set limits on records, amounts, recipients and file types.

The model may propose an action; a deterministic component decides whether it is allowed. The MCP security guide covers related integration threats.

Audit the full chain

Log user, agent, model, policy, token identifier, tool, arguments and outcome. Correlation should reconstruct who initiated the objective and which decisions produced the effect.

Never log full tokens or secrets. Protect audit records from modification by the agent and set retention for sensitive tool arguments.

NHI lifecycle

1. Register an owner, purpose and permitted resources.
2. Issue short-lived, audience-bound tokens.
3. Enforce policy inside every tool.
4. Monitor unusual scopes, resources and frequency.
5. Rotate trust after incidents or supplier changes.
6. Remove identity automatically when the agent retires.
7. Test identity-provider failure and access revocation.

Measure static keys, ownerless NHIs, over-broad tokens and time from workload retirement to access removal. A safe agent is not a “trusted user”; it is a constrained workload whose capabilities require explicit policy.

---

Delegation boundaries

An agent should use its own identity linked to a user and task, not a shared team key. Its token has a constrained audience, scope, lifetime and, where supported, sender binding. The target system enforces permission rather than trusting that the model “knows” what is forbidden.

Require human approval for irreversible operations with a clear impact summary. Record who requested the task, which agent obtained a token, tools used and changes made. Revocation must work without restarting the platform. A long-lived secret in prompts, repositories or agent memory breaks this model.

Sources: NIST SP 800-207, RFC 9700, MCP Authorization.