How to Let AI Agents Sign Up for Your App Safely — Isabelle Williams, WorkOS
Isabelle Williams of WorkOS demonstrates how to make an application ready for agent users, using a travel app called Waypoint. She covers the auth.md protocol for anonymous agent access and claim flows, ID-JAG identity assertions that let an agent's provider vouch for a user without a signup form, and scoped, revocable agent tokens that keep agent permissions auditable and bounded.
Isabelle Williams, a product manager at WorkOS, argues that the next user of many applications will be an agent, and that apps need to be built for that reality. She uses Waypoint, a travel planning app she live-coded with Cursor, to walk through three design questions: how to let agents in, how to connect agent activity to real customers, and how to limit and revoke what agents can do.
Three questions for agent-ready apps
For a product-led growth team, the signup funnel has always been about getting a human to the aha moment quickly. Williams’s point is that personal agents will take over discovery, research, and onboarding, so the agent becomes the first user to satisfy. That raises two follow-up questions. First, how does activity that starts with an anonymous agent get tied to a real, paying customer? Second, for corporate travel, where compliance and financial risk are real, how do you constrain an agent and cut off its access when needed?
auth.md as a front door for agents
auth.md is an open protocol: a markdown file hosted alongside the application that tells an agent how to obtain access, create an account, and call the user-facing API. It is written for machines rather than people. Williams stresses that auth.md only describes access and operations; the application itself still enforces them.
Waypoint’s auth.md defines two modes. In anonymous mode, an agent can try the product with limited actions, proving value without a signup. The agent receives an access token and a claim token. When the user wants to take ownership of the agent’s work, the agent gives them a link and a one-time code. The user signs up or signs in, enters the code, and the anonymous activity moves under their account. The authorization server then issues an OAuth access token on behalf of that user to the agent, which uses it to call the API with broader permissions.
Skipping signup with identity assertions
Williams identifies the claim flow as a conversion risk: a link, a signup form, a code, and email verification are exactly where users drop off. Her counterpoint is that the agent provider, such as a Claude or Cursor-style service, has already verified who the user is. Why make the user prove it again?
The answer is ID-JAG, the Identity Assertion Authorization Grant, an IETF draft. The flow works like this. The agent discovers how the protected resource and authorization server work, asks the user for consent to share their identity and email with the application, and then requests an ID-JAG from its own provider. It presents that assertion to the application’s authorization server. The application verifies the signature against the issuer’s public key and decides for itself whether to create an account, link to an existing one, and what scopes to grant in the access token. The assertion’s header carries the token type, signing algorithm, and key. Its payload carries the issuer, the user’s name, email and email verification status, the audience (the application), a client ID known to the application, and an expiry. Williams notes that the same spec underpins enterprise-managed authorization in the MCP specification and Okta’s cross-app access.
In a live demo, a fresh user named Sam Rivera asked an agent harness to plan a New York itinerary that could be shared with coworkers. The agent found several planning tools, but some required a browser signup or an API key. Waypoint accepted the agent directly. After Sam consented to share his name and verified email, and separately to elevated permissions allowing the agent to book dinner reservations, the agent verified his identity, created his Waypoint account, booked a dinner at Quality Bistro, and produced a shareable itinerary link. None of this required any action from Sam.
Williams argues that this kind of cross-service agent activity, where agents sign up, transact, and pay, can only be trusted if it is built on open standards.
Limiting and revoking agent authority
For corporate travel, Williams needs agents to be auditable, bounded, and revocable. Her persona, Jordan, is responsible for company funds and is the only person who can approve budgets and rules. Waypoint includes a read-only agent that answers questions about budgets, and a fund agent that can move money between travelers within the approved budget and rules, but cannot change the budget or the rules.
The key design decision is that an agent never receives the user’s token or an API key. Waypoint issues a separate agent token with three benefits: actions are attributable to the specific agent while still acting on behalf of the user, the agent can be revoked without disturbing the user’s session, and its scope can be constrained. Each agent has a blueprint that acts as a ceiling on its access. The scopes in the agent token are the intersection of the user’s permissions and the blueprint’s permissions.
In the demo, the read-only agent’s blueprint held only one permission. The fund agent was asked to fix a $250 shortfall for a traveler named Alex. It moved $70 but could not cover the rest because the team budget was exhausted. The agent could not change the budget, so Jordan raised it to $2,000 with his own user token, and the agent then finished rebalancing Alex’s funds.
Williams’s takeaways are that auth.md lets agents discover how to enter an application, that the user claim flow or ID-JAG can connect agent activity to real customers, and that enforcing scoped permissions with revocation keeps agents within safe limits.