Agentisches Zahlungssicherheitsbedrohungsmodell
Threat-Modell agentische Zahlungen über Absicht, Rechnungsdaten, Genehmigung, Anmeldeinformationen, Ausführung und Abwicklung mit konkreten Kontrollen und Missbrauchstests.
Ein agentisches Zahlungsbedrohungsmodell muss die gesamte Transaktion abdecken, nicht nur das Modell. Rechnungsinhalte können den Agenten manipulieren, ein gültiger Anmeldenachweis kann missbraucht werden, eine Genehmigung kann ersetzt werden, ein Provider-Timeout kann ein Duplikat auslösen und ein signierter Datensatz kann immer noch einen falschen Quellenanspruch enthalten.
Der volle Agentische Zahlungsarchitektur Hier greifen wir jede Grenze an und erklären, was passieren muss, wenn eine Kontrolle versagt.
Zeichnen Sie die Vertrauensgrenzen
untrusted documents -> agent proposal -> schema validator
-> authority and policy
human approval ----------------------> exact request digest
credential broker -------------------> payment adapter -> provider
provider events ----------------------> reconciler -> evidence store
Bewahren Sie Zahlungsinformationen außerhalb des Modellkontexts auf, lösen Sie Lieferanten- und Zielkennungen von geregelten Systemen auf, behandeln Sie Rechnungstext, E-Mails, abgerufene Seiten und Modellzusammenfassungen als nicht vertrauenswürdige Eingaben.
Kartenmissbrauch für Kontrollen
| Bedrohung | Kontrollieren | Störfallvorrichtung |
|---|---|---|
| Soforteinspritzung der Rechnung | Strenge Extraktion plus Außenpolitik | Rechnung sagt, Genehmigung zu überspringen |
| Bestimmungsbestimmung | Geprüftes Zielregister | Konto unterscheidet sich durch einen Identifikator |
| Ersatzgenehmigung | Canonic Request Digest | Änderungen der genehmigten Menge vor dem Versand |
| Berechtigungsdiebstahl | vermittelte, enge, kurzlebige Anmeldeinformationen | Token erscheint im Tool Output |
| Mandatswiederholung | Nonce- und Atomnutzungsanspruch | zwei KI-Worker nutzen letzte erlaubte Transaktion |
| Doppelzahlung | Domain-Idempotenz und Abgleich | Anbieter akzeptiert dann Zeiten |
| Fälliger Vergleich | Provider-Abfrage oder signierte Veranstaltung | Agent sagt "bezahlt" ohne Anbieternachweis |
| Gateway Bypass | Service Identity und Netzwerkpolitik | Adapter direkt aufgerufen |
OWASP Agentische Bedrohungen und Minderungsmaßnahmen Der PCI Security Standards Council befasst sich mit Ziel-Hijacking, Missbrauch von Werkzeugen und Missbrauch von Privilegien. KI-Prinzipien für Zahlungsumgebungen Die Anwendbarkeit auf ein System erfordert eine unabhängige Bewertung.
Separate Transaktionszustände
PROPOSED -> DENIED | APPROVAL_REQUIRED | AUTHORIZED
AUTHORIZED -> NOT_DISPATCHED | SUBMITTED
SUBMITTED -> ACCEPTED | REJECTED | UNCERTAIN
ACCEPTED -> SETTLED | FAILED | REVERSED | RETURNED
Ein Timeout nach der Einreichung ist uncertainWenn Sie mit einem neuen idempotency-Schlüssel erneut versuchen, können Sie ein Duplikat erstellen.
Googles AP2-Spezifikation Bereitstellung von unterzeichneten Mandats- und Zahlungsobjekten für Protokollteilnehmer. Unternehmensführung, interne Genehmigungen, Anbieterbetrieb und Abgleich bleiben getrennte Verantwortlichkeiten.
Bedrohungen durch Schauspieler überprüfen
Ein externer Angreifer kann eine Rechnung vergiften oder einen Beleg stehlen. Ein kompromittiertes Lieferantenkonto kann eine Zieländerung verlangen. Ein böswilliger Mitarbeiter kann eine Out-of-Policy-Zahlung genehmigen. Ein fehlerhafter Agent kann eine Rechnung in mehrere Vorschläge aufteilen. Ein Zahlungsanbieter oder ein interner Adapter kann einen inkonsistenten Zustand zurückgeben. Jedem Akteur eine Kontroll- und Beweisquelle zuweisen, anstatt Betrug als eine Modellrisikokategorie zu behandeln.
Verfügbarkeitsbedrohungen einschließen. Ein Angreifer, der die Richtlinie oder den Wiedergabedienst deaktiviert, kann hoffen, dass die Betreiber auf eine ungeschützte Route wechseln. Definieren Sie, welche Lesevorgänge mit dem Bounded-Stale-Zustand fortgesetzt werden können und welche wertverändernden Aktionen gestoppt werden müssen. Testen Sie den Betriebsdruck, einschließlich der Frage, ob der dokumentierte Break-Glas-Pfad von einem Agenten verwendet werden kann.
Für jede Bedrohung sind die präventive Kontrolle, das Detektivsignal, die Wiederherstellungsaktion, das Restrisiko und der Testbesitzer aufzuzeichnen; das Modell bei Änderungen eines Zahlungsschienen-, Lieferanten-Onboarding-Pfads, eines Anmeldedatenflusses oder eines Delegationsmusters für Agenten zu überprüfen.
Verwendung Zahlungs-Idempotenz für KI-Agenten und Genaue Zahlungsgenehmigung Einzelheiten zur Umsetzung. Agentische Handelsplattform für den Live Business Workflow.
Dieses Bedrohungsmodell beansprucht keine PCI-Compliance, keine Betrugspräventionszertifizierung oder den Betrieb von Produktions-Zahlungsschienen.
Threat-Model Review-Fragen
Was ist der geschützte Vermögenswert?
Mehr als Geld auflisten. Zahlungsnachweise, Lieferantenziele, Genehmigungsbehörde, Rechnungsstatus, persönliche Daten, Transaktionsverfügbarkeit und vertrauenswürdige Beweise schützen. Ein Angreifer könnte es vorziehen, ein Ziel zu ändern oder eine Umkehrung zu verbergen, anstatt ein Token zu stehlen. Jedes Asset mit seinem maßgeblichen System und dem Eigentümer des Vorfalls verknüpfen.
Wohin geht die prompte Injektion?
Es kann über Rechnungen, E-Mails, Webseiten, Lieferantennachrichten, Tool-Ausgaben und Speicher eintreffen. Diese Quellen als nicht vertrauenswürdig markieren und sie außerhalb deterministischer Richtlinien halten. Testdokumente, die den Agenten auffordern, Anmeldeinformationen preiszugeben, Ziele zu ändern, Zahlungen aufzuteilen oder Genehmigungen neu zu interpretieren. Der erwartete Schutz ist eine externe Kontrolle, nicht nur eine Modellverweigerung.
Kann ein vertrauenswürdiger Mitarbeiter der Bedrohungsakteur sein?
Ja. Muster-Missbrauchsfälle für Genehmigungsabsprachen, Lieferanten-Master-Änderungen, privilegierte Gateway-Konfiguration und Evidenzlöschung. Aufgabentrennung, genaue Genehmigung, unveränderliche Überprüfungsaufzeichnungen und unabhängige Domänenabgleichhilfe. Administratoraktionen für die Kontrollen selbst aufzeichnen.
Wie werden Zahlungsanmeldeinformationen erfasst?
Bewahren Sie Anmeldeinformationen in einem Broker oder Adapter auf, beschränken Sie sie auf die beabsichtigte Entität, Schiene und den Betrieb, wo sie unterstützt werden, drehen Sie sie und blockieren Sie den Zugriff aus dem Modellkontext. Ein enger Anmeldenachweis benötigt immer noch eine Transaktionsautorisierung. Testen Sie, ob ein gestohlener Adapter-Token direkt um das Gateway herum verwendet werden kann.
Was ist der Verfügbarkeitsangriff?
Ein angreifer kann richtlinien, wiederholungs- oder zuliefersysteme deaktivieren, um betreiber in umgehung zu drängen, fehlverhalten und einen menschlichen glasbruchpfad vor dem ereignis definieren, wesentliche zahlungen sollten nicht erlaubt werden, weil eine erforderliche tatsache unbekannt ist.
Wann ist das Bedrohungsmodell abgeschlossen?
Es ist nie endgültig. Eine akzeptierte Version für einen benannten Architektur- und Aktionssatz erstellen und ihn dann aktualisieren, wenn sich Schienen, Anbieter, Tools, Anmeldeinformationen, Genehmigungen, Delegationen oder Beweise ändern. Jede Überprüfung mit Testbesitzern und Restrisikoentscheidungen abschließen, keine Liste von Bedrohungen ohne Maßnahmen.
Fügen Sie der Überprüfung eine Ende-zu-Ende-Betrugsgeschichte hinzu. Ein Lieferantenbriefkasten ist kompromittiert, eine Rechnung enthält neue Bankdaten und eine Anweisung, die Änderung als dringend zu behandeln, der Agent erstellt einen selbstbewussten Vorschlag und der Anbieter spätere Zeiten. Gehen Sie die Anfrage durch Extraktion, Zielüberprüfung, Autorität, Genehmigung, Idempotenz und Abgleich. Nennen Sie an jeder Grenze das System, das die Zahlung stoppen kann, und den Datensatz, den es produziert. Wenn die einzige zuverlässige Verteidigung darin besteht, dass das Modell bemerken sollte, dass die E-Mail verdächtig klingt, ist das Design nicht bereit für diese Aktion.
Nach jeder Kontrolle das Restrisiko aufzeichnen, auch wer einen genehmigten Pfad noch missbrauchen kann und welche Quelle noch falsch sein könnte. Das hält die Überprüfung ehrlich über vertrauenswürdige Administratoren, kompromittierte Lieferantenaufzeichnungen und Anbieterfehler. Das Ziel ist ein begrenzter, beobachtbarer Fehler, nicht eine Behauptung, dass die Architektur Betrug unmöglich macht.