Machine identity for AI agents: choosing the right credential

At a glance

What this is: This is a WorkOS analysis of machine identity for AI agents, with the key finding that user-scoped keys, org-scoped keys, and M2M applications each fit different agent scenarios.

Why it matters: It matters because IAM and PAM teams now need to govern agent access as a separate identity pattern, not as a simple extension of human sessions or service accounts.

By the numbers:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read WorkOS's analysis of which credential to issue to AI agents

Context

Machine identity for AI agents is now a practical governance problem, not a future-state architecture question. When an agent can call endpoints, mutate records, and chain tools across systems, the real decision is which credential primitive safely represents that behaviour without overextending trust.

The article separates three scenarios that identity teams already recognise in other forms: a personal agent tied to one user, a shared agent serving an org-wide workflow, and a backend agent operating as infrastructure. Each scenario maps to a different permission model, revocation path, and attribution requirement, which is why the same credential pattern should not be reused everywhere.

Key questions

Q: How should security teams choose credentials for AI agents that act on behalf of users?

A: Use user-scoped credentials when the agent must stay inside one person's existing permission boundary and revocation needs to follow the user lifecycle. That preserves attribution and simplifies offboarding. Do not use a broader org credential just because the workflow is convenient, because the agent will inherit more access than the task actually requires.

Q: Why do AI agents complicate non-human identity governance?

A: AI agents complicate non-human identity governance because they sit between human delegation and machine execution. They can act with a user's authority, but their runtime behaviour is more dynamic than a normal service account. That means entitlement scope, attribution, and revocation all need separate treatment instead of being copied from human IAM or backend IAM patterns.

Q: What breaks when an AI agent is given a generic service credential?

A: A generic service credential breaks the link between task scope and access scope. The agent can now operate with org-wide authority even when it only needs a narrow delegated boundary, which expands blast radius and makes incident review harder. That is a governance failure, not just a token choice problem.

Q: How do organisations keep AI agent credentials from becoming standing privilege?

A: Organisations should use short-lived tokens where possible, store secrets in a secrets manager, and make revocation part of the deployment and offboarding workflow. The goal is to avoid persistent credentials that outlive the agent's purpose. Without lifecycle controls, even a well-scoped agent credential becomes standing privilege in practice.

Technical breakdown

User-scoped API keys and delegated agent identity

User-scoped API keys bind the agent to a specific human account, so permissions, attribution, and revocation follow the user lifecycle. This is a delegated identity model, not a generic machine account. The main governance benefit is traceability, because each action inherits the user's granted permissions and can be removed when the user leaves. The limitation is structural: the agent cannot be constrained below the user's own entitlement set, so the credential is only as safe as the underlying user permissions.

Practical implication: use user-scoped keys only when the agent must act exactly within one person's existing access boundary.

Org-scoped keys, permission scoping, and shared workflow agents

Org-scoped API keys with permission scoping represent an identity primitive for shared agents that are not owned by a single person. The key belongs to the organisation, but the available permissions are narrowed so the agent does not inherit the full org surface. That makes it suitable for support routing, webhook processing, and other cross-account workflows. The governance tradeoff is attribution loss: the credential identifies the workflow, not the human operator, so lifecycle accountability has to live in surrounding application controls.

Practical implication: pair org-scoped keys with separate owner metadata and review processes so accountability does not disappear with the human context.

OAuth client credentials and short-lived JWTs for backend agents

M2M applications use the OAuth 2.0 client credentials flow to issue short-lived JWTs for backend agents running in infrastructure. The important property is not just authentication, but bounded exposure: the token expires automatically and can be validated locally, which reduces dependence on online revocation checks. That makes it a better fit for unattended services than long-lived bearer secrets. But it still remains a non-human identity primitive, so storage, rotation, and secret handling discipline are still required.

Practical implication: reserve client-credentials flows for infrastructure agents that need ephemeral tokens and machine-speed validation.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent credentials expose an identity design problem, not just an authentication choice. The article shows that the right primitive depends on delegation pattern, lifecycle ownership, and permission boundary. User-scoped keys, org-scoped keys, and M2M tokens are not interchangeable because each one encodes a different trust model. Practitioners should treat agent credentials as identity architecture decisions, not implementation preferences.

Delegated access for AI agents is a governance problem because the agent inherits someone else's privilege boundary. A personal agent is not a user, but it is also not a service account with its own standing authority. That makes the human-to-agent delegation chain the real control surface, especially where offboarding, attribution, and entitlement ceilings matter. The implication is that existing user-centric governance must be extended to cover agent-mediated actions.

Identity blast radius becomes the decisive concept for AI agent governance. The article repeatedly frames the choice around how much access the agent should carry relative to the task it performs. That is not the same as asking whether the credential is human-like or machine-like. The practitioner conclusion is that agent identity should be scoped by blast radius first, then by operational convenience.

Standing secret exposure remains the weak point even when the credential choice is correct. The source article notes that agents can exfiltrate or replay credentials at machine speed, which means storage and rotation matter as much as the primitive itself. That aligns with OWASP-NHI and Zero Trust assumptions, where token leakage and replay risks do not disappear because the credential is short-lived. Practitioners should assume the secret handling layer will fail before the policy layer does.

Agent identity governance is converging on a new baseline where lifecycle, attribution, and token lifetime must be designed together. Personal agents need revocation tied to the user lifecycle, shared agents need scoped organisational oversight, and backend agents need short-lived credentials with auditable issuance. The field is moving toward explicit agent identity governance rather than reusing human IAM patterns by default. Practitioners should redesign their authorization graph before agent sprawl creates inconsistent trust paths.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• Use 52 NHI Breaches Analysis to see how credential lifecycle failures turn into real incidents.

What this signals

Identity blast radius: agent programmes now need an access model that starts with delegation scope, not with credential format. In practice, that means user-scoped, org-scoped, and M2M-issued credentials should be treated as different trust classes, not interchangeable implementation options.

Because 96% of organisations still store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the operational risk is not only over-privilege but also exposure. Agent credentials that are easy to mint but hard to contain will become the fastest route from workflow automation to lateral misuse.

Teams should align agent identity controls with the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework so that permission scoping, attribution, and revocation are designed together. The practical shift is to review where human IAM patterns stop and where machine-speed controls must begin.

For practitioners

• Map each agent to a distinct identity primitive Classify every agent as personal, shared, or backend before assigning credentials. Use that classification to decide whether the access should be user-scoped, org-scoped, or issued through an OAuth client credentials flow.
• Tie agent revocation to the right lifecycle event Make personal-agent access disappear when the underlying user is offboarded, and ensure org-scoped keys have explicit ownership and review. Do not rely on manual cleanup after a workflow is retired.
• Limit permission scope before issuing any agent credential Narrow the permissions available to API keys and tokens to the smallest operational set the agent needs. Avoid reusing a full service credential when a bounded scope can satisfy the workflow.
• Store agent secrets as higher-severity credentials Keep agent credentials in a secrets manager, never in logs or plaintext environment variables, and rotate them as part of deployment. Treat leaked agent credentials as more dangerous than a typical user password because they can be replayed by machines immediately.
• Separate attribution from authorization in shared workflows If the credential cannot encode the human owner, add application-level metadata and approval records so you can reconstruct who authorized the agent and why. That preserves accountability when the identity primitive itself is org-wide.

Key takeaways

• AI agent identity cannot be governed with a single credential pattern because user delegation, shared workflows, and backend services carry different trust boundaries.
• The evidence base remains unforgiving: API key offboarding and rotation are still weak in most organisations, which makes agent secrets easy to overretain.
• Practitioners should scope agent access by lifecycle, attribution, and blast radius before they standardise on any one token type.

Key terms

• User-scoped API Key: A user-scoped API key is a credential issued to an individual account rather than to the organisation as a whole. It inherits the user's permissions and lifecycle, which makes it suitable for delegated agent actions that must remain traceable to a person and disappear with that person's access.
• Org-scoped API Key: An org-scoped API key is an organisation-owned credential with a deliberately narrowed permission set. It is useful for shared workflows that are not tied to one person, but it requires separate accountability controls because the credential itself does not encode human ownership.
• M2M Application: An M2M application is a machine-to-machine identity that uses OAuth client credentials to obtain short-lived tokens for backend service authentication. It is the strongest fit for unattended infrastructure agents because the token expires automatically, but it still needs secure secret handling and clear ownership.
• Identity Blast Radius: Identity blast radius is the amount of access and operational impact an identity can create if it is misused or compromised. For agents, the concept is crucial because the right credential is the one that limits damage to the smallest workable task scope, not the broadest convenient permission set.

Deepen your knowledge

AI agent credential scoping is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping delegated, shared, and backend agent access into one governance model, it is worth exploring.

This post draws on content published by WorkOS: Machine identity for AI agents, which credential to issue and when. Read the original.