This is the infrastructure layer most teams bolt on after the first incident. You frame it as identity, but what you're really building is accountability infrastructure.

Three gaps I see:

Delegation chains break when they hit MCP. Your RFC 8693 reference is spot-on, but MCP servers today rarely verify delegation context. The calling agent says "user:1234 approved this" and the tool server has to trust it. Cryptographic delegation solves this—but you need the verification layer in the tool server, not just the agent.

Audit trails without revocation semantics are forensic, not operational. You can trace which agent did what, but if that agent's credentials are still valid after you discover the problem, you're closing the barn door after the horse left. Key rotation is the easy part. Delegation revocation cascades through every tool server that accepted the original delegation.

The "acting on behalf of" boundary is where most implementations blur. Is the agent autonomous? Acting for user X? Acting for workflow Y which user X approved last week? Each of those has different audit requirements and different revocation blast radii.

Your gut check questions are good—I'd add one: if the agent's key was rotated this morning, can every system it touched yesterday still trace its actions back to that specific key version? Most teams would say yes. Most teams would be wrong.