AP2 Zahlungsmandate vs Enterprise Agent Authority

Rezensiert 11. August 2026 · 14 Minuten gelesen

AP2-Zahlungsmandate autorisieren die Zahlung für eine bestimmte Kasse und können den Zahlungsempfänger, das Zahlungsinstrument, den Betrag, das Budget und den Ausführungstermin einschränken. Die Befugnis des Unternehmensagenten beantwortet eine breitere Reihe von Fragen: Welche Organisation besitzt den Agenten, warum handelt er, welche Werkzeuge und Daten kann er verwenden, ob er delegiert werden kann, welche internen Genehmigungen gelten und welche Beweise für Nichtzahlungsaktionen müssen aufbewahrt werden.

Dieser Artikel richtet sich an Zahlungsarchitekten und Agenten-Plattform-Ingenieure, die AP2 in Enterprise-Workflows integrieren. Das Ergebnis ist ein Kompositionsmodell, das die Zahlungssemantik von AP2 bewahrt und gleichzeitig die Behauptung vermeidet, dass ein Zahlungsauftrag jede Aktion autorisiert, die zu einem Kauf führt.

Für das breitere Kontrollmuster lesen Sie die Agentic Payments Architecture Guide und Identität versus Autorität für agentische Systeme.

Was AP2-Zahlungsmandate autorisieren

AP2 v0.2 definiert ein Checkout-Mandat und ein verknüpftes Zahlungsmandat, wobei das Checkout-Mandat dem Händler kryptografische Beweise dafür liefert, dass der Einkaufsagent berechtigt ist, den zusammengebauten Checkout zu kaufen, und wobei das Zahlungsmandat den Zahlungsrollen den Nachweis liefert, dass der Agent berechtigt ist, für diesen Checkout zu bezahlen. Die offizielle AP2-Spezifikation ist die Autorität für diese Protokollansprüche.

Das geschlossene Zahlungsmandat umfasst eine Transaktionskennung, die an Checkout, Zahlungsempfänger, Zahlungsbetrag, Zahlungsinstrument und optionales Ausführungsdatum gebunden ist. AP2 Zahlungsauftrag dokumentiert diese Felder und Einschränkungen.

AP2 unterscheidet auch menschliche Gegenwart und autonome Flüsse. Im autonomen Modus drücken offene Mandate Einschränkungen aus, und der Agent bindet ein geschlossenes Mandat an eine Transaktion, die sie erfüllt.

Das ist eine substanzielle Autorität und auch zahlungsspezifisch.

Was Enterprise Authority hinzufügt

Betrachten Sie einen Beschaffungsagenten, der einen Lieferanten entdeckt, Vertragspreise liest, die Lieferung aushandelt, eine Bestellung erstellt und dann zahlt.

Die Zahlungsberechtigung antwortet nicht unbedingt:

• ob der Agent den vertraulichen Katalog lesen darf
• ob der Lieferant durch Beschaffung zugelassen ist
• ob der Kauf einen autorisierten Geschäftszweck unterstützt
• ob der Agent Vertragsbedingungen aushandeln darf
• ob ein Kinderagent die Befugnis erben kann
• ob dieser Gegenpartei Daten übermittelt werden dürfen
• ob die Inventarreservierung oder Bestellung autorisiert wurde
• welche interne Richtlinie und welcher Genehmiger die Aktion zugelassen haben
• Wie Sie den Nichtzahlungszugang des Agenten sofort widerrufen können

Dies sind Transaktionskontrollen für Unternehmen. Sie können durch IAM, Policy Engines, Gateways, Workflow-Genehmigungen und ein OATI-Mandat durchgesetzt werden. AP2 muss nicht alle kopieren, um nützlich zu sein.

Die Policy-Objekte direkt vergleichen

Das Agent Authorization Framework von AP2 besagt, dass das Mandatsmodell in Zukunft allgemeiner gelten könnte, während AP2 es für Zahlungen verwendet. AP2-Agentenautorisierung unterstützt eine präzise Schlussfolgerung: Unternehmensplattformen können mit AP2 komponieren, ohne dass AP2 bereits jede Unternehmenssteuerung spezifiziert.

Erstellen Sie die Schichten um eine Transaktion

enterprise intent and policy
  -> enterprise agent mandate
  -> supplier discovery and checkout creation
  -> merchant-signed checkout
  -> AP2 Checkout Mandate
  -> AP2 Payment Mandate
  -> credential and payment processing
  -> AP2 Checkout and Payment Receipts
  -> enterprise Action Receipt and reconciliation

Das Enterprise-Mandat sollte das AP2-Zahlungsmandatsbyte nicht für Byte kopieren, sondern die Objekte durch stabile Referenzen und Digests binden.

type EnterprisePaymentContext = {
  enterpriseTransactionId: string;
  agentId: string;
  organisationId: string;
  mandateId: string;
  purpose: 'approved_supplier_invoice' | 'approved_procurement';
  supplierId: string;
  ap2MerchantId: string;
  invoiceId?: string;
  checkoutDigest: `sha256:${string}`;
  ap2PaymentTransactionId: string;
  maximumAmount: { currency: string; valueMinor: bigint };
  policyDigest: `sha256:${string}`;
  approvalId?: string;
};

Dies ist illustrativer Anwendungscode, kein AP2-Schema. vct Werte.

Bindung vor der Genehmigung

Eine Unternehmenszulassung wie "Büroausrüstung genehmigen" ist zu locker. Binden Sie sie an den Lieferanten, Artikel, Menge, Gesamtsumme, Währung, Zahlungsziel und Checkout-Digest. Wenn der Händler die Checkout ändert, erstellen Sie eine neue Autorisierungsentscheidung.

function verifyComposition(
  enterprise: EnterprisePaymentContext,
  ap2: ClosedPaymentMandate,
  checkout: MerchantSignedCheckout,
): ReasonCode[] {
  const reasons: ReasonCode[] = [];
  if (sha256(checkout.jwt) !== enterprise.checkoutDigest)
    reasons.push('ENTERPRISE_CHECKOUT_DIGEST_MISMATCH');
  if (ap2.transaction_id !== hashCheckout(checkout.jwt))
    reasons.push('AP2_CHECKOUT_BINDING_MISMATCH');
  if (ap2.payee.id !== enterprise.ap2MerchantId)
    reasons.push('SUPPLIER_PAYEE_MISMATCH');
  if (!withinLimit(ap2.payment_amount, enterprise.maximumAmount))
    reasons.push('ENTERPRISE_AMOUNT_EXCEEDED');
  return reasons.sort();
}

Reale Zuordnungen erfordern eine maßgebliche Lieferantenkennung. Der Vergleich eines Anzeigenamens ist nicht sicher. Verwenden Sie verifizierte Rechtsträger-, Händler-Domain- oder Registry-Zuordnungen, die für den Einsatz geeignet sind.

Bewahren Sie Zahlungsinformationen außerhalb des Modells auf

Der Einkaufsagent kann Mandatsinhalte zusammenstellen, aber die vertrauenswürdige Oberfläche, der Anmelder und die Zahlungsrollen führen definierte Signatur- und Verifizierungsarbeiten durch.

Ein Enterprise-Gateway kann die AP2-Objekte an einen konformen Zahlungsadapter übergeben, nachdem seine eigene Richtlinie den Betrieb ermöglicht.

Das Modell kann eine Ablehnung erklären, z. B. eine Überschreitung des Betrags oder eine ungelöste Einschränkung.

Eingänge überlappen, ohne identisch zu sein

AP2 verlangt Checkout- und Zahlungsquittungen nach Annahme oder Ablehnung und beschreibt die Zusammenführung von Mandaten und Quittungen für Streitbeweise.

Eine Enterprise Action Quittung muss möglicherweise interne Zwecke, Policy Digest, Genehmigung, Rechnung, Bestellreferenz und Nichtzahlungs-Tool-Historie enthalten.

{
  "enterprise_transaction_id": "oati:tx:purchase-8841",
  "decision": "allow",
  "mandate_id": "oati:mandate:invoice-8841",
  "policy_digest": "sha256:...",
  "checkout_digest": "sha256:...",
  "ap2_payment_transaction_id": "base64url-hash...",
  "ap2_payment_receipt_digest": "sha256:...",
  "provider_reference": "pay_7319",
  "outcome": "pending"
}

Dies ist ein konzeptionelles Anwendungsprotokoll, kein wörtlicher OATI-Aktionsbeleg.

Keine Quittung beweist, dass eine Rechnung rechtmäßig war oder Waren angekommen sind, sie beweist, was der Emittent aufgezeichnet und unterschrieben hat, und Bestell- und Zahlungssysteme bleiben für die Änderung des Ergebniszustands maßgebend.

Widerruf und Konsum brauchen einen koordinierten Staat

Ein offenes Zahlungsmandat mit einem Budget erfordert eine kumulierte Nutzung. Ein Unternehmensmandat kann sein eigenes kumulatives Budget, eine Anrufanzahl oder eine einmalige Nutzung haben.

Es gibt keine systemübergreifende Atomtransaktion zwischen jedem Unternehmens-Ledger und Zahlungsteilnehmer, sondern stabile Idempotenz, Vergleichs- und Vergleichsverbrauch und Abgleich.

RECEIVED -> ENTERPRISE_AUTHORIZED -> AP2_VERIFIED -> SUBMITTED
   -> ACCEPTED | REJECTED | UNKNOWN
   -> SETTLED | FAILED | REVERSED

Wenn die Einreichung unbekannt wird, geben Sie nicht beide Budgets frei und versuchen Sie es erneut mit einer neuen Transaktion.

Das Unternehmen kann einen Agenten oder ein Mandat vor der Ausführung widerrufen, auch wenn ein AP2-Objekt kryptographisch gültig bleibt. Umgekehrt kann ein gültiges Unternehmensmandat ein abgelaufenes oder ungültiges AP2-Zahlungsmandat nicht retten.

Ausfallfälle und Wiederherstellung

AP2 definiert unresolved_constraint Ein nicht-agentischer Fallback oder ein neues direkt genehmigtes Mandat ist sicherer.

Reproduzierbare Zusammensetzungsprüfung

Erstellen Sie eine vom Händler signierte Kasse, eine Enterprise Authority und ein AP2-Zahlungsmandat, zeichnen Sie die genauen erwarteten Digests auf und mutieren Sie dann ein Feld nach dem anderen:

1. Erhöhen Sie den Zahlungsbetrag um eine kleinere Einheit über der Unternehmensobergrenze.
2. Ersetzen Sie den Zahlungsempfänger unter Beibehaltung der gleichen Unternehmenslieferantenreferenz.
3. Ändern Sie den Checkout JWT nach der Genehmigung.
4. Läuft das Unternehmensmandat ab, behält aber die AP2-Gültigkeit.
5. Läuft AP2 ab, während das Unternehmensmandat gültig bleibt.
6. Senden Sie die gleiche Transaktion zweimal gleichzeitig.
7. Entfernen Sie den AP2-Beleg aus dem Beweispaket.

Die Prüfstelle sollte deterministische, sortierte Grundcodes zurückgeben und Null-Anbieter-Aufrufe für abgelehnte Vorrichtungen durchführen; die gleichzeitig gültige Vorrichtung sollte einen Anbieter-Vorgang und ein erstattungsfähiges vorheriges Ergebnis für den Wiederholungsversuch ergeben.

Aktueller Intelliger und OATI Grenze

OATI und AP2 sind separate Standards. Die aktuelle Entwicklervorschau von OATI implementiert allgemeine Passport-, Mandate-, Transaction Envelope-, deterministische Bewertungs- und Aktionsempfangsobjekte, einschließlich Commerce-Preis- und Budgetbeschränkungen. Sie beansprucht keine native AP2 v0.2-Konformität oder einen Produktions-AP2-Zahlungsanschluss.

Die derzeitige kommerzielle MVP-Richtung von Intelliger ist Agent Spend Control über einen bestehenden Zahlungsanbieter, Schiene und Währung. Intelliger hält keine Gelder und behauptet nicht, eine Bank, Depotbank oder Treasury-Plattform zu sein. Der Provider-Connector, das dauerhafte Zahlungsbuch, der Abgleich und der Workflow des Auditpakets bleiben MVP oder unvollständige Produktionsarbeiten.

Das implementierte OATI-Framework hat keine unabhängige Kryptographie- und Protokollprüfung, die vollständige Zwei-Unternehmen-Produktionsannahme oder dauerhafte Streitbeilegungsworkflows abgeschlossen.

Lesen Automatisierung von Zahlungskonten ohne doppelte Zahlungen für das State-Machine-Detail und erkunden Sie die aktuelle OATI offene Standardseiten für implementierte Entwicklerfähigkeiten.

Checkliste der Durchführung

• Behandeln Sie AP2 als Zahlungsberechtigung, nicht als universelle Unternehmenspolitik.
• Bewahren Sie genaue AP2-Schemata, Versionen und Verifizierungsregeln auf.
• Binden Sie die Unternehmenszulassung an den vom Händler signierten Checkout-Digest.
• Karte Lieferantenidentität zum AP2-Zahlungsempfänger durch ein maßgebliches Register.
• Bewerten Sie Unternehmens- und AP2-Einschränkungen deterministisch.
• Bewahren Sie Zahlungsinformationen und wiederverwendbare Geheimnisse außerhalb des Modellkontexts auf.
• Verfolgen Sie den Unternehmens- und AP2-Budgetverbrauch unter Parallelität.
• Tragen Sie stabile Transaktion und Anbieterreferenzen durch Retries.
• Verknüpfen Sie AP2-Empfänge, anstatt sie durch interne Protokolle zu ersetzen.
• Überprüfen Sie den Widerruf und Ablauf an der endgültigen Ausführungsgrenze erneut.
• Abgleichen Sie unbekannte, abgerechnete, gescheiterte und umgekehrte Ergebnisse separat.
• Testen Sie jede Schicht gültig, während die andere ungültig ist.

Ein AP2-Protokoll-Reviewer, ein Zahlungsarchitekt und ein Sicherheits-Reviewer sollten die Details der Mandatsversion, die Checkout-Bindung, die selektive Offenlegung, den Budgetverbrauch und die gesamte Streitbeweissprache überprüfen.

Verwendung der Agentische Zahlungsverkehrskontrollarchitektur Um Unternehmensentscheidungspunkte vor der Implementierung des AP2-Adapters abzubilden.