Handing an agent the user's session token gives it every permission the user has

Look at the scoping boundary. Once a gateway validates the token, every service downstream runs its queries against the tenant_id and user_id it resolved from the claims ^[2]. Two identity axes exist in that token, and separating an agent from the person it acts for needs a third ^[2]. Hand the agent the user's session token and it holds everything the user holds, for as long as the token is valid. Afterwards there is no way to tell whether the user did it or the agent decided to ^[12].

"It stopped being complete the day an AI agent became a caller," the post's author wrote of the two-axis model ^[4]. The worked example is a support-automation agent told, in natural language, to find the three invoices that bounced last month and retry them ^[11]. One search call plus a retry-payment call per invoice: four API calls minimum out of one instruction, more if a first attempt fails ^[1]. The post names the first consequence "blast radius stops matching task scope" ^[13].

The three failure modes it lists are older than agents ^[6]. A reporting job or a migration script starts accepting tenant_id as a request parameter instead of deriving it from the token, because that was faster to build. Then something calls it cross-tenant by accident ^[7]. Admin absorbs every permission nobody wanted to model separately, since a new fine-grained role is a migration and a support ticket while checking role == "admin" is one line ^[8]. Twelve services end up with twelve slightly different answers to "does this user have permission X in this tenant", and an audit is what finds out ^[9]. An agent inheriting that coarse admin role, or calling through that loose parameter, can trigger the same bug a hundred times a minute without a human noticing the pattern, according to the author ^[10].

The roadmap line deserves more care than the token-and-enforcement account does. The post asserts that Auth0, Okta and every other identity vendor spent a chunk of their 2026 roadmaps on this problem ^[14], and it does not link or cite a roadmap document ^[16]. Everything else here is one engineer's account of several iterations of one multi-tenant platform ^[15]. There are no incident counts and no measured population of services. The failure modes transfer only to platforms that share the conditions: internal endpoints that take tenant_id as a parameter, a role model where new roles cost a migration, and a permission check written once per team.

Adding a third claim to the token is the cheap half. Enforcement lives in the services that today trust tenant_id and user_id as the boundary for every query ^[2]. Each of them has to read the new claim and narrow what it will do on the agent's behalf. In my view the sequencing runs opposite to the way vendor roadmaps will present it. The services that still take tenant_id as a request parameter are the same services that will ignore an actor claim. The cleanup the post describes as pre-AI hygiene has to come first.