Unklare Identität
Eine AgentCard sagt Ihnen, wie ein Agent erreichbar ist. Sie sagt nicht, welcher Betreiber, welches Unternehmen oder welche verantwortliche Partei dahintersteht.
FÜR ARCHITEKTEN
Discovery allein reicht nicht. Agenten brauchen Governance.
ADI trennt Kommunikation, Trust und Transaktionsverhalten, damit externe Agenten entdeckt, regiert und zum Transagieren befähigt werden können, ohne alles in eine einzige Token-Erzählung zu pressen.
A2ATrustAP2
DAS PROBLEM
A2A ermöglicht Kommunikation. Vertrauen entsteht dadurch nicht von selbst.
Sobald Agenten Unternehmens-, Team- oder Wallet-Grenzen überschreiten, brauchen Sie operative Antworten auf Identität, Delegation, Widerruf und kontrolliertes Payment-Verhalten.
Kein Delegationsmodell
Sobald ein Agent für eine Person oder ein Unternehmen handelt, brauchen Sie maschinenlesbare Rechte, Scope, Gültigkeit und Widerruf.
Keine Governance
Ohne Blocklists, Widerruf, Zertifikatsstatus und Auditierbarkeit bleibt externe Agenten-Interaktion operativ schwach.
Payments brauchen mehr
Agent Payments brauchen Rollen, Mandate, Proofs und Transaktions-Kontrollpunkte – nicht nur ein generisches Token.
TRUST-FRAGEN
Was die Trust-Schicht beantworten muss, bevor ein externer Agent handeln darf.
Genau diese Fragen bleiben offen, wenn Architektur bei AgentCard plus OAuth stehen bleibt.
Ist dieser Agent real oder nur ein beliebiger Endpoint?
Ist er an einen Betreiber, Nutzer oder eine Organisation gebunden?
Welche Rechte wurden delegiert und für wie lange?
Wurden Credentials, Zertifikate oder Policies widerrufen?
Kann ich Aktionen einsehen, blockieren und auditieren?
ADI STACK
Vier Schichten für vertrauenswürdige Agentensysteme.
ADI ersetzt A2A nicht. Es legt Identität, Trust, Policy und Transaktionskontrolle über die Discovery-Schicht.
01
A2A Discovery und Access
Agent Cards, JSON-RPC-Methoden, Interfaces und Security-Deklarationen machen den Agenten aufrufbar.
AgentCard und Well-Known Discovery
Unterstützte Interfaces und Security-Anforderungen
OIDC, OAuth, JWT oder andere Transport-Authentisierung
02
Identität und Betreiberbindung
Ein Agent muss einem Betreiber, Tenant, Rollenkontext oder einer Organisation zugeordnet sein, bevor er als realer Akteur gelten kann.
Verknüpfung mit Nutzer oder Organisation
Rollen- und Ownership-Kontext
Lebenszyklusstatus und Aktivierungskontrolle
03
Trust- und Governance-Kontrollen
Diese Schicht beantwortet, ob der Agent handeln darf, für wen er handeln darf und welche Nachweise noch gültig sind.
Policies, Claims und Delegations-Scope
Verifiable Proofs, Zertifikatsstatus, Widerruf
Blocklists, Audit Trails und Inspektionsflächen
04
AP2-Transaktionsverhalten
Zahlungsfähige Agenten brauchen Mandatsbehandlung, payment-spezifische Rollen und transaktionsfeste Kontrollpunkte.
Rollen wie Merchant, Shopper, Credentials Provider oder Processor
Cart-, Intent- und Payment-Mandate
Kontrollierte Payment-Flows und Payment-Proofs
WANN WELCHE TIEFE?
Nicht jede Integrationsfläche braucht denselben Governance-Grad.
Der operative Bedarf steigt, sobald ein Agent Verantwortung, Rechte oder echte Zahlungsfähigkeit erhält.
Nur A2A
Für interne oder einfache Service-Agenten, die primär Discovery, Messaging und Basisauthentisierung brauchen.
Interne Assistenten und Workflow-Bots
Low-Liability Service-Interaktionen
Kein Wallet-, Mandats- oder Payment-Verhalten
A2A + Trust
Für externe oder governance-pflichtige Agenten, bei denen Identität, Delegation und Widerruf relevant sind.
Agenten-Interaktionen über Unternehmensgrenzen hinweg
Delegation im Namen von Personen oder Organisationen
Compliance-, Audit- oder Accountability-Anforderungen
A2A + Trust + AP2
Für Commerce-, Wallet- und Payment-Agenten, die Mandate, Limits oder Payment-Proofs austauschen.
Einkaufs- und Verkaufsagenten
Virtuelle Karten-, Wallet- oder Mandatsflüsse
Transaktionsfeste Orchestrierung und Zahlungssteuerung
Geben Sie Agenten eine Architektur, die Kommunikation, Governance und Payment sauber trennt.
ADI wird interessant, wenn Agenten reale Verantwortung, Delegation und kontrollierte Transaktionen übernehmen sollen.
Zuständigkeiten sauber trennen
Halten Sie Kommunikation, Trust und Payment-Verhalten als unabhängige Schichten, statt alles in ein Token oder eine Registry zu pressen.
Externe Agenten regieren
Behandeln Sie Dritt- oder Partneragenten als gesteuerte Akteure mit Ownership, Status und Policy-Kontext statt als opake Endpunkte.
Echte Transaktionsflüsse kontrollieren
Gehen Sie von generischer API-Nutzung zu gesteuerten Payment- und Mandatsflüssen mit auditierbaren Kontrollpunkten.
Menschen- und Maschinenflächen verbinden
Halten Sie öffentliche Erklärung, maschinenlesbare Metadaten und operative Integrationsflächen in derselben Architektur zusammen.