ADI
ADI Blog Trust Services 2 Min. Lesezeit

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.

Persönliches Signieren und organisatorisches Siegeln sind rechtlich und technisch unterschiedliche Handlungen.

Enterprise-Agentensysteme brauchen meist beide Ebenen: persönliche Zustimmung für bestimmte Schritte und OrganisationseSeals für wiederkehrende Unternehmensartefakte.

Persönliche Signaturen für jede maschinelle Unternehmenshandlung zu verlangen, erzeugt unnötige Friktion und das falsche Vertrauensmodell.

Warum die Unterscheidung wichtig ist

In vielen Gesprächen über Agent Trust werden Signaturen wie ein generischer Beweisblock behandelt. Das führt in Enterprise-Kontexten sofort zu Fehlkonstruktionen.

Eine vertretungsberechtigte Person, die sich identifiziert und eine High-Trust-Aktion freigibt, ist nicht dasselbe wie ein Unternehmen, das ein wiederverwendbares Trust-Artefakt für einen Enterprise-Agenten ausstellt. Das eine ist ein persönlicher Akt, das andere ein institutioneller.

Wofür eine menschliche Signatur gedacht ist

Vertreterfreigabe beim Onboarding

Delegation von einer realen Person an einen Enterprise-Agenten

High-Trust-Consent oder Commitment, das einer natürlichen Person zurechenbar bleiben soll

Momente, in denen das System beweisen muss, dass ein Mensch bewusst den nächsten Schritt autorisiert hat

Wofür ein OrganisationseSeal gedacht ist

Ausstellung organisationsgetragener Credentials

Versiegelung von Trust-Statements oder Enterprise-Agent-Assertions

Unterstützung wiederkehrender maschineller Unternehmenshandlungen, die der juristischen Person zurechenbar sein sollen

Trennung von Unternehmensartefakten vom privaten Signaturlebenszyklus einzelner Mitarbeitender

Zwei Trust-Ebenen für Enterprise-Agenten

Vertretungsperson und Organisation verschwinden nicht in demselben Beweisobjekt. Sie erfüllen unterschiedliche Rollen.

flowchart TD
    rep["Vertretungsberechtigte Person"] --> sign["Persönliche Signatur oder Identifikation"]
    org["Verifizierte Organisation"] --> seal["OrganisationseSeal"]
    sign --> delegation["Delegation oder Freigabeereignis"]
    seal --> credential["Unternehmens-Credential oder Trust-Artefakt"]
    delegation --> agent["Regierter Enterprise-Agent"]
    credential --> agent

Warum Enterprise-Agenten nicht auf wiederholte persönliche Signatur angewiesen sein sollten

Wenn jede routinemäßige Unternehmenshandlung eine frische persönliche Signatur verlangt, wird das System langsam, spröde und unpraktisch. Schlimmer noch: Es verwischt die Bedeutung der Handlung. Wiederkehrende Unternehmensakte sollten meist der Organisation und nicht der zufällig verfügbaren Person zurechenbar sein.

Das beseitigt die menschliche Trust-Ebene nicht. Es setzt sie nur an die richtigen Stellen: Onboarding, Delegation, Ausnahmen, Eskalationen und bewusste High-Trust-Zustimmung.

Wie ADI diese Trennung modellieren sollte

Eine vertretungsberechtigte Person wird identifiziert und mit der Organisation verknüpft.

Die Organisation wird als juristische Person verifiziert.

Die Organisation erhält die Grundlage für eSeal-fähige Unternehmensartefakte.

Enterprise-Agenten nutzen organisationsgesiegelte Trust-Objekte für routinemäßige unternehmensgetragene Handlungen.

Persönliche Signaturen bleiben für explizite menschliche Freigaben oder Eskalationen verfügbar.

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.

SHOP-INTEGRATIONEN Systemarchitektur

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-Systeme liefern Daten.

Die Trust-Schicht bewertet Rechte, Scope und Kontrollfähigkeit.

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.