Give each AI agent its own token so its actions can be audited, limited and revoked

Isabelle Williams, a product manager at WorkOS, argued on the AI Engineer show that an app should not hand an AI agent the user's own login token. The app should issue the agent a separate token instead. That token names the agent, limits what it can do, and can be cancelled without cutting off the person who started it.

What was said

Williams built a demo travel app called Waypoint, which handles corporate booking. Her example user, Jordan, is responsible for company funds. She gave Jordan two agents. One is a read-only chatbot. The other can move money between travellers, but only inside the budget and approval rules.

Williams said Jordan needs that second agent to stay in bounds. It must not alter the budget or the approval rules to get a job done. To enforce that, her app issues the agent its own token. She said: "it's really important to me that I don't just hand an agent Jordan's user token." She gave three reasons: auditing and attribution, revocation, and limiting scope.

In the demo, the token's subject is the agent's ID, so actions can be attributed to the agent. It also records that the agent acts on Jordan's behalf. Its permissions are the overlap between Jordan's rights and a ceiling the app sets for that kind of agent.

The demo showed the effect. A teammate had a $250 shortfall, but only $70 was available. The agent moved the $70 and stopped. Jordan then raised the budget himself with his own token, and the agent finished the job.

Why it matters

Our reading: when an agent borrows a user's token, its actions look like the user's own actions. The only way to stop it is to cut off the user. A separate identity changes that. The token names the agent and records who it acts for, so a log shows which agent acted and on whose behalf. The app can revoke the agent without logging Jordan out.

Williams said real corporate money is at stake in her example. For buyers, one question for vendors is whether their agents get their own identity. For builders, the work is deciding each agent's ceiling. Who is accountable when an agent still causes harm is a separate question, and the talk left it open.

The other side

Williams did not say who pays when an agent still causes a loss. A traceable token shows what happened. It does not settle who compensates the customer. The demo was one controlled case, shown by a vendor promoting its own product, WorkOS Agent Auth.

The limits are also only as good as the ceiling the app builder picks. A generous blueprint gives the agent generous powers. She did say the wider approach will need open standards, and that standards work is still under way.