Tweet by tweetsbycolin

May 22, 2026

We've been discussing internally and like it! Happy to collab on this Parts we like: 1. It does account matching by email. Lots of identity folks don't like this, but it's hard to imagine agent auth ever working without it. 2. There's a clever mechanism in the "User Claimed" flow where services don't email an OTP, but instead email a link that *eventually* reveals an OTP. This is nice because it allows the services to enforce 2FA, SSO, bot detection, extra sign up fields, etc. 3. There's another nice mechanism with "Anonymous Start," which enables an agent to provision resources before identifying themselves (if a service supports it) Parts we think need more definition... 1. The "Agent verified" flow defers heavily to ID-JAG and lists Claude/Codex/Cursor as anticipated ID-JAG minters. We wish it shared more on how to maintain a trust list while accepting these federated minters. For example, consider that Acme Co has configured enterprise SSO with Clerk. If Claude mints an ID-JAG for an Acme Co email address, Clerk must reject it since otherwise it would serve as an enterprise SSO bypass. What's a good schema for a trust list that expresses this well? 2. "Anonymous start" for ID-JAG. We like the anonymous start mechanism but we're not sure it should only apply to "User Claimed" 3. We wish it did more to minimize standing privilege. This is more a gripe with protected-resource-metadata than with auth.md per se, but we think any agent auth spec is going to struggle with widespread proliferation unless we come up with a better strategy (e.g. scoping per task)

Author
tweetsbycolin
Date
May 22, 2026
Open on X