A new paper proposes a single cryptographic token type meant to solve a problem that's been quietly compounding across the agent ecosystem: MCP and A2A tell agents how to talk to each other, but neither says who they are. As the authors put it, these protocols "define how agents communicate but not who they are." The consequence, already documented, is stark: a security scan of roughly 2,000 MCP servers found every single one lacked authentication, and A2A's agent cards are self-declared with no attestation binding them to anything real. The proposal is called AIP (Agent Identity Protocol), built around what it calls Invocation-Bound Capability Tokens, or IBCTs. Instead of separate systems for identity, authorization, and audit logging, the token does all three at once — it's described as a primitive that unifies identity, attenuated authorization, and provenance binding in a single evolvable token chain. Practically, that means a token issued for one agent-to-agent call can shrink its own permissions as it passes through a delegation chain, while leaving a cryptographic trail of who touched it and what they were allowed to do at each hop. The engineering detail worth noting is that the tokens come in two forms depending on the situation. For a single-hop MCP call, it's a compact signed JWT. For longer, multi-hop delegation — Agent A asks Agent B who asks Agent C — it switches to a Biscuit token carrying Datalog policies, which lets the permission logic travel with the token itself rather than requiring a central authority to check every hop. The performance numbers are meant to preempt the obvious objection that this kind of security theater is too slow for real agent traffic. The authors report sub-millisecond verification for compact tokens, and in a live multi-agent deployment running on Gemini 2.5 Flash, the overhead came out to a small fraction of total latency. They also ran 600 adversarial tests across six attack categories and report full rejection. What makes this different from the pile of other agent-ID proposals circulating right now is the framing: rather than treating identity, authorization, and audit as three separate problems needing three separate specs, it collapses them into one artifact that travels with the request. Whether that survives contact with real multi-vendor deployments — where MCP servers, A2A agents, and whatever comes next all need to agree on token semantics — is the actual open question. The paper positions itself as addressing just the identity layer of what it calls the agent trust stack, alongside separate prior work on provenance and reasoning, which suggests even its own authors don't think one token solves everything.