How to Let AI Agents Sign Up for Your App Safely - Isabelle Williams, WorkOS

As AI agents become the primary users of applications, developers need open standards and architectures that let agents discover, register, and act on behalf...

How to Let AI Agents Sign Up for Your App Safely: An Architectural Analysis

Abstract

As autonomous AI agents increasingly mediate product discovery, sign-up, and task execution, conventional web authentication and product-led growth assumptions require revision. This synthesis examines an architectural stack for agent-to-service interaction, organized around three questions: how applications admit agents, how agent activity binds to verified human identities, and how agent authority is constrained and revoked. Three mechanisms are analyzed: Auth.md, a machine-readable registration protocol; the user claim flow and ID Jag (Identity Assertion Joined Authorization Grant) for identity binding; and agent tokens scoped as the intersection of user permissions and a predefined agent blueprint ceiling. A live demonstration indicates identity assertion can eliminate manual sign-up friction, while scoped tokens preserve auditability. The analysis concludes that interoperable open standards, not proprietary integrations, are prerequisite for safe agent commerce.

1. Introduction

The thesis motivating this work is direct: "Your next user is an agent." Personal agent products - including Muse, Instinct, and Claude Code - are assuming responsibility for tasks historically performed by humans: researching vendors, comparing options, registering for services, and executing transactions on a user's behalf. This shift destabilizes a foundational assumption of product-led growth (PLG), the strategy whereby a frictionless self-serve experience converts an evaluating human into a paying customer. When the evaluating entity is software rather than a person, sign-up forms, email verification loops, and browser-based consent screens become obstacles rather than conversion funnels.

Three questions structure this analysis: first, admission - by what mechanism does an application permit an agent to discover and invoke its capabilities; second, identity binding - how anonymous or pseudonymous agent activity connects to a real, verifiable customer account; and third, constraint - how agent actions can be limited, audited, and revoked, particularly under corporate compliance requirements. These questions are not independent; admission mechanisms shape identity-binding options, and identity-binding decisions determine what constraint mechanisms are available downstream.

Sections 2 through 4 develop the technical substrate for each question, drawing on a live demonstration involving a fictional new user ("Sam Rivera") interacting with a travel-booking application, and a second scenario involving corporate travel persona "Jordan." Section 5 situates these findings within the broader standards landscape, including convergence with Anthropic's MCP specification and Okta's cross-app access feature.

2. Background and Related Work

The architectural pattern under discussion extends OAuth, the prevailing delegated-authorization framework, rather than replacing it. OAuth remains the issuance mechanism for the final user-scoped access token; what changes is the path by which an agent arrives at the authorization decision. Two standardization efforts provide context. First, ID Jag is an IETF specification defining an assertion-based grant in which one party attests to a user's identity for a specific relying party. Its adoption is not isolated: the same construct underlies Anthropic's enterprise managed authorizations within the MCP specification and Okta's cross-app access. This convergence suggests identity assertion is stabilizing as the canonical primitive for agent-mediated authentication.

Second, WorkOS Agent Auth provides a reference implementation for constructing scoped agent tokens, operationalizing the permission-ceiling model discussed in Section 3.3. The conceptual tension animating this work is captured in a user-facing question: "Doesn't my agent already know who I am?" If an agent provider has already authenticated a user, requiring re-authentication at every downstream application represents redundant friction - provided the downstream application can cryptographically verify the provider's claim.

3. Core Analysis

3.1 Admission: The Auth.md Protocol

Auth.md is an open protocol expressed as a markdown file hosted by an application, describing how agents may register and access its APIs. Critically, Auth.md describes access and operations but does not itself enforce authentication or API logic - enforcement remains the application's responsibility. Two access modes are defined: an anonymous trial mode, in which agents operate without prior sign-up, and an expanded mode tied to a verified user account. Anonymous access allows agents to demonstrate product value before committing a user to registration, directly addressing the PLG friction problem described in Section 1.

3.2 Identity Binding: Claim Flow versus ID Jag

Two mechanisms connect anonymous agent activity to real users. The claim flow proceeds as follows: an agent acts anonymously and receives a claim token; the human user then signs up or logs in using a one-time code to claim the agent's prior actions; OAuth subsequently issues a user-scoped access token to the agent. This flow introduces friction - sign-up, code entry, and email verification - that risks losing users during exactly the discovery phase PLG strategies are designed to optimize.

ID Jag (Identity Assertion Joined Authorization Grant) offers an alternative: the agent provider asserts user identity directly to the application, bypassing manual steps. The flow proceeds: the agent requests user consent to share identity; the agent provider issues an ID Jag; the receiving application verifies the signature and independently decides on account creation, linking, and token scope. The payload structure includes an issuer (the agent provider), user information (name, email, verification status), an audience (the target application), a client ID, and an expiration, with a header specifying token type, signing algorithm, and signing key. The assertion is signed with the issuer's public key, enabling cryptographic verification by the receiving application.

A central design principle is that trust decisions remain fully with the receiving application: "Your app is completely in control of that." The application determines whether to create an account, link an existing one, and what scopes to grant - the assertion only establishes verified identity, not authorization.

3.3 Constraint: Agent Tokens and the Blueprint Ceiling

The demonstration involving persona "Jordan" illustrates the constraint problem in a corporate compliance context, where audit trails and prevention of unauthorized financial actions are required. Two agent types were constructed: a read-only chatbot agent and a fund-moving agent. Each agent is issued a distinct agent token - not the user's own token - with a subject identifying the agent and an "acting on behalf of" field linking to the human user. This separation supports auditing, attribution, and revocation independent of the user's own credentials.

Token scope is computed as the intersection of the user's actual permissions and a predefined agent blueprint, a ceiling of permissions assigned to that agent type regardless of what the user is independently authorized to do. In the demonstration, the fund-moving agent could reallocate budget between users but could not alter the overall budget total - an action reserved exclusively for the human user Jordan. This demonstrates that blueprint ceilings can impose restrictions stricter than the user's own permission set, providing a compliance control independent of user-level access policy.

4. Technical Insights

Several implementation considerations emerge. First, Auth.md separates capability advertisement from enforcement, meaning applications retain full control of authentication logic while gaining a standardized discovery surface for agents - reducing integration cost without ceding security control. Second, the claim flow and ID Jag are not mutually exclusive; the claim flow remains useful where no trusted agent-provider assertion is available, while ID Jag is preferable where an established, cryptographically verifiable identity provider already exists.

Third, the ID Jag payload's inclusion of audience and client ID fields is a critical limitation on misuse: an assertion issued for one application cannot be replayed against another, constraining the blast radius of a compromised or malicious agent provider. Fourth, the agent-token model's reliance on a blueprint ceiling introduces a governance requirement largely orthogonal to existing OAuth scope design: organizations must define blueprints per agent type in advance, independent of individual user permission grants. A limitation noted but not elaborated in the source material is how blueprint definitions are versioned or updated as agent capabilities evolve. Finally, WorkOS Agent Auth is presented as a concrete implementation of this scoping logic, suggesting the pattern is implementable with existing tooling rather than requiring bespoke infrastructure.

5. Discussion

These findings suggest that agent-mediated commerce is converging on a layered trust architecture: discovery via standardized files, identity assertion via signed, audience-bound tokens, and authorization via scoped, revocable credentials distinct from user credentials. The repeated emphasis that "your app is completely in control" reflects a deliberate design choice to preserve application-side sovereignty over trust decisions even as identity verification is delegated upstream to agent providers.

The convergence of ID Jag across Anthropic's MCP enterprise authorizations, Okta's cross-app access, and the demonstrated travel-booking implementation indicates this is not a vendor-specific pattern but an emerging cross-industry standard. This matters because fragmented, proprietary identity-assertion schemes would require applications to integrate separately with each agent provider, reproducing the very friction the standard is designed to eliminate.

Open questions remain regarding blueprint governance at scale, cross-provider trust federation, and how applications should handle conflicting or stale identity assertions. The source material does not address revocation latency - how quickly a revoked agent token ceases to be honored - which is material to the stated compliance use case.

6. Conclusion

This analysis has outlined three interlocking mechanisms - Auth.md for admission, the claim flow and ID Jag for identity binding, and scoped agent tokens for constraint - that together constitute an emerging architecture for safe agent-to-application interaction. The practical takeaway for developers is that these are additive to existing OAuth infrastructure rather than replacements, and that standards adoption, rather than custom integration, is positioned as the durable path toward secure agent commerce.

Sources

• How to Let AI Agents Sign Up for Your App Safely - Isabelle Williams, WorkOS - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub