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

A travel-planning app normally asks a person to discover it, create an account and get far enough to see why it is useful. What happens when that person delegates the whole search to an agent? Isabelle Williams, a product manager at WorkOS, explores that question through Waypoint, an app she built with Cursor for personal and company travel. The working task is to plan a trip to AIE in New York City.

An agent doing product discovery also needs a way to get started. If registration requires the person to leave the conversation, navigate a browser and collect credentials, the delegated workflow stops before the app can demonstrate its value. Waypoint therefore needs an entrance an agent can use—and a way to connect the resulting work to a real customer.

Company travel adds a harder requirement. An agent that can spend or move corporate funds needs limits, attribution and revocation. These concerns produce three distinct design questions: how an agent gets access, whose behalf it acts on, and which actions it may take once inside.

auth.md is the agent-facing starting point. Williams presents it as an open registration protocol expressed through a Markdown file hosted with the application. The file explains how to obtain access, create an account and begin calling the API. A person can read it, but its intended reader is the agent trying to use the product.

The important division is between description and enforcement. Writing down allowed operations does not enforce them. Waypoint's API remains responsible for checking authorization. The file helps an agent discover the supported route; the application decides whether a request is permitted.

Waypoint uses two access conditions:

• Anonymous exploration: An agent can take limited actions without first creating a user account, giving it a chance to establish that the app is useful.
• User-connected access: Once Waypoint can tie the agent to a real user, it can expand the available actions.

That distinction lets registration happen after some useful work, rather than making it a prerequisite for every interaction.

The first route separates permission to do limited work from ownership of that work. During anonymous access, the agent receives an access token for API calls and a separate claim token. The claim token supports a later transfer: a user can take ownership of what the agent has already done and bring it under their account.

When the user wants to claim the work, the agent provides a link and a one-time code. The user visits Waypoint, signs up or signs in, and enters the code. After the claim, Waypoint's OAuth authorization server can issue the agent an access token on behalf of that user. Subsequent API calls then operate in the user's context.

This solves the ownership problem, but it retains a conversion problem: the person still follows a link, completes authentication, enters a code and may need to verify an email address. Williams's objection is practical: “this is where you lose your user.” If the agent's provider already has a signed-in user and a verified email, why require the application to collect that identity again through another manual signup?

The second route lets the agent provider assert the user's identity to Waypoint. It begins with discovery: the agent finds the protected API or MCP server and its OAuth authorization server. It then asks the user for consent to share identity information and an email address with Waypoint. With consent, the agent requests an ID-JAG from its provider and sends that assertion to Waypoint's authorization server.

Waypoint verifies the assertion and decides what to do with it. It may create a new account, link the identity to an existing account, and choose the scopes to place in the access token returned to the agent. The assertion supplies identity information; it does not make those application decisions. Only after the exchange does the agent receive the access token it uses to call Waypoint on the user's behalf.

ID-JAG expands to Identity Assertion JWT Authorization Grant, which Williams introduces as an IETF specification. She connects it to enterprise managed authorizations in the MCP ecosystem and Okta's Cross App Access. In the Waypoint flow, the agent provider is the issuer and Waypoint is the intended audience. The provider signs an assertion about a particular user for a particular recipient.

What information lets Waypoint distinguish who is making the assertion from whom it concerns and where it may be used? The illustrated assertion separates those roles:

• Header: Identifies the ID-JAG type, signing algorithm and signing key.
• Issuer and user information: Identifies the agent provider and carries the user's email address and whether that email was verified.
• Recipient and client: Names Waypoint as the audience and identifies a client known to Waypoint.
• Validity and signature: States how long the assertion is valid and provides the issuer's signature for verification.

These fields make the identity handoff inspectable. Waypoint still chooses which issuer claims to trust and what access to grant; a valid signature does not itself settle account linking or permission policy.

The demonstration starts in a custom agent harness that can issue ID-JAGs. Its signed-in user is Sam Rivera, a fresh identity that Waypoint has never seen. Sam asks for an AIE New York City itinerary that can be shared with coworkers, and asks the agent to find a suitable planning tool. During the search, one alternative requires browser signup and another requires an API key. Waypoint offers a registration path the agent can use.

The agent asks permission to share Sam's name and verified email with Waypoint. There is also a separate consent request for elevated access: booking dinner reservations. Williams approves both. This is an important qualification to the hands-off signup: the demo removes manual account creation, while retaining human approval for identity sharing and the more consequential booking capability.

What does that access produce? The harness reports that it verified Sam's identity and created the Waypoint account. It then returns an itinerary, a dinner reservation at Quality Bistro and a link Sam can share with colleagues. The useful change is from a user unknown to Waypoint to a user with an account and shareable work, without a separate signup form. This demonstrates the flow in Williams's ID-JAG-capable harness; it does not establish that an arbitrary agent provider can already perform the same exchange.

The interoperability requirement follows directly from that example. A registration route only helps discovery if agents and applications can understand the same exchange. Williams's closing judgment on this part is that safe, trusted agent access will require open standards for talking to services, signing up, acting and paying. The custom harness demonstrates a working path; standardization is how she expects that path to extend across providers and applications.

The company-travel example changes the stakes from creating an itinerary to moving corporate money. Jordan is responsible for company funds and is the only person allowed to approve the budget and approval rules. Waypoint provides two in-app agents:

• Read-only agent: Can answer questions about the budget but cannot change it or move money.
• Funding agent: Can move funds between users within the approved budget and rules, but cannot change either constraint.

For example, someone flying from San Francisco may need more funding than someone arriving by train from Boston. Jordan wants an agent to handle that redistribution without gaining the power to rewrite the budget to make its task easier.

When Jordan invokes an agent, Waypoint's backend issues a separate agent token instead of handing over Jordan's user token. That separation serves three different purposes:

• Attribution: Actions can be attributed to the agent that performed them.
• Independent revocation: Jordan or Waypoint can revoke the agent without ending Jordan's session or removing Jordan's own access.
• Limited permissions: The token can carry fewer scopes than Jordan possesses.

How does Waypoint prevent either the user or the agent configuration from granting too much access? Each agent has a blueprint defining its maximum scopes. The issued token receives the intersection of that ceiling and the invoking user's permissions:

The two inputs converge on the token; they are not successive permission grants. A capability must be allowed by both. Jordan's broader budget-management permissions therefore do not automatically pass to the funding agent, and a blueprint cannot give an invoking user permissions they lack.

The live session details make the intersection concrete. Jordan's user token has several permissions; the read-only blueprint has only one. The resulting agent token carries their intersection. Its subject is the agent ID, while separate information records that it acts on behalf of Jordan. What should the comparison reveal? The credential identifies both the actor performing the work and the user represented by that actor, without treating them as the same identity.

The read-only agent's behavior is skipped in the interest of time. The demonstration moves to the funding agent, where the permission distinction can produce an observable result: the agent will try to fix Alex's budget while the team has only about $70 available.

Alex has a $250 shortfall. The funding agent asks whether it should rebalance funds, and Williams confirms. It moves $70 to Alex—the amount available—but cannot resolve the full shortfall. The remaining problem is not a lack of instructions: there is no more budget available, and the funding agent is not allowed to increase it.

What does a permission ceiling look like in the result? Here it is partial completion: $70 moves, but the rest of the request remains unresolved. The agent can redistribute existing funds without gaining permission to enlarge the pool. This is the consequential distinction between Jordan's authority and the authority delegated to the funding agent.

Jordan still has the missing permission. Using the user session, Williams changes the team budget to $2,000 and tells the agent that the budget has increased. The agent can then fix Alex's budget. The correction changes the available funds through a separately authorized human action; it does not require expanding the agent's permission ceiling.

That ending ties the registration and authorization mechanisms together. auth.md tells an arriving agent how to get access. A claim flow or ID-JAG connects its work to a customer. Once the agent acts inside the app, an agent-specific token limits what it can do and supports attribution and revocation. Williams identifies WorkOS Agent Auth as the product used for the scoped in-app agents. The funding example shows the permission limit in action; independent revocation is an architectural capability described here, rather than an operation performed in the demo.