Agent Identity Management

Agent Identity Management is the property that agents have persistent identities that are independent of any user session. These include formal credentials, machine accounts, or agent- specific principals such as Microsoft Entra Agent ID. The OWASP document treats this under the broader category of Non-Human Identities (NHIs): machine accounts, service identities, and agent-based API keys that operate without session-based user oversight.

Why it matters for security: NHIs change the accountability model. They live longer than user sessions, are scoped broadly to do the agent’s job, and are increasingly treated as enterprise-grade access principals with privileged long-term API access. Misuse of an agent identity may not look anomalous in conventional access logs.

Identity management interacts with Autonomy (an autonomous agent acts under its own identity, not the user’s), with Non-Determinism (the same agent identity can be used to perform different actions on different runs), and with Agent-to-Agent Communication (agents authenticate to each other and inherit trust transitively).

A concrete scenario

A software company builds a code-review agent that has read/write access to GitHub repos and read access to an internal Jira instance. The agent runs as a service account (agent-codereview@company.internal) with a long-lived OAuth token stored in a Kubernetes secret. A developer is manipulated into merging a pull request that contains a dependency with a poisoned package; the package reads the AGENT_OAUTH_TOKEN environment variable at install time and exfiltrates it to an attacker-controlled server. The attacker now holds a credential that has write access to every repository the review agent can touch, not just the one the poisoned PR was targeting. The token has no expiry date and is not scoped per-repository. Because the credential belongs to a machine account, the initial exfiltration generates no authentication alert; the access logs show only normal-looking API calls under the service account name.

What this means for your system

Agent credentials are a privileged target, not a convenience detail. A service account token with broad repository or database access is more valuable to an attacker than most human user tokens, because it is long-lived, scoped broadly, and the account does not have a human who notices suspicious login times. Treat agent secrets with the same rigour as root credentials.

Conventional access reviews miss NHIs. Identity governance processes designed for human accounts (quarterly access reviews, manager approvals) do not naturally surface machine accounts. An agent identity created for a proof-of-concept may retain its permissions long after the project ends. You need a separate inventory and lifecycle process specifically for non-human identities.

Shared identities prevent attribution. If multiple agents share one service account, you cannot tell from audit logs which agent instance performed a given action. When an incident occurs, the investigation is blind.

What to do about it

Give each agent its own distinct identity (a dedicated service account, Entra Agent ID, or workload identity) rather than sharing credentials across agents or reusing human-user accounts. One identity per agent is the minimum baseline for attribution.

Scope credentials to the minimum surface needed for each task, not the maximum the agent might ever need. A code-review agent needs read on source repos and write on PR comments; it does not need write on the main branch or access to secrets stores. Use GitHub’s fine-grained personal access tokens or AWS IAM conditions to enforce this at the API level, not just in the system prompt.

Set short expiry on all agent tokens and rotate them on a schedule shorter than your longest plausible incident-detection window. If your SOC typically detects stolen credentials in 72 hours, a 48-hour token rotation limits the damage window.

Include agent identities in your SIEM’s anomaly baselines. Unusual call patterns (new API endpoints, access at odd hours, volume spikes) are as meaningful for machine accounts as for human ones. AWS CloudTrail, Azure Monitor, and GitHub’s audit log stream all support filtering by service-account principal.

Log every action against the agent’s identity, not just the user session that triggered the agent. When an agent acts autonomously across tool calls, each call must be individually attributable in the audit trail so post-incident reconstruction is possible.

Related

ASI entries this factor most amplifies:

• ASI03 — Identity & Privilege Abuse: weak agent identity management is the direct enabler: an attacker who compromises a broadly scoped NHI credential can act as the agent, with all its permissions, indefinitely.
• ASI04 — Agentic Supply Chain Vulnerabilities: supply-chain attacks frequently target the credential-loading step (environment variables, mounted secrets) because agent credentials are high-value and often unmonitored.
• ASI07 — Insecure Inter-Agent Communication: when agents authenticate to each other using long-lived shared tokens, a single compromised agent exposes the entire agent mesh.

Example threats driven by this factor:

• T9 — Identity Spoofing and Impersonation: weak agent identity management creates the conditions for spoofing: if agents accept self-asserted identity claims over internal channels, any process that can speak on that channel can impersonate.
• T3 — Privilege Compromise: over-permissioned agent accounts mean that any compromise of the agent (whether through injection, supply chain, or credential theft) immediately grants the attacker broad privilege.
• T13 — Rogue Agents in Multi-Agent Systems: a rogue agent must present a believable identity to peer agents; poor identity management (no attestation, shared tokens) makes this straightforward.