Notifications
Clear all
Topic starter
06/06/2026 1:38 am
TL;DR: AI agents in B2B workflows need different credentials depending on whether they act for a user, an org-wide workflow, or backend infrastructure, according to WorkOS. The key governance issue is that agent identities inherit permissions and lifecycle rules differently from both humans and traditional machine accounts, so the wrong primitive expands blast radius.
NHIMG editorial — based on content published by WorkOS: Machine identity for AI agents, which credential to issue and when
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map each agent to a distinct identity primitive Classify every agent as personal, shared, or backend before assigning credentials.
- 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.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Exact setup steps for user-scoped API keys in the WorkOS dashboard and widget.
- Permission configuration examples for org-scoped API keys across shared workflows.
- Client credentials flow setup for M2M Applications and short-lived JWT issuance.
- The practical tradeoffs between revocation, attribution, and local token validation.
👉 Read WorkOS's analysis of which credential to issue to AI agents →
AI agent credentials in B2B products: what should teams issue?
Explore further
06/06/2026 2:53 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Machine identity for AI agents: choosing the right credential
