Agent registration with auth.md changes how services trust AI agents

At a glance

What this is: Auth.md defines a protocol and discovery document for agent registration that lets services accept agent-initiated access through standardised flows and existing identity infrastructure.

Why it matters: It matters because IAM teams now have to govern how non-human actors onboard, claim identity, and receive credentials without assuming a human-driven signup flow.

👉 Read WorkOS's agent registration guidance for auth.md and delegated access

Context

Agent registration is the missing control layer when a non-human actor reaches a service and cannot complete a human-style sign-up or OAuth consent flow. In practical terms, the problem is not authentication alone but how an agent proves enough context to be issued credentials without turning every integration into a bespoke build.

For IAM and NHI programmes, this is a governance issue as much as a protocol issue. Once agent-initiated access becomes a normal pattern, teams need to decide which identity proof, delegation record, and revocation path will bind the credential to an accountable user or platform.

Auth.md is a typical response to an emerging gap in agent onboarding rather than an isolated edge case. Services are already being asked to treat agents as first-class requesters, and existing provisioning flows were not designed for that starting point.

Key questions

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. Define which proof methods are acceptable, which services may issue credentials to agents, and how revocation is recorded. The goal is to keep delegation, scope, and accountability inside the same lifecycle controls used for other non-human identities.

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. That changes how identity is asserted, how credentials are issued, and how accountability is attached. IAM teams need explicit policy for that trust boundary before agents begin requesting access at scale.

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. Those workarounds expand risk because they bypass consistent identity proof and lifecycle tracking. A registration model must exist before the team starts improvising.

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.

How it works in practice

Agent registration discovery through auth.md and protected resource metadata

Auth.md combines a human-readable Markdown document with machine-readable protected resource metadata so agents can discover supported registration paths without per-partner integration. The Markdown file describes steps, scopes, error handling, and claim flows, while the /.well-known/oauth-protected-resource response advertises the agent_auth block as a source of truth. This matters because discovery is the first control boundary: if the service cannot describe how agents should register, the agent falls back to brittle heuristics or custom code paths. The model keeps existing OAuth-style verification in place and changes only how the workflow begins.

Practical implication: publish a discoverable registration surface before agents start improvising against your API.

Identity assertion versus user-claimed registration

Auth.md separates two trust models. In the verified path, a trusted provider signs an ID-JAG that asserts the agent is acting for a specific user, and the service verifies the token against JWKS before issuing credentials. In the claimed path, the user proves identity through an OTP ceremony, which is useful when the provider cannot attest to the user relationship. This distinction is important because the service is not choosing between convenience and security, but between two different evidence standards for delegation. The registration model therefore becomes a policy decision about who can assert identity on whose behalf.

Practical implication: define which delegation evidence your service will accept before you implement the endpoint.

Credential issuance and revocation after agent registration

Once registration succeeds, the agent uses ordinary credentials such as access tokens or API keys, so the downstream access model stays familiar. The hard part is lifecycle control: revocation has to reach the agent through the control plane, and 401 handling becomes part of the trust model rather than a mere error case. In other words, the system is not inventing a new credential type, but it is adding a new issuance trigger and a new offboarding path for a non-human actor. That places agent registration squarely inside NHI governance, even when the initiating actor is autonomous in behaviour.

Practical implication: connect issuance and revocation to the same governance record so agent access can be withdrawn cleanly.

NHI Mgmt Group analysis

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.

Delegation evidence is now part of the access decision, which means identity proof shifts from the browser to the protocol. The verified flow relies on a signed assertion from a trusted agent provider, while the claimed flow uses OTP-based confirmation when the provider cannot speak for the user. That is a meaningful change for IAM because the trust anchor is no longer just user authentication, but the combination of user context, agent context, and provider attestation. Practitioner conclusion: decide which delegation evidence your programme can actually defend before allowing agent-issued credentials.

JIT provisioning assumptions still hold, but the trigger has changed from human login to agent initiation. The article explicitly says the user model does not change, only what causes the user record and credential to be created. That means many existing onboarding controls can be reused, but only if the organisation is willing to treat an agent as a legitimate registration initiator. Practitioner conclusion: map agent onboarding to existing JIT governance, then add explicit policy for who may initiate it.

Auth.md introduces a named concept that matters for the category: lowest-layer trust between an autonomous actor and an unknown service. That phrase captures the real problem space better than simple API access or OAuth extension language. The protocol tries to standardise the first trust exchange before deeper authorisation begins, which is exactly where most ad hoc agent integrations become fragile. Practitioner conclusion: the first trust exchange now needs the same scrutiny IAM teams give to authentication and provisioning.

Agent registration is an NHI lifecycle event, even when the system presents itself as an agent protocol. Registration, claim, credential issuance, expiry, and revocation all create an identity lifecycle that spans service accounts, delegated users, and platform-managed agents. That means recertification, revocation testing, and scope control apply here just as they do for other NHI forms. Practitioner conclusion: fold agent registration into your NHI lifecycle model instead of treating it as a separate AI feature.

From our research:

• 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.
• Agent onboarding pressure is already colliding with credential exposure patterns, which is why the AI LLM hijack breach analysis is useful for thinking about discovery, trust, and revocation together.

What this signals

Lowest-layer trust for agents is becoming a programme-level design issue. Once services start advertising agent registration, IAM teams have to decide where discovery, delegation proof, and revocation sit in the control stack. The practical shift is toward explicit policy for non-human onboarding, not implicit trust in whatever the service happens to accept. That is where the Ultimate Guide to NHIs , 2025 Outlook and Predictions becomes relevant for future-state planning.

Auth.md strengthens the case for treating agent lifecycle as an NHI problem with autonomous behaviour at the edge. Even when the credential is ordinary, the initiation pattern is not. Teams that already struggle with service-account sprawl will find that agent registration adds another place where issuance, expiry, and revocation have to be provable. The control gap is not just identity proof but lifecycle discipline.

With 43% of security professionals already concerned about AI systems learning and reproducing sensitive information patterns from codebases, per the State of Secrets in AppSec, agent registration becomes part of a broader trust-and-exposure problem rather than a narrow authentication feature. The more agents discover services on their own, the more governance has to assume discovery will be adversarial as well as legitimate.

For practitioners

• 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. Tie those decisions to the same control register used for non-human onboarding so the process is auditable across services.
• Separate verified and claimed flows in policy Treat identity-asserted registration and OTP-claimed registration as different trust levels. Use the verified path only where provider attestation is strong enough for the access being issued, and restrict anonymous or claimed starts to narrowly scoped credentials.
• Bind credential issuance to lifecycle controls Require issuance records, expiry handling, and revocation hooks for every agent credential. If the service cannot prove how a credential is withdrawn after the agent stops being authorised, the registration design is incomplete.
• Test 401 discovery and recovery paths Validate that an agent receiving a 401 can discover the correct metadata, reach the right registration endpoint, and continue without manual workaround. Broken discovery is a governance failure because it pushes teams toward custom exceptions and shadow integrations.

Key takeaways

• Auth.md turns agent onboarding into a governed identity event, not a custom integration problem.
• The practical security question is which delegation proofs, claim methods, and revocation paths your programme can defend.
• Teams that do not formalise agent registration will end up with shadow onboarding, weaker accountability, and harder offboarding.

Key terms

• Agent Registration: Agent registration is the process of creating a governed trust relationship between a non-human actor and a service before access is granted. In this model, the registration step records proof, scope, and ownership so the resulting credential can be issued, monitored, and revoked within an accountable lifecycle.
• Identity Assertion: Identity assertion is evidence used to state that an actor is acting on behalf of a particular user or principal. For agents, this can come from a trusted provider or from a claim ceremony, and the strength of that assertion determines how much access the service should grant.
• Claim Ceremony: A claim ceremony is the verification step that binds an initially issued credential to a real user or delegated principal. It usually uses a one-time code or similar confirmation flow, and it exists to convert provisional registration into accountable access with a clear ownership record.
• Protected Resource Metadata: Protected resource metadata is machine-readable discovery data published by a service so clients can find its authorization expectations. For agent registration, it tells the actor where to look for supported flows and how to discover the trust model without relying on ad hoc integration.

Deepen your knowledge

Auth.md and agent registration are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are adapting lifecycle governance for agents or service accounts, this is a useful place to build the baseline.

This post draws on content published by WorkOS: Agent Registration with auth.md. Read the original.