ADI
ADI Blog Systemarchitektur 1 Min. Lesezeit

Warum Shop-Integrationen Trust-Inputs und nicht die Trust-Schicht sind

Shopify, WooCommerce oder ERP-Integrationen liefern wertvolle Commerce-Daten. Sie sind aber nicht die Trust-Schicht selbst. Sie speisen Trust-Entscheidungen mit Bestand, Preisen und Produktzuständen, ersetzen aber weder Delegation noch Governance.

Shop-Integrationen liefern operative Fakten, aber keine eigenständige Autoritätslogik.

Die Trust-Schicht entscheidet, ob und wie diese Fakten in eine zulässige Agentenhandlung übersetzt werden.

Wenn Commerce-Integrationen mit Governance verwechselt werden, entstehen schwache oder nicht nachvollziehbare Agentenflüsse.

Die Rolle einer Shop-Integration

Eine Shop-Integration liefert genau die Dinge, die ein Agenten-Commerce-System braucht: Produktdaten, Preise, Bestand, Verfügbarkeit, Währungen und Zustandsänderungen.

Diese Informationen sind wertvoll, aber sie sagen nicht, ob ein bestimmter Agent für eine bestimmte Organisation handeln darf oder ob eine konkrete Zahlung im erlaubten Scope liegt.

Warum das nicht die Trust-Schicht ist

Ein Shop-System weiß nicht automatisch, welche Delegation einem Agenten erteilt wurde.

Es verwaltet nicht zwingend Widerruf, Credential-Status oder Blocklisten.

Es liefert keine belastbare, unabhängige Aussage darüber, ob ein Agent im Namen einer Person oder Organisation handeln darf.

Es ist operativ auf Commerce-Daten optimiert, nicht auf Governance und Rechenschaft.

Die korrekte Trennung

Commerce-Daten vs. Trust-Entscheidung

Shop-Integrationen liefern Inputs. Die Trust-Schicht trifft die belastbare Freigabeentscheidung.

flowchart LR
    shop["Shop/ERP/Commerce-System"] --> facts["Preise, Bestand, Produktstatus"]
    facts --> trust["ADI Trust- und Policy-Schicht"]
    trust --> decision["Freigabe oder Ablehnung"]
    identity["Identität, Delegation, Status"] --> trust
    mandate["Mandate und Payment-Kontext"] --> trust

Was schiefgeht, wenn man das vermischt

Sobald ein Team glaubt, eine Shop-Integration sei bereits die Governance-Lösung, wird der Agentenfluss meist zu locker. Der Shop kennt dann zwar das Produkt, aber niemand prüft sauber, ob der Agent dafür überhaupt befugt ist.

Das führt zu impliziten Freigaben, unklaren Audit-Trails und Commerce-Flows, die bei Streit oder Fehlverhalten schwer erklärbar werden.

Das ADI-Modell

ADI behandelt Shop-Integrationen als Trust-Inputs. Preise, Bestand und Produktzustände sind wichtig, aber sie werden durch Mandate, Identität, Merchant-Bindung und Karten-/Wallet-Regeln gerahmt.

Damit bleiben Shop-Systeme dort stark, wo sie stark sind, und die Trust-Schicht übernimmt dort, wo kontrollierbare Autorität gebraucht wird.

WEITERLESEN

Weitere Artikel aus der technischen Wissensschicht.

OFFENE AGENTENVERTRAUENSKETTE Agenten-Interoperabilität

Wie externe Agenten einen ADI-Merchant-Agenten verifizieren

Ein Buyer-Agent muss nicht innerhalb von ADI laufen, um einem ADI-Merchant-Agenten zu vertrauen. Er braucht öffentliche Discovery, eine auflösbare Agentenidentität, signierte Credentials und einen klaren Mandats- und Payment-Pfad.

A2A-Discovery macht den Merchant-Agenten erreichbar.

ADI-Trust-Discovery macht den Merchant-Agenten zurechenbar.

MERCHANT TRUST Agent Commerce

Wie der Merchant-Trust-Katalog funktioniert

Ein Merchant-Agent kann aus dem Shop verkaufen, aber ADI braucht eine unabhängige Referenz dafür, was dieser Agent überhaupt verkaufen darf. Der Merchant-Katalog in ADI ist genau diese Referenz.

Der Shop-Katalog betreibt das Geschäft.

Der ADI-Katalog beweist, was der Händler freigegeben hat.

AP2-VALIDIERUNG Agent Commerce

Wie ADI validiert, was ein Merchant-Agent verkauft

Ein Merchant-Agent kann ein Angebot beschreiben, aber ADI zahlt nicht auf Basis einer Beschreibung. ADI validiert AP2-Mandate, Händlerorganisation, Produkt-SKU, Trust-Katalog, Buyer-Wallet und virtuelle Karten-Policy vor der Autorisierung.

Das Gespräch erzeugt Intent.

AP2 erzeugt strukturierte Mandate.

INTEGRATIONSMODI Agenten-Integration

Drei Wege, einen externen Agenten mit der ADI-Trust-Schicht zu verbinden

Ein externer Agent muss nicht innerhalb von ADI laufen, um von ADI regiert zu werden. Entscheidend ist, wie das Zielsystem diesen Agenten technisch authentisiert und wann es ADI für Trust, Delegation und Zertifikatsstatus befragt.

Standardmodus: API-Key oder Agent-Token plus Online-Trust-Lookup

Enterprise-Modus: OIDC plus Trust-Lookup

TRUST-GRUNDLAGEN Agent Trust

Warum Agenten eine Trust-Schicht brauchen

Ein API-Token sagt nur, ob eine Anfrage authentisiert ist. Eine Trust-Schicht sagt, welcher Agent handelt, für wen er handelt, welche Nachweise gültig sind und ob dieser Agent gestoppt werden kann.

Wann OAuth nicht mehr ausreicht

Welche Fragen eine Trust-Schicht beantworten muss

ARCHITEKTUR Systemarchitektur

A2A, Trust und AP2 sauber trennen

Das zentrale Architekturprinzip ist die Trennung der Schichten. A2A ist Kommunikation. Trust ist Governance. AP2 ist das Verhalten im Zahlungs- und Mandatskontext.

Was A2A tatsächlich standardisiert

Wann zusätzlich Trust nötig ist

PRODUKT ADI-Stack

Wie ADI als Agent-Trust-Stack funktioniert

ADI ist keine einzelne Oberfläche. Es ist eine operative Schicht, die Discovery, Identität, Trust und Payment-Flows für agentische Systeme miteinander verbindet.

Die vier Schichten der Plattform

Wo A2A, MCP und AP2 zusammenkommen

A2A ERKLÄRT A2A-Grundlagen

Was A2A ist und was es nicht ist

A2A gibt Agenten eine gemeinsame Sprache für Discovery, Nachrichten und Tasks. Es löst aber nicht automatisch Identitätsbindung, delegierte Autorität, Auditierbarkeit oder Payment-Kontrolle.

A2A standardisiert Discovery, Nachrichten, Tasks und deklarierte Sicherheitsfähigkeiten.

A2A beantwortet nicht von selbst, wen ein Agent repräsentiert oder was er darf.

AP2-GRUNDLAGEN AP2-Payments

Was AP2 für Agent Commerce löst

AP2 gibt Agent Commerce ein strukturiertes Modell für Intent, Cart, Payment-Autorisierung und Receipts. Ohne dieses Modell erfindet jede Agenten-Payment-Integration ihre eigene fragile Semantik.

AP2 führt ein gemeinsames Vokabular für Agenten-Payment-Flows ein.

Mandate trennen Scope, Intent und finale Zahlungsfreigabe.

TRUST-GRUNDLAGEN Agent Trust

Was Agent Trust tatsächlich bedeutet

Agent Trust ist kein Marketingbegriff. Es ist die operative Fähigkeit zu beweisen, wer ein Agent ist, in wessen Namen er handelt, was er tun darf und wie diese Autorität widerrufen oder auditiert werden kann.

Trust beginnt dort, wo reine Authentisierung endet.

Eine echte Trust-Schicht muss Widerruf, Inspektion und Evidenz unterstützen.

PRODUKT-ERKLÄRUNG ADI-Stack

Was ADI in einem Agenten-Stack macht

ADI ist die Trust- und Kontrollschicht zwischen Agenten-Interoperabilität und echter Geschäftshandlung. Es hilft Organisationen, Agenten handeln zu lassen, ohne sie wie ungeregelte Black Boxes zu behandeln.

ADI ist der Punkt, an dem Governance in den Agenten-Stack eintritt.

Die Plattform verbindet externe Agenten, Enterprise-Kontrollen und Transaktionspolicies.

SIGNATUREN UND ESEALS Trust Services

Menschliche Signaturen vs. organisatorische eSeals

Eine menschliche Signatur beweist den Willen oder die Freigabe einer natürlichen Person. Ein organisatorisches eSeal beweist, dass ein Trust-Objekt von einer juristischen Person ausgestellt oder versiegelt wurde. In Enterprise-Agentensystemen sind das verschiedene Aufgaben.

Menschliche Signaturen beantworten: Wer hat persönlich zugestimmt?

OrganisationseSeals beantworten: Welche juristische Person steht hinter diesem Artefakt?