Grundlagen

Was ist Agentic Commerce?

Agentic Commerce bezeichnet Einkäufe und Serviceprozesse, die ein KI-Agent im Auftrag eines Menschen selbstständig erledigt, vom Suchen über das Vergleichen bis zum Bezahlen. Der Mensch gibt nur noch das Ziel und die Grenzen vor, die einzelnen Schritte übernimmt der Agent.

Das betrifft perspektivisch B2C-Shops genauso wie B2B-Portale. Erste agentische Lösungen können bereits Produkte suchen, Bestellprozesse vorbereiten oder auf freigegebene Konto- und Servicedaten zugreifen. Vollständig autonome Abläufe, die Rechnungen abrufen, Vertragsdaten ändern oder Käufe ohne erneute Bestätigung abschließen, sind jedoch noch nicht flächendeckend etabliert.

Überall, wo bisher ausschließlich ein Mensch mit Login und Passwort erwartet wurde, müssen Unternehmen künftig auch Software berücksichtigen, die in seinem Auftrag handelt.

Kurz zur Abgrenzung: In unserem Beitrag zu AI Security schauen wir auf KI-Agenten, die innerhalb deines Unternehmens arbeiten. Hier geht es um die Agenten deiner Kunden, also um Software, die von außen ins Kundenkonto will.

Herausforderung

Warum ist Agentic Commerce ein Problem für das Kundenkonto?

Heutige Kundenkonten kennen nur zwei Arten von Besuchern, Menschen und Bots, und der Agent eines echten Kunden passt in keine der beiden Schubladen. Daraus entstehen drei ganz handfeste Probleme.

Mensch oder Bot? Weder noch.

Dein Login, deine Session-Logik und deine Bot-Erkennung sind auf eine einfache Unterscheidung gebaut: Ein Mensch darf rein, ein Bot bleibt draußen. Maschinenzugriffe an sich sind dabei nichts Neues, Partnerschnittstellen laufen seit Jahren über technische Clients. Neu ist der Zugriff im Auftrag eines einzelnen Verbrauchers, mit Grenzen, die dieser selbst gesetzt hat.

Der Agent eines Kunden ist technisch gesehen ein Bot, inhaltlich ist er aber im Auftrag eines zahlenden Kunden unterwegs. Sperrst du ihn aus, verärgerst du den Kunden. Lässt du ihn rein wie einen Menschen, weißt du nicht, was er darf.

Der bequemste Weg ist der gefährlichste

Aus Kundensicht liegt die Lösung nahe: Benutzername und Passwort einfach an den Assistenten weitergeben. Dadurch kann der Agent jedoch gegenüber dem Shop wie die Kundin selbst erscheinen. Je nach Umsetzung muss er MFA zwar weiterhin durchlaufen; werden zusätzlich Sitzungen, Einmalcodes oder bereits ausgestellte Tokens weitergegeben, kann die Schutzwirkung der MFA aber unterlaufen werden.

Vor allem fehlen eine getrennte Agentenidentität, begrenzte Rechte und eine eindeutige Zuordnung der Aktionen. Der Agent erhält dann potenziell denselben Zugriff auf Adressen, Zahlungsmittel und Kontofunktionen wie die Kundin.

Bot-Abwehr trifft die Falschen

Captchas und klassische Bot-Erkennung allein lösen das Problem nicht. Sie können erwünschte automatisierte Zugriffe blockieren oder zusätzliche Reibung erzeugen, während fortgeschrittene Betrugsbots einzelne Erkennungsmechanismen umgehen können.

Trotzdem bleiben Bot-Management, Betrugserkennung und risikobasierte Prüfungen wichtige Schutzschichten. Für legitime Kundenagenten braucht es zusätzlich einen verifizierbaren Delegationsnachweis, damit der Shop sie nicht allein anhand ihres Verhaltens beurteilen muss.

Vergleich

Wie unterscheidet man den Agenten eines Kunden von einem Bot?

Entscheidend ist die Delegation: Ein legitimer Kundenagent kann nachweisen, für wen er handelt, in welchem Auftrag und mit welchen Rechten. Die folgende Übersicht zeigt, woran du die drei Typen auseinanderhältst.

Das bedeutet konkret: Das eigentliche Risiko steckt in der mittleren Spalte. Sie wirkt harmlos, weil ein echter Kunde dahintersteht. Trotzdem bricht sie jede Sicherheitsannahme, die dein Kundenkonto bisher getroffen hat.

Delegation

Wie funktioniert delegierter Zugriff für KI-Agenten?

Beim delegierten Zugriff meldet sich nur der Kunde mit seinen eigenen Zugangsdaten an und stattet seinen Agenten mit einem eigenen, eng begrenzten Berechtigungsnachweis aus. Das Passwort bleibt dabei immer beim Kunden. In der Praxis sieht der Ablauf so aus:

1. Der Kunde meldet sich selbst an und erteilt den Auftrag. Er authentifiziert sich wie gewohnt, gerne mit Passkey oder MFA, und legt fest, was der Agent tun soll. Zum Beispiel: „Druckerpatronen nachbestellen, maximal 40 Euro.“
2. Der Agent bekommt ein eigenes Token mit klarem Umfang. Darin steht, welche Aktion erlaubt ist, für welche Zielsysteme es gilt und wie lange es verwendet werden darf. Ein kurzes Ablaufdatum und ein enger Berechtigungsumfang begrenzen den Schaden bei einem Diebstahl.
3. Bei kritischen Aktionen fragt das System beim Kunden nach. Eine Zahlung über dem vereinbarten Betrag, eine neue Lieferadresse oder eine Kündigung lösen eine Rückfrage aus, etwa als Push-Nachricht aufs Smartphone. Erst nach dem Okay geht es weiter.
4. Jede Aktion wird protokolliert. Im Log steht dann „für Kundin X durch Agent Y“. Im Streitfall siehst du sofort, wer was ausgelöst hat.
5. Der Kunde behält die Kontrolle. Idealerweise sieht er in seinem Kundenkonto alle Agenten, denen er Rechte gegeben hat, und kann einzelne Berechtigungen gezielt entziehen, ohne gleich sein Passwort ändern oder alle Sitzungen beenden zu müssen.

Das Gute daran: Du musst nicht bei null anfangen. OAuth bietet ein etabliertes Fundament für delegierte Zugriffe. OAuth 2.0 Token Exchange nach RFC 8693 kann dabei Delegation und Identitätsverkettung abbilden, wenn Subjekt und handelnder Akteur getrennt repräsentiert und vom Autorisierungsserver geprüft werden.

Für die inhaltliche Begrenzung, also das Limit von 40 Euro und die Beschränkung auf eine bestimmte Produktkategorie, sind Rich Authorization Requests nach RFC 9396 der passende Baustein.

Für feinere Laufzeitentscheidungen arbeitet die OpenID Foundation im Rahmen von AuthZEN an ergänzenden Spezifikationen. Der Access Request and Approval Profile liegt derzeit als Working Group Draft vor und beschreibt Abläufe, in denen vor einer erneuten Autorisierungsentscheidung zunächst Voraussetzungen wie eine Freigabe, Einwilligung oder zusätzliche Prüfung erfüllt werden müssen. Die Bausteine sind also vorhanden, ergeben aber noch keinen vollständigen, überall interoperablen Standard für Agentic Commerce.

Daten und Einwilligungen

Was bedeutet Agentic Commerce für Einwilligungen und Profile?

Agentic Commerce zwingt dich, drei Bereiche neu zu denken, die bisher stillschweigend davon ausgingen, dass immer ein Mensch vor dem Bildschirm sitzt: Einwilligungen, Profildaten und Betrugserkennung. Wir bleiben hier bewusst auf der technischen Seite, die rechtliche Bewertung gehört in die Hände deiner Datenschutz- und Rechtsabteilung.

Einwilligungen

Ein Beispiel: Die Kundin hat dem Empfang eines Newsletters zugestimmt. Diese Einwilligung beantwortet nicht automatisch die separate Frage, ob ein Agent Angebote aus dem Kundenkonto abrufen, auswerten oder Daten an einen Drittanbieter übermitteln darf.

Technisch brauchst du deshalb ein Berechtigungs- und Consent-Modell, das Zweck, Datenumfang, Empfänger und Agent getrennt abbilden kann. Ob dafür rechtlich eine zusätzliche Einwilligung erforderlich ist oder eine andere Rechtsgrundlage greift, muss die Datenschutz- und Rechtsabteilung für den konkreten Ablauf bewerten.

Wie Einwilligungen schon beim Login sauber erfasst werden, haben wir in unserem Beitrag zu Social Login beschrieben.

Profildaten

Nicht jedes Feld im Kundenprofil gehört in die Reichweite eines Agenten. Ob Lieferadresse oder Bestellhistorie für eine Nachbestellung erforderlich sind, hängt vom konkreten Zweck und vom Prinzip der Datenminimierung ab. Besonders schutzbedürftig oder missbrauchsrelevant können etwa Geburtsdatum, Zahlungsdaten und Änderungen an E-Mail-Adresse, Lieferadresse oder Wiederherstellungsoptionen sein.

Hier hilft eine klare Einteilung in Daten, die ein Agent für einen bestimmten Auftrag lesen darf, Daten, die er unter definierten Bedingungen ändern darf, und Daten oder Aktionen, die eine erneute Bestätigung durch den Menschen erfordern.

Betrugserkennung

Agenten verhalten sich anders als Menschen. Sie klicken schneller, bestellen nachts um drei und brauchen keine Pause zwischen zwei Formularfeldern. Betrugsregeln, die auf menschliches Verhalten trainiert sind, schlagen dann falsch Alarm.

Die Lösung: Führ Agenten als eigene Kategorie, mit eigenen Normalwerten und eigenen Schwellen.

B2B

Was ändert sich bei Agentic Commerce im B2B?

Im B2B handelt ein Agent für eine Person und gleichzeitig für deren Unternehmen, deshalb braucht er Firmenrollen, Budgetgrenzen und Freigabewege. Genau hier wird es spannend, und genau hier greifen die üblichen Marketing-Betrachtungen zu kurz.

Stell dir vor, ein Einkäufer bei einem Maschinenbauer lässt seinen Agenten Ersatzteile im Portal eines Zulieferers bestellen. Der Agent muss dann wissen:

• Welche Rolle hat der Einkäufer im Unternehmen? Darf er nur für seinen Standort bestellen oder für die ganze Gruppe?
• Welches Budget gilt? Bis 5.000 Euro freihändig, darüber mit Freigabe der Abteilungsleitung?
• Welche Freigabewege gibt es? Wer bekommt die Rückfrage, wenn der Agent eine Grenze erreicht, der Einkäufer selbst oder sein Vorgesetzter?
• Was passiert beim Ausscheiden? Verlässt der Einkäufer das Unternehmen, müssen auch alle Agenten, die er beauftragt hat, sofort ihre Rechte verlieren.

Kurz gesagt: Der Agent erbt ein ganzes Geflecht aus Organisation, Rollen und Regeln. Wer im B2B-Portal schon heute sauber mit delegierter Administration arbeitet, hat hier einen klaren Vorsprung.

Wie das aussehen kann, zeigen wir in unseren Beiträgen zu User Self Service im B2B und Partner Identity Management.

Praxis

Wie fangen Unternehmen jetzt pragmatisch an?

Am besten klein und messbar: erst Agenten-Traffic sichtbar machen, dann unkritische Anwendungsfälle freigeben und parallel prüfen, ob dein CIAM-System delegierte Tokens beherrscht. Unser Expertenrat bei amiconsult sieht vier Schritte vor:

FAQ

Häufige Fragen zu Agentic Commerce und CIAM