Agentic Commerce: Wie du KI-Agenten sicher einkaufen lässt

Warum das jetzt wichtig ist

KI-Agenten werden richtig gut bei Konversationen, Empfehlungen und Suche. Der nächste Schritt liegt auf der Hand: Lass sie Transaktionen abschließen. Ein Agent, der Verfügbarkeit prüfen, Optionen vergleichen und Tickets buchen kann, ist nützlicher als einer, der dir nur die Optionen zeigt und dich durch ein Checkout-Formular klicken lässt.

Aber sobald ein Agent Geld ausgeben kann, ändert sich alles. Ein Kundenservice-Agent, der die falsche Show bucht. Ein Reise-Agent, der 50 Plätze statt 5 reserviert. Ein Shopping-Assistent, der eine Bestellung für ein Produkt aufgibt, das der Lieferant gar nicht mehr führt. Das sind keine hypothetischen Szenarien. Das sind die vorhersehbaren Folgen, wenn du ein LLM an eine Checkout-API anschließt, ohne Governance einzubauen.

Wir haben ein Protokoll dafür gebaut. Wir nennen es das Agentic Checkout Protocol (ACP). Es steuert, wie KI-Agenten Commerce-Transaktionen innerhalb einer Multi-Tenant-Plattform initiieren, validieren und abschließen. Dieser Artikel erklärt die Architektur von Grund auf.

Für Kontext, wie wir agentische KI-Systeme und Multi-Agent-Architektur angehen: Diese Guides behandeln die breiteren Muster. Dieser Artikel fokussiert sich speziell auf das Commerce-Transaktionsproblem.

Das Kernproblem

Traditionelle Checkout-Flows setzen voraus, dass ein Mensch die Entscheidung trifft. Das Merchant-Backend ruft die Checkout-API mit einem API-Key auf, die Bestellung wird validiert, die Zahlung erfasst. Der Mensch ist verantwortlich.

Bei Agentic Commerce ist der Aufrufer ein KI-Agent. Der Agent operiert innerhalb eines Konversations-Threads, hat Zugriff auf Tools und kann autonom handeln. Das bringt Risiken mit sich, die ein traditioneller Checkout nicht abdeckt:

Die Lösung ist nicht "Agenten dürfen nichts kaufen." Die Lösung ist ein Protokoll, das jeden Schritt steuert.

Das Agentic Checkout Protocol

ACP kombiniert fünf Systeme zu einem einzigen Trust-Framework:

┌─────────────────────────────────────────────────────────┐
│                   ACP FLOW                               │
│                                                          │
│  User: "Buche Der König der Löwen für 2 Erwachsene      │
│         am Samstag"                                      │
│                         │                                │
│                         ▼                                │
│  ┌─────────────────────────────────┐                    │
│  │  1. MCP TOOL LAYER              │                    │
│  │  Agent ruft createCheckout()    │                    │
│  │  via Model Context Protocol     │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  2. POLICY ENGINE               │                    │
│  │  Prüfung: Darf dieser Agent     │                    │
│  │  bei diesem Lieferanten buchen? │                    │
│  │  Liegt der Wert im Limit?       │                    │
│  │  Ergebnis: ALLOW oder DENY      │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│            ALLOW│         DENY ──▶ Fehler an Agent      │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  3. HITL APPROVAL GATE          │                    │
│  │  Wenn Bestellwert > Schwelle:   │                    │
│  │  Workflow pausieren, Ops        │                    │
│  │  benachrichtigen                │                    │
│  │  Auf menschliche Freigabe       │                    │
│  │  warten                         │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│              APPROVED                                    │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  4. SUPPLIER EXECUTION          │                    │
│  │  Inventar reservieren           │                    │
│  │  Buchung beim Lieferanten       │                    │
│  │  bestätigen                     │                    │
│  │  HMAC-Quittung generieren       │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  5. AUDIT LOG                   │                    │
│  │  Unveränderlichen Eintrag       │                    │
│  │  schreiben                      │                    │
│  │  actor_type: "agent"            │                    │
│  │  thread_id, tenant_id, receipt  │                    │
│  └─────────────────────────────────┘                    │
│                                                          │
└─────────────────────────────────────────────────────────┘

Jede Komponente hat für sich einen Wert. Zusammen bilden sie ein vollständiges Governance-Framework für KI-initiierten Handel.

Komponente 1: MCP Tool Layer

Der Agent ruft APIs nie direkt auf. Er nutzt MCP-Tools (Model Context Protocol), die beim Agent Framework registriert sind. Jedes Tool ist ein kontrollierter Einstiegspunkt mit Eingabevalidierung, Policy-Enforcement und Audit-Logging.

// MCP-Tool-Definition zum Erstellen eines Checkouts
const createCheckoutTool = createTool({
    id: 'createCheckout',
    description: 'Create a checkout for a product booking',
    inputSchema: z.object({
        productId: z.string(),
        date: z.string().datetime(),
        persons: z.array(z.object({
            type: z.enum(['adult', 'child', 'senior']),
            count: z.number().int().positive(),
        })),
    }),
    execute: async ({ productId, date, persons }, ctx) => {
        // 1. Validiere, dass das Produkt im Suchindex existiert
        const product = await searchApi.getProduct(ctx.tenantId, productId);
        if (!product) throw new ToolError('Product not found');

        // 2. Policy prüfen
        const policy = await policyEngine.evaluate(
            ctx.tenantId, ctx.channelId, 'create_order',
            { productId, supplierId: product.supplierId, estimatedValue: product.price }
        );
        if (!policy.allowed) throw new ToolError(`Policy denied: ${policy.reason}`);

        // 3. Checkout-Workflow starten
        return checkoutWorkflow.start({ productId, date, persons, ctx });
    },
});

Das Tool validiert, dass das Produkt tatsächlich existiert (verhindert halluzinierte Buchungen), prüft die Policy vor jeder finanziellen Aktion und routet in einen gesteuerten Workflow. Der Agent hat nie direkten Zugriff auf die Supplier-API.

Dieses Muster kommt daher, wie wir KI-Workflow-Systeme designen. Das Tool ist die Trust-Grenze. Alles innerhalb des Tools ist gesteuert. Alles außerhalb ist nur Konversation.

Komponente 2: Policy Engine

Vor jeder finanziellen Aktion evaluiert die Policy Engine Tenant-spezifische Regeln. Regeln werden pro Tenant gespeichert und mit einem 5-Minuten-TTL gecacht.

interface PolicyRule {
    action: string;                    // "create_order", "cancel_order", "search"
    effect: "allow" | "deny";
    conditions: {
        max_order_value?: number;          // Hartes Limit, darüber ablehnen
        allowed_suppliers?: string[];      // Einschränkung welche Lieferanten
        require_human_approval_above?: number;  // HITL-Schwelle
        max_items_per_order?: number;      // Massen-Betrug verhindern
    };
}

Evaluierungsregeln

1. Deny-Regeln haben Vorrang. Wenn eine Deny-Regel zutrifft, wird die Aktion sofort abgelehnt.
2. Allow-Regeln mit Bedingungen. Wenn eine Allow-Regel zutrifft, werden ihre Bedingungen gegen den Request evaluiert.
3. Keine passende Regel = abgelehnt. Default-Deny. Ein Agent kann nichts tun, was nicht explizit erlaubt ist.

Beispiel-Policy

{
    "tenant_id": "tenant_acme",
    "rules": [
        {
            "action": "create_order",
            "effect": "allow",
            "conditions": {
                "max_order_value": 5000,
                "allowed_suppliers": ["supplier_alpha", "supplier_beta"],
                "require_human_approval_above": 500,
                "max_items_per_order": 10
            }
        },
        {
            "action": "cancel_order",
            "effect": "allow",
            "conditions": {}
        },
        {
            "action": "search",
            "effect": "allow",
            "conditions": {}
        }
    ]
}

Die Agenten dieses Tenants können frei suchen, Bestellungen bis 5.000 EUR erstellen (aber Bestellungen über 500 EUR brauchen menschliche Freigabe), nur bei zwei freigegebenen Lieferanten buchen, und Bestellungen mit maximal 10 Artikeln erstellen. Stornierungen sind ohne Einschränkungen möglich. Alles andere wird abgelehnt.

Die Policy Engine ist Tenant-bezogen. Verschiedene Merchants bekommen verschiedene Regeln. Ein großes Unternehmen setzt die HITL-Schwelle vielleicht bei 2.000 EUR. Ein kleiner Betreiber verlangt möglicherweise Freigabe für alles über 100 EUR. Der Plattformbetreiber setzt Default-Policies, und Tenants können innerhalb ihres erlaubten Rahmens anpassen.

Komponente 3: HITL-Freigabe-Gates

Wenn eine Bestellung den require_human_approval_above-Schwellenwert überschreitet, pausiert der Checkout-Workflow und wartet auf menschliche Freigabe.

// Im Checkout-Workflow
async function checkoutWorkflow(ctx, params) {
    // Schritt 1: Inventar reservieren
    const reservation = await supplierAdapter.reserveInventory(
        ctx.tenantId, params.productId, params.date, params.persons
    );

    // Schritt 2: Prüfen ob menschliche Freigabe nötig ist
    if (reservation.totalPrice > policy.require_human_approval_above) {
        // Workflow pausieren, Ops-Dashboard benachrichtigen
        const approval = await workflow.suspend({
            reason: 'Order exceeds approval threshold',
            totalPrice: reservation.totalPrice,
            threshold: policy.require_human_approval_above,
            productName: reservation.productName,
            reservationExpiresAt: reservation.expiresAt,
        });

        if (!approval.approved) {
            await supplierAdapter.cancelReservation(reservation.id);
            return { status: 'REJECTED', reason: approval.rejectionReason };
        }
    }

    // Schritt 3: Buchung bestätigen
    const booking = await supplierAdapter.confirmBooking(reservation);

    // Schritt 4: Quittung generieren
    const receipt = generateHmacReceipt(booking, ctx.tenantId);

    // Schritt 5: Audit-Log
    await auditLog.write({
        action: 'order_completed',
        actor_type: 'agent',
        thread_id: ctx.threadId,
        tenant_id: ctx.tenantId,
        order_id: booking.orderId,
        receipt_hmac: receipt.hmac,
    });

    return { status: 'COMPLETED', orderId: booking.orderId, receiptHmac: receipt.hmac };
}

Der Workflow nutzt suspend() und resume() vom Agent Framework. Wenn er pausiert ist, zeigt das Ops-Dashboard die ausstehende Bestellung mit allen Details. Ein Operator kann freigeben oder mit Begründung ablehnen. Der Workflow setzt automatisch fort, sobald die Entscheidung getroffen ist.

Die Reservierung hat eine Ablaufzeit. Wenn der Mensch nicht vor Ablauf der Reservierung freigibt, storniert das System die Reservierung automatisch und informiert den Agenten. Der Agent kann dem User dann mitteilen, dass das Buchungsfenster geschlossen ist.

Mehr zum Thema menschliche Aufsicht in KI-Systemen findest du in unserem Guide zu Human-in-the-Loop KI.

Komponente 4: HMAC-Quittungen

Jede abgeschlossene Bestellung erzeugt eine manipulationssichere Quittung mit HMAC-SHA256. Das liefert kryptografischen Beweis darüber, was passiert ist.

Quittungsspezifikation

Quittungs-Payload

interface ReceiptPayload {
    order_id: string;
    tenant_id: string;
    products: Array<{
        id: string;
        date: string;
        total_price: number;
    }>;
    total_price: number;
    currency: string;
    booker_email: string;
    created_at: string;  // ISO 8601
}

Signierung

function generateHmacReceipt(order: Order, tenantId: string): Receipt {
    const payload: ReceiptPayload = {
        order_id: order.id,
        tenant_id: tenantId,
        products: order.items.map(item => ({
            id: item.productId,
            date: item.date,
            total_price: item.totalPrice,
        })),
        total_price: order.totalPrice,
        currency: order.currency,
        booker_email: order.bookerEmail,
        created_at: order.createdAt.toISOString(),
    };

    // Kanonisches JSON: sortierte Schlüssel für deterministische Ausgabe
    const canonical = JSON.stringify(payload, Object.keys(payload).sort());
    const secret = await secretsManager.getTenantSecret(tenantId);
    const hmac = crypto.createHmac('sha256', secret).update(canonical).digest('hex');

    return { payload, hmac, signedAt: new Date().toISOString() };
}

Verifizierung

GET /v1/order/{orderId}/verify
Response: { valid: true, signed_at: "2026-06-15T14:30:00Z" }

Der Verifizierungsendpunkt berechnet den HMAC aus den gespeicherten Bestelldaten mit dem Tenant-Secret neu und vergleicht ihn mit der gespeicherten Quittung. Eine Abweichung bedeutet, dass die Bestelldaten nach der Signierung manipuliert wurden. Das gibt Merchants, Prüfern und Regulierungsbehörden nachweisbaren Beweis, dass ein bestimmter Agent, im Rahmen eines bestimmten Tenant-Scopes, eine bestimmte Bestellung zu einem bestimmten Zeitpunkt erstellt hat.

Komponente 5: Unveränderlicher Audit Trail

Jede ACP-Aktion erzeugt einen Audit-Eintrag. Das Audit-System nutzt eine zweistufige Architektur:

Stufe 1: Operatives Log (Datenbank, abfragbar, 90 Tage Aufbewahrung)

{
    action: 'order_completed',
    actor_type: 'agent',           // "agent" | "human" | "system"
    thread_id: 'thread_abc123',    // welche Konversation
    tenant_id: 'tenant_acme',
    channel_id: 'ch_web_en',
    order_id: 'ord_xyz789',
    total_price: 450,
    currency: 'EUR',
    supplier_id: 'supplier_alpha',
    receipt_hmac: 'a1b2c3...',
    policy_evaluated: true,
    hitl_required: false,
    created_at: '2026-06-15T14:30:00Z',
}

Stufe 2: Unveränderliches Archiv (Object Storage mit Write-Once/Read-Many, 7 Jahre Aufbewahrung)

Das operative Log streamt zu Object Storage mit Object Locks (Compliance-Modus). Einmal geschrieben, können Einträge für den Aufbewahrungszeitraum weder geändert noch gelöscht werden. Das erfüllt regulatorische Anforderungen für Finanztransaktionsaufzeichnungen.

Jeder Audit-Eintrag enthält actor_type und thread_id. Damit lässt sich exakt nachvollziehen, welcher KI-Agent, in welcher Konversation, welche finanzielle Aktion initiiert hat. Kombiniert mit der HMAC-Quittung liefert der Audit Trail einen lückenlosen Beweis der Entscheidungskette.

Wie wir Audit- und Observability-Systeme allgemein bauen, beschreiben unsere Guides zu KI-Governance und KI-Observability.

ACP vs. Traditioneller Checkout

Idempotenz

Agenten-initiierte Transaktionen brauchen Idempotenz auf Protokollebene. Netzwerk-Retries, Agent-Wiederholungsversuche und Workflow-Replays dürfen keine doppelten Bestellungen erzeugen.

// Idempotenz-Schlüssel für agenten-initiierte Checkouts
const idempotencyKey = `${tenantId}:${threadId}:${productId}:${date}`;

// Vor der Verarbeitung prüfen
const existing = await idempotencyStore.get(idempotencyKey);
if (existing) {
    return existing.result;  // Gecachtes Ergebnis zurückgeben
}

// Verarbeiten und speichern
await idempotencyStore.acquire(idempotencyKey);
const result = await processCheckout(params);
await idempotencyStore.complete(idempotencyKey, result);
return result;

Der Idempotenz-Schlüssel kombiniert Tenant, Konversations-Thread, Produkt und Datum. Derselbe Agent in derselben Konversation, der dasselbe Produkt am selben Datum bucht, bekommt immer dasselbe Ergebnis. Ein anderer Konversations-Thread bekommt einen neuen Schlüssel.

Der Store nutzt bedingte Schreibvorgänge, um Race Conditions zu verhindern. Wenn zwei Worker gleichzeitig denselben Schlüssel akquirieren wollen, schafft es nur einer.

Tenant-Scoping

Jede ACP-Operation ist auf einen Tenant und Channel beschränkt. Die Identitätshierarchie stellt Datenisolation auf jeder Ebene sicher:

Tenant (Merchant-Organisation)
  └── Channel (Storefront oder Vertriebskanal)
       └── Customer (Endnutzer)
            └── Session (Browser/Gerät-Session)
                 └── Agent Thread (einzelne Konversation)

Der Agent-Thread erbt seinen Tenant- und Channel-Kontext von der authentifizierten Session. Jeder Tool-Call, jede Policy-Evaluierung, jeder Audit-Eintrag trägt diese Identifikatoren. Cross-Tenant-Datenzugriff ist architektonisch unmöglich, weil jede Abfrage den Tenant-Scope als Pflichtfilter enthält.

Das ist dasselbe Multi-Tenant-Isolationsmuster, das wir in unserem System-Architektur-Guide beschreiben. Der Unterschied bei ACP ist, dass der Agent eine weitere Scoping-Ebene hinzufügt: den Thread. Speicher und Kontext eines Agenten sind auf tenant_id + session_id + thread_id beschränkt. Agent A in einem Tenant kann die Konversation von Agent B in einem anderen Tenant nicht sehen.

Was schiefgehen kann

Selbst mit ACP gibt es Fehlerfälle, die du behandeln musst:

Implementierungsüberlegungen

Wann du ACP einführen solltest

Nicht jede KI-Commerce-Integration braucht das volle Protokoll. Betrachte den Autonomiegrad:

Fang mit Suche an. Füge Warenkorb-Aufbau hinzu, wenn Vertrauen aufgebaut ist. Geh zu unterstütztem Checkout mit HITL bei jeder Bestellung über. Graduiere erst zu autonomem Checkout mit policy-basierten HITL-Schwellen, wenn du Daten zur Genauigkeit des Agenten hast und die Fehlerrate akzeptabel ist.

Technologieentscheidungen

ACP ist ein Protokoll, keine Implementierungsvorgabe. Die Komponenten können mit verschiedenen Technologien gebaut werden:

Das Protokolldesign ist wichtiger als die konkreten Tools. Wenn du die fünf Komponenten implementierst (Tool-Governance, Policy-Evaluierung, menschliche Freigabe-Gates, manipulationssichere Quittungen und unveränderliches Audit), ist das System sicher, unabhängig von der zugrunde liegenden Technologie.

Für unsere breitere Perspektive auf KI-System-Architektur und wie wir Beratungsprojekte angehen, bieten diese Seiten mehr Kontext.

Häufige Fehler

1. Agenten direkt Supplier-APIs aufrufen lassen. Der MCP Tool Layer ist die Trust-Grenze. Ohne ihn hast du kein Policy-Enforcement, keinen Audit Trail und keine Idempotenz.

2. Default-Allow-Policy. ACP nutzt Default-Deny. Wenn keine explizite Allow-Regel für eine Aktion existiert, wird sie abgelehnt. Default-Allow mit Deny-Overrides ist schwächer, weil du jede schlechte Aktion im Voraus antizipieren musst.

3. HMAC-Quittungen überspringen. Ohne manipulationssichere Quittungen kannst du einem Merchant oder Regulierer nicht beweisen, dass eine Bestellung nach dem Erstellen nicht verändert wurde.

4. Gleiches Idempotenz-Schlüsselformat für alle Operationen. Der Schlüssel muss Kontext enthalten (Thread, Produkt, Datum). Ein globaler Schlüssel wie order:123 hindert nicht daran, dass ein anderer Agent in einer anderen Konversation dasselbe Produkt bucht.

5. Keine Reservierungsablaufzeit. Wenn HITL-Freigabe ewig dauert, hält die Reservierung Inventar unbegrenzt. Setze immer eine Ablaufzeit und handle den Timeout-Fall.

6. Vom Agenten bereitgestellten Produktdaten vertrauen. Das Tool muss validieren, dass das Produkt im Suchindex existiert. Der Agent könnte eine Produkt-ID, einen Preis oder ein Verfügbarkeitsdatum halluzinieren.

7. Agent-Speicher nicht per Tenant scopen. Ein Agent, der Tenant A bedient, darf keinen Zugriff auf Tenant Bs Konversationshistorie, Produktkatalog oder Policy-Regeln haben.

8. Agentic Checkout als Feature behandeln, nicht als Protokoll. ACP ist kein Feature, das du draufschraubst. Es ist ein Trust-Framework, das von Anfang an in das System eindesignt werden muss.

Zentrale Erkenntnisse

• Agenten können nicht "einfach Dinge buchen." Jede agenten-initiierte Finanztransaktion braucht Policy-Evaluierung, optionale menschliche Freigabe, manipulationssichere Quittungen und einen unveränderlichen Audit Trail. Das ist nicht optional für Produktions-Commerce.

• Das MCP-Tool ist die Trust-Grenze. Der Agent hat nie direkten API-Zugriff. Jede Aktion geht durch ein gesteuertes Tool, das validiert, Policy prüft und loggt.

• Default-Deny-Policy ist nicht verhandelbar. Wenn keine explizite Allow-Regel existiert, wird die Aktion abgelehnt. Deny-Regeln überschreiben immer Allow-Regeln.

• HITL-Gates sind konfigurierbar, nicht binär. Kleine Bestellungen gehen automatisch durch. Große Bestellungen warten auf menschliche Freigabe. Die Schwelle ist per Tenant und per Aktion einstellbar.

• HMAC-Quittungen beweisen, was passiert ist. Per-Tenant Signing Keys, kanonische JSON-Serialisierung, hex-kodierter HMAC-SHA256. Verifizierbar durch jede Partei mit dem Secret.

• Idempotenz verhindert Doppelbestellungen. Der Schlüssel muss Konversationskontext (Thread-ID) enthalten, nicht nur die Bestelldaten.

• Fang mit Suche an, graduiere zum Checkout. Gib Agenten nicht am ersten Tag autonome Kaufkraft. Baue Vertrauen schrittweise auf mit Daten zu Genauigkeit und Fehlerraten.

Agentic Commerce ist unvermeidlich. Die Frage ist, ob du die Governance zuerst baust oder den Schaden danach aufräumst. Wir haben ACP gebaut, weil wir es für eine echte Multi-Tenant Commerce-Plattform mit mehreren Lieferanten und KI-gestützten Buchungsagenten gebraucht haben. Das Protokoll funktioniert. Die Architektur ist produktionserprobt.

Wenn du KI-gestützten Handel baust und Hilfe beim Design der Governance-Schicht brauchst, sprich mit unserem Team oder fordere ein Angebot an. Du kannst auch unsere KI-Services und unsere E-Commerce-Architektur-Praxis für mehr Kontext erkunden.