Das Agent Identity Protocol (AIP) verspricht, was Agenten-Ökosysteme dringend brauchen: eine einheitliche Infrastruktur für Identität, Delegation und Autorisierung über Protokollgrenzen hinweg. Technisch ist der Vorschlag bemerkenswert durchdacht. Aber wer genauer hinschaut, entdeckt eine Lücke, die kein Protokoll schließen kann — und eine Frage, die der Text nicht stellt.

Protokollvorschläge für Multi-Agenten-Systeme haben derzeit Konjunktur. Die meisten davon teilen ein Muster: ein reales Problem wird identifiziert, bestehende Lösungen werden als unzureichend eingestuft, ein neuer Ansatz präsentiert sich als Synthese des Besten aus allen Welten. Das Agent Identity Protocol (AIP) mit seinen Invocation-Bound Capability Tokens (IBCTs) folgt dieser Dramaturgie — aber es folgt ihr mit ungewöhnlicher handwerklicher Sorgfalt. Die Architektur ist kohärent, die Benchmarks sind konkret, die Einschränkungen werden offen benannt. Das allein hebt den Vorschlag aus dem Gros vergleichbarer Papiere heraus. Umso lohnender ist eine Betrachtung dessen, was der Text verspricht, was er einlöst — und wo die strukturellen Grenzen liegen.

Das definierte Spielfeld

Der Ausgangspunkt ist klassisch: Sieben notwendige Eigenschaften werden identifiziert — Public-Key-Verifikation, Holder-Attenuation, expressive Policies, Cross-Protocol-Flow, Provenance, keine Blockchain-Abhängigkeit, Lifecycle-Awareness —, bestehende Ansätze wie OAuth 2.1, DIDs, Macaroons, UCAN, Biscuit und SPIFFE erfüllen jeweils nur Teilmengen davon, AIP deckt alle sieben ab. Was zunächst wie eine neutrale Bestandsaufnahme wirkt, ist bei näherer Betrachtung ein rhetorisches Konstrukt: Wer die Anforderungsliste selbst definiert, gewinnt den Vergleich zwangsläufig. Die Frage, ob genau diese sieben Eigenschaften die entscheidenden sind — und nicht etwa Revokierbarkeit im eigentlichen Sinne, Post-Quantum-Resistenz oder formale Verifikation — wird nicht gestellt. Das ist kein Vorwurf der Unehrlichkeit; es ist ein Hinweis auf den…