Notifications
Clear all
Topic starter
04/06/2026 6:50 pm
TL;DR: Auth.md introduces a discoverable registration path for agents using Markdown-based service instructions, protected resource metadata, and two registration flows that extend existing OAuth and JIT provisioning patterns, according to WorkOS. The shift is not new crypto but a new trust primitive for agent-initiated access, where identity and delegation have to be resolved before the agent can act.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
Q: How should security teams govern agent registration for non-human identities?
A: Security teams should treat agent registration as a governed onboarding event, not a convenience feature.
Q: Why do agent-initiated registration flows matter for IAM programmes?
A: They matter because they move the first trust decision from a human-driven browser flow into the service protocol itself.
Q: What breaks when agents can only register through human-style sign-up flows?
A: Agents stall at the moment they need to act, and the organisation responds by creating one-off endpoints, manual account creation, or shared credentials.
Practitioner guidance
- Map agent registration to an approved onboarding path Document which services may accept agent-initiated registration, which proof methods are allowed, and which business owners approve each flow.
- Separate verified and claimed flows in policy Treat identity-asserted registration and OTP-claimed registration as different trust levels.
- Bind credential issuance to lifecycle controls Require issuance records, expiry handling, and revocation hooks for every agent credential.
What's in the full announcement
WorkOS's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step auth.md file structure and the exact sections services need to publish
- Endpoint-by-endpoint integration guidance for /agent-auth, /agent-auth/claim, and /agent-auth/claim/complete
- Claim ceremony and OTP state-machine details for user-claimed registration
- Implementation notes for revocation handling and credential expiry behaviour
👉 Read WorkOS's agent registration guidance for auth.md and delegated access →
Auth.md for agent registration: what does it change for IAM teams?
Explore further
04/06/2026 7:04 pm
Auth.md is best understood as a trust-boundary protocol for non-human onboarding, not just a convenience layer. The article solves the problem of how an agent gets from a 401 to an accountable credential without forcing a human to translate every access request into a manual setup step. That makes the underlying issue an identity governance problem, because the service now needs rules for delegation, proof, and offboarding at the moment of first contact. Practitioner conclusion: treat agent registration as a governed onboarding path, not an integration shortcut.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: Who should be accountable when an agent credential is issued through delegation?
A: Accountability should sit with the service owner that accepted the delegation model, the platform that asserted identity if one was used, and the business owner that approved the scope. If any of those roles are undefined, the credential is operating outside a defensible governance chain.
👉 Read our full editorial: Agent registration with auth.md changes how services trust AI agents
