Enterprise AI Agents: Sichere Transaktionen mit einem Unternehmen

12 Minuten Lesezeit

KI-Agenten brauchen nicht jede Gegenpartei, um das gleiche Vertrauensprotokoll zu übernehmen, bevor Transaktionen sicherer werden. Unternehmensübergreifende Standards beginnen oft mit dem Endzustand: kompatible Identitäten, tragbare Autorität, ein gemeinsames Transaktionsformat und Unterschriften beider Unternehmen.

Ein API-Anbieter kann nicht warten, bis jeder Kundenagent einen neuen Trust-Stack installiert. Ein kaufendes Unternehmen kann nicht verlangen, dass jeder Lieferant sein Agentenprotokoll versteht, bevor er einen Kauf automatisiert. Die meisten echten Integrationen beginnen mit einem OAuth-Token, API-Schlüssel, JWT-Subjekt oder einem bestehenden Service-Konto.

Ein teilnehmendes Unternehmen kann die Kontrolle noch verbessern. Es kann die vorhandenen Anmeldeinformationen einer lokalen Agentenidentität zuordnen, eine begrenzte Autorität erfordern, deterministische Richtlinien durchsetzen und eine Quittung für das, was es beobachtet hat, unterschreiben. Die Gegenpartei verwendet weiterhin ihre aktuelle API und Anmeldeinformationen.

Das Ergebnis ist nützlich, aber seine Zusicherung hat eine Grenze. Der Empfang ist ein einseitiger Beweis. Seine Unterschrift beweist, was das entsendende Unternehmen über seine Beobachtung und Kontrolle bestätigt hat. Der Empfang beweist nicht, dass jeder Weg durch die Durchsetzung gegangen ist oder dass die andere Partei der Transaktion zugestimmt hat.

Teams können mit gewöhnlichem API-Zugriff beginnen und stärkere bilaterale Beweise hinzufügen, wenn die Gegenpartei bereit ist.

Platzieren Sie Enterprise AI Agent Control auf der Seite, die es braucht

Es gibt zwei nützliche Einsatzmodi.

Im Inbound-Trust platziert ein API-, Daten- oder SaaS-Anbieter ein Durchsetzungs-Gateway vor seinem bestehenden Service. Kundenagenten senden weiterhin gewöhnliche authentifizierte Anfragen. Der Anbieter verwendet das Gateway, um den Zugriff auf Mandanten, erlaubte Operationen, sensible Felder, Nutzung und Beweise zu kontrollieren.

In der Outbound-Kontrolle platziert ein Unternehmen ein Gateway zwischen seinen eigenen Agenten und einem unveränderten Lieferanten, einer SaaS-Plattform, einem Managed-Service-Provider oder einer Zahlungs-API. Das externe System erhält die gleiche Anfrage und das gleiche Anmeldeformat, das es bereits unterstützt. Das Unternehmen verwendet das Gateway, um Ziele, Beträge, Tools und Zwecke einzuschränken, bevor der Datenverkehr seine Umgebung verlässt.

Inbound trust

External agent -> existing credential -> provider gateway -> existing API

Outbound control

Enterprise agent -> enterprise gateway -> existing credential -> external API

Beide Muster beruhen auf dem gleichen Transaktionskern, der Bereitstellungsort und der verantwortliche Betreiber unterscheiden sich.

Betrachten wir einen eingehenden B2B-SaaS-Fall. Ein Kunde hat einen Automatisierungsagenten, der Kontodaten lesen und Rückerstattungen über die bestehende OAuth-API des Anbieters ausstellen kann. Der Anbieter möchte autonome Rückerstattungen auf einen bestimmten Mandanten und Betrag begrenzen, größere Rückerstattungen zur Genehmigung weiterleiten und nachweisen, welche Kontrollen ausgeführt wurden.

Der Kunde muss nichts über das neue Durchsetzungssystem wissen, er präsentiert immer wieder das OAuth-Token, das er bereits hat.

Karte eines vorhandenen Credentials zum lokalen Agentenkontext

Das Gateway authentifiziert die Anfrage zunächst mit dem aktuellen Mechanismus und löst dann die Anmeldeinformationen in einem lokalen Datensatz auf, der die Kundenorganisation, den Agenten oder den Workload, den Mandanten, den Assurance Level und den Status nennt.

credentialMapping:
  issuer: https://identity.customer.example
  subject: 7dbb19f4-2f7a-4f72-a9da-2d65fa4bd915
  audience: https://api.vendor.example
  localOrganisation: org:vendor:customer-418
  localAgent: agent:vendor:customer-418:refund-worker
  tenant: tenant-418
  assurance: credential-mapped
  status: active

Der Anbieter weiß, dass ein verifizierter Anmeldenachweis unter seiner eigenen Leitung einem lokalen Datensatz zuordnet. Er hat keinen von der Kundenorganisation unterzeichneten Reisepass erhalten.

Diese Unterscheidung spielt bei Benutzeroberflächen, Richtlinien und Quittungen eine Rolle. credential-mappedBeschriften Sie den Agenten nicht als "von Kunde A verifiziert", es sei denn, Kunde A hat Beweise vorgelegt, die den Anspruch stützen.

Kartierungsaufzeichnungen erfordern Lebenszykluskontrollen. Nachverfolgen, wer die Kartierung erstellt hat, die maßgeblichen Anmeldemerkmale, die Mandantenbindung, zulässige Zielgruppen, Status, effektive Daten und Widerrufsquelle. Von Anrufern ausgewählte Organisation oder Mandanten-Header ablehnen, es sei denn, ein verifizierter Identitätsanspruch erlaubt dies.

Lokale Autorität hinzufügen, ohne das Remoteprotokoll zu ändern

Der Anbieter kann ein lokales Mandat für den abgebildeten Agenten ausstellen oder verlangen; dieses Mandat drückt aus, was der Anbieter von dieser Identität akzeptiert; er behauptet nicht, dass der Vorstand oder gesetzliche Vertreter des Kunden die Befugnis delegiert hat, es sei denn, der Anbieter hat diese Beweise überprüft.

Für das Erstattungsbeispiel:

{
  "mandateId": "mandate_refunds_tenant_418",
  "subject": "agent:vendor:customer-418:refund-worker",
  "issuer": "org:vendor",
  "purpose": "customer-support-refund",
  "validFrom": "2026-08-10T00:00:00Z",
  "expiresAt": "2026-08-17T00:00:00Z",
  "constraints": {
    "actions": ["refund.create", "refund.status.read"],
    "tenantIds": ["tenant-418"],
    "currencies": ["EUR"],
    "maxAmountMinor": 10000,
    "maxDailyTotalMinor": 50000,
    "destinations": ["original-payment-method"],
    "delegation": { "allowed": false }
  }
}

Das Mandat ist nützlich, weil OAuth Umfange wie refunds:write Ein Mandat kann auch den Mieter, den Betrag, die Währung, den Bestimmungsort, den Zweck, die kumulative Nutzung und den Ablauf begrenzen.

Halten Sie die Autoritätserklärung ehrlich. Bei einer Ein-Teilnehmer-Inbound-Bereitstellung setzt der Anbieter seine eigenen akzeptierten Limits für einen abgebildeten Kundennachweis durch. Eine spätere Integration kann es dem Kunden ermöglichen, ein unterzeichnetes Mandat seines eigenen Emittenten vorzulegen. Das gibt dem Anbieter stärkere Beweise für die kundenseitige Delegation, vorbehaltlich der Vertrauens- und Verifizierungspolitik.

Normalisierung jeder Anfrage in einem Transaktionsumschlag

Legacy-APIs drücken den Kontext an verschiedenen Stellen aus. Der Mieter kann in der URL erscheinen, der Rückerstattungsbetrag in JSON, der Betreff OAuth in einem Token und der Zweck in einem Ticketfeld. Das Gateway sollte diese Werte vor der Richtliniebewertung in einen kanonischen Umschlag extrahieren.

type NormalisedTransaction = {
  transaction: Transaction
  canonicalDigest: string
}

function normaliseRefund(
  req: HttpRequest,
  identity: Identity
): NormalisedTransaction {
  const transaction: Transaction = {
    id: requireIdempotencyKey(req),
    agent: identity.localAgent,
    organisation: identity.localOrganisation,
    tenant: identity.tenant,
    assurance: identity.assurance,
    action: "refund.create",
    resource: `tenant/${req.params.tenantId}/charge/${req.body.chargeId}`,
    counterparty: req.body.merchantAccount,
    destination: "original-payment-method",
    purpose: req.body.reasonCode,
    amount: {
      minor: req.body.amountMinor,
      currency: req.body.currency,
    },
    requestedAt: req.receivedAt,
  }

  return {
    transaction,
    canonicalDigest: sha256(canonicalise(transaction)),
  }
}

Die Schemavalidierung sollte erfolgen, bevor die Transaktion eine Policy-Engine erreicht; unbekannte Währungsformate, Mehrdeutigkeitseinheiten und doppelte Identifikatoren ablehnen; die Canonicalisierung sollte zu einem stabilen Digest führen, der von Richtlinie, Genehmigung, Ausführung und Erhalt verwendet wird.

Lassen Sie den Konnektor keine eindeutige Geschäftsrichtlinie enthalten. Seine Aufgabe besteht darin, zwischen der vorhandenen API und dem Transaktionsmodell zu übersetzen und dann eine autorisierte Transaktion in die Upstream-Anfrage zurückzuübersetzen.

Lokale Richtlinie und Autorität gemeinsam bewerten

Das Gateway überprüft die Anmeldeinformationen und das Mandat, bewertet dann den Umschlag mit der aktuellen Geschäftspolitik.

deny if mapping.status != "active"
deny if mapping.tenant != transaction.tenant
deny if transaction.action not in mandate.constraints.actions
deny if transaction.tenant not in mandate.constraints.tenantIds
deny if transaction.amount.currency not in mandate.constraints.currencies
deny if transaction.amount.minor > mandate.constraints.maxAmountMinor
deny if dailyConsumedMinor + transaction.amount.minor > mandate.constraints.maxDailyTotalMinor
deny if transaction.destination != "original-payment-method"

approval_required if account.riskHold == true
approval_required if transaction.purpose == "exception"

deny if idempotency.reserve(transaction.id, transactionDigest) fails

allow otherwise

Ein Genehmigungsergebnis verbraucht in dieser Skizze nicht die idempotency-Reservierung. Der Anrufer übermittelt später den gleichen Transaktionsverdau mit einer gebundenen Genehmigung erneut und das Gateway reserviert die Ausführung unmittelbar vor dem Versand. pending_approval, reserved, executing und Terminal-Zustände so aufgegeben Genehmigungen und Retries kann nicht stranden den Schlüssel.

Führen Sie diese Richtlinie in der Nähe des geschützten Dienstes aus. Die Datenebene sollte bei jeder Entscheidung nicht von einer SaaS-Runde abhängen. Verteilen Sie signierte Richtlinienpakete und Cache-Vertrauenszustand mit klaren Frischegrenzen. Materialschreiben sollten nicht geschlossen werden, wenn der erforderliche Vertrauens-, Widerrufs- oder Wiedergabezustand nicht verfügbar ist. Wenn ein Team Fail-Open-Verhalten für risikoarme Lesevorgänge zulässt, konfigurieren Sie es separat und explizit.

Das Gateway kann Felder entfernen, die der Agent nicht senden darf, eine Abfrage auf den abgebildeten Mandanten beschränken und sensible Antwortfelder filtern, den Transformationsverdau so aufzeichnen, dass der Beweis die Anforderung beschreibt, die den Dienst tatsächlich erreicht hat.

Behalten Sie den bestehenden API-Vertrag

Die nicht teilnehmende Partei sollte ein gewöhnliches Protokollverhalten sehen.

Für eine Inbound-Bereitstellung erhält der Kundenagent die normale Erfolgsantwort der API, eine strukturierte Ablehnung oder einen anhängigen Zustand, wenn eine Genehmigung erforderlich ist Der Anbieter kann eine Quittungsreferenz als optionalen Response-Header freilegen, ohne dass der Kunde diese verarbeiten muss.

Für eine Outbound-Bereitstellung erhält der Lieferant die gleiche OAuth-Token- oder API-Anfrage, die er bereits erwartet. Das Enterprise-Gateway kann die Anmeldeinformationen vermitteln, die lokale Entscheidung durchsetzen und die Quittung intern speichern. Der Lieferant benötigt kein OATI-Konto, SDK, Passport oder Unterschrift.

Diese Einschränkung verhindert Architekturdrift. Wenn jeder Connector das entfernte System auffordert, ein neues Objektmodell zu übernehmen, bevor es ausgeführt werden kann, ist das Design nicht mehr ein Teilnehmer.

Unterschreiben Sie Beweise mit dem richtigen Assurance Label

Nach der Ausführung kann das Durchsetzungssystem des teilnehmenden Unternehmens eine unterzeichnete Quittung ausstellen, die Folgendes enthält:

• die örtlich abgewickelte Organisation und den Vertreter;
• die Sicherheitsstufe für die Berechtigungszuordnung;
• Mandat und strategische Referenzen;
• der kanonische Request Digest;
• die Entscheidung und etwaige Genehmigung;
• die ausgeführte Anfrage und Antwort verdaut wird;
• die Außendienstnummer;
• Zeitstempel, Nonce- und Idempotenzdaten;
• Metadaten des Emittenten und der Unterschrift.

Die Quittung kann internes Audit, Abrechnungsabgleich und Untersuchung von Vorfällen unterstützen. Ein unabhängiger Prüfer kann die Signatur und die referenzierten Objekte überprüfen, ohne dem Dashboard zu vertrauen, das sie anzeigt.

Es kann keine Tatsachen feststellen, die der Unterzeichner nicht beachtet hat. Im ausgehenden Fall kann eine Quittung beweisen, dass das Unternehmen eine Anfrage gesendet und eine Antwort des Lieferanten aufgezeichnet hat. Es beweist nicht, dass der Lieferant die Bestellung erfüllt hat. Im eingehenden Fall kann es beweisen, was der Anbieter freigegeben hat. Es beweist nicht, dass der Kunde die Anfrage beabsichtigt hat, es sei denn, das vertrauenswürdige Mandat oder die Unterschrift des Kunden stützen diese Schlussfolgerung.

Verwenden Sie progressive Assurance Labels:

Jede Ebene fügt Beweise hinzu; keine sollte die Bedeutung einer früheren Quittung rückwirkend aufblähen.

Vier praktische Einsatzmuster

Paid Data API

Ein lokales Mandat begrenzt Datensätze, Abfragetypen, Volumen, Zweck und Aufbewahrungsbedingungen. Das Gateway filtert freigegebene Felder, misst die Nutzung und signiert eine Quittung für das, was es zurückgegeben hat. Der Kunde verwendet weiterhin den vorhandenen Endpunkt.

Beschaffungsagent

Das kaufende Unternehmen stellt ein Outbound-Gateway vor Lieferanten-APIs. Es prüft den zugelassenen Lieferanten, das Produkt, die Menge, die Menge, die Währung, den Zweck und das Lieferziel. Nach der Genehmigung ruft es den Lieferanten unter Verwendung der vorhandenen Anmeldeinformationen an. Sein Erhalt ist ein Beweis für die käuferseitige Entscheidung und die beobachtete Antwort, nicht die Lieferantenvereinbarung.

Externe Sanierungsstelle

Ein Unternehmen ordnet den vorhandenen Leistungsnachweis eines MSP-Agenten einer lokalen Identität zu. Ein Mandat schränkt Werkzeuge, Produktionsressourcen, Ticketnummern und Wartungsfenster ein. Das Gateway vermittelt einen temporären vorgelagerten Leistungsnachweis und zeichnet die ausgeführte Änderung auf. Der MSP muss nicht dasselbe Vertrauenssystem betreiben.

Versicherungsinformationsaustausch

Ein Versicherer ordnet den bestehenden OAuth-Client eines Brokers einem lokalen Agenten und Anspruchskontext zu. Die Richtlinie begrenzt die Dokumente, Felder, Zweck und Freigabeziel. Eine einseitige Quittung zeichnet auf, was der Versicherer unter seiner Kontrolle freigegeben hat. Sie beweist nicht, wie der Broker die Daten später verwendet hat.

Fehlerfälle, die wichtig sind

Credential Mapping wird zum Schatten-Identitätssystem

Mappings akkumulieren, Eigentümer verlassen und Kundenmieter ändern sich. Behandeln Sie Mappings als geregelte Aufzeichnungen mit Ablauf, Überprüfung, Widerruf und verbindlicher Quellenbindung. Schlüssen Sie niemals aus einem freundlichen Anzeigenamen auf das rechtmäßige Eigentum.

Das Gateway vertraut dem von Anrufern bereitgestellten Kontext

Ein Agent schickt X-Tenant-ID: tenant-7 Während seine Berechtigung gehört tenant-418Den Mandanten und die Organisation aus der verifizierten Identität ableiten und dann mit dem Anforderungskontext vergleichen.

Ein Connector versteckt Richtlinie

Ein Lieferantenadapter akzeptiert stillschweigend einen höheren Betrag, weil die vorgelagerte API Dezimalzahlen verwendet. Beträge vor der Bewertung in explizite Einheiten kanonisieren. Anbieterspezifische Übersetzungen von anbieterneutralen Richtlinien trennen.

Der Erhalt impliziert eine Geschäftspartnervereinbarung

Die Benutzeroberfläche kennzeichnet eine lokale Quittung als "verifizierte Transaktion", ohne anzugeben, wer sie unterschrieben hat. Ausgabestelle, Sicherheitsstufe und Status der Gegensignatur anzeigen. Eine einseitige Quittung ist genau dann nützlich, wenn ihre Grenzen klar sind.

Remote Call Zeiten aus

Fehler nicht aufzeichnen und blind wiederholen, das Ausführungsergebnis unbekannt markieren, durch die Fernbedienungsreferenz oder den Idempotenzschlüssel abgleichen und dann den aufgelösten Zustand anhängen.

Durchsetzung von Verkehrsumgehungen

Wenn ein Agent die API weiterhin direkt erreichen kann, ist die Richtlinie optional: Verwenden Sie Netzwerkrouten, Service Mesh-Richtlinien, Ausstiegskontrollen oder API-Konfigurationen, um das Gateway zum einzigen akzeptierten Pfad für den geschützten Betrieb zu machen.

Checkliste der Durchführung

• Wählen sie die ein- oder ausgehende durchsetzung, je nachdem, wer jetzt die kontrolle braucht.
• Authentifizierung mit dem vorhandenen Nachweis, bevor der lokale Kontext abgebildet wird.
• Bindung von Mappings an Emittent, Subjekt, Publikum, Mieter, Status und Lebenszyklus.
• Kennzeichnen Sie Credential-mapped Identity getrennt von portable Identity.
• Express lokale Befugnis mit kurzen Ablauf und maschinenüberprüfbare Einschränkungen.
• Normalisieren Sie API- und MCP-Aufrufe in einen kanonischen Transaktionsumschlag.
• Halten Sie die Konnektorübersetzung von der Geschäftspolitik getrennt.
• Bewerten Sie Identität, Mandat, Transaktion und Geschäftspolitik zusammen.
• Erzwingen Sie Replay-Schutz und Idempotenz, bevor Sie schreiben.
• Halten Sie Richtlinie und erforderlichen Vertrauenszustand in der Nähe der Datenebene verfügbar.
• Machen Sie Bypass technisch schwierig durch Netzwerk- und Servicekontrollen.
• Unterzeichnen Sie Quittungen bei Emittent und Assurance Level sichtbar.
• Behandeln Sie einseitige Beweise als einseitig.
• Passport, Mandatsaustausch und Gegenzeichnung nur hinzufügen, wenn die Gegenparteien bereit sind.

Verwandte technische Anleitungen

• Beginnen Sie mit dem Enterprise AI Agents Architektur und Deployment Guide für das breite Lebenszyklus-, Risiko- und Startmodell.
• Verwendung Begrenzte Delegation in Multiagentensystemen innerhalb des teilnehmenden Unternehmens.
• Erfahren Sie, was einseitige Beweise unterstützen können AI Agent Observability: Quittungen versus Protokolle.

Ein inkrementeller OATI-Pfad

OATI Eine erste Ein-Teilnehmer-Zusicherungsstufe kann mit einem vorhandenen Nachweis beginnen, der einem lokalen Agentendatensatz zugeordnet ist. Reisepass ist in dieser Phase optional. Das teilnehmende Unternehmen wendet dann lokale Befugnisse und Richtlinien an und gibt einen einseitigen Aktionsbeleg heraus. Die Vorlage eines Passports, eines von der Gegenpartei ausgestellten Mandats oder einer Gegensignatur erhöht das Sicherheitsniveau, wenn diese Objekte verfügbar sind. Das öffentliche Entwickler-Framework implementiert Kerndatensätze, Signatur, Verifizierung, deterministische Bewertung, Lookup und Referenz-Middleware. Es existiert ein bereitgestellter Trust- und Lookup-Slice, aber das Projekt bleibt eine Entwicklervorschau, bis eine unabhängige Überprüfung und weitere Produktionsabnahmearbeiten vorliegen.

Die vollständige kommerzielle Gateway-Flotte, Business-Genehmigungs-Workflows, dauerhafte bilaterale Beweise und Föderation sind Zielstaat-Fähigkeiten. Entwickler müssen nicht warten, bis dieser Endzustand das Muster verwendet. Beginnen Sie damit, die Durchsetzung eines Unternehmens zu verbessern, sagen Sie genau, was die resultierenden Beweise beweisen, und lassen Sie die Remote-API in Ruhe.