Der Enterprise Agent Control Stack: Sechs Schichten, die zusammenarbeiten müssen

Rezensiert 17. August 2026 · 15 Minuten gelesen

Ein Enterprise Agent Control Stack benötigt sechs verschiedene Fähigkeiten: Identität, Entscheidungskontext, Konnektivität, Transaktionsautorität, kontrollierte Ausführung und Ergebnisnachweis. Kein einzelner Identitätsanbieter, Wissensgraph, Gateway, Policy Engine oder Zahlungsprotokoll deckt alle sechs ab. Die praktische Architektur setzt diese Systeme zusammen und macht eine Kontrollgrenze für die genaue Aktion verantwortlich, bevor sie ein Folgesystem erreicht.

Dieses Handbuch richtet sich an Unternehmensarchitekten, die entscheiden, wo Produkte wie Microsoft Entra, Okta, OriginTrail, Kong, PlainID, Catena und Intelliger passen. Es bietet einen Referenzkontrollfluss, eine veraltete Marktkarte und einen Fehlertest, der Lücken aufdeckt, die Feature-Listen tendenziell verbergen.

Was gehört in einen Enterprise Agent Control Stack?

Beginnen Sie mit den Fragen, die das System beantworten muss. Die Antworten kommen aus verschiedenen Quellen und ändern sich mit unterschiedlichen Geschwindigkeiten.

Wischen Sie horizontal, um das vollständige Diagramm zu überprüfen.

Die Layer können auf einer oder mehreren Plattformen laufen und bleiben getrennte Verantwortlichkeiten, auch wenn ein Anbieter mehr als einen liefert.

Microsoft dokumentiert die Entra Agent ID als Identitätsgrundlage für die Verwaltung von Agentenidentitäten, Eigentümern, Sponsoren, Lifecycle, Conditional Access und Ressourcenzugriff. Das ist eine umfangreiche Identitätsinfrastruktur. Es beseitigt nicht die Notwendigkeit, einen Kaufbetrag, einen Zielort und eine Genehmigung an eine Transaktion zu binden. Dokumentation der Microsoft Entra Agent ID macht den Identitätsumfang explizit.

Kongs MCP-Material umfasst Proxying, Authentifizierung, Zugriffskontrollen, Verkehrsrichtlinien, Beobachtbarkeit und Konvertierung bestehender APIs in MCP-Tools. Das sind Gateway-Verantwortlichkeiten. Ein Gateway kann auch einen externen Autor aufrufen, benötigt aber ein stabiles Transaktionsobjekt, wenn die Richtlinie von der Geschäftsbedeutung abhängt und nicht nur von Route und Toolname. Kongs MCP Gateway Dokumentation zeigt die Traffic- und Integrationsgrenze.

Der Kontrollfluss sollte eine Transaktionsidentität bewahren

Ein häufiges architektonisches Versagen ist der Bedeutungsverlust zwischen den Schichten. tools/call, sieht die Policy-Engine einen Benutzer und eine Rolle, und der Anbieter erhält eine Rückerstattungsanfrage. Jede Komponente behandelt ihr eigenes Objekt, aber keine gemeinsame Kennung beweist, dass sie die gleiche Aktion bewertet hat.

Verwenden Sie einen kanonischen Transaktionsumschlag vor der Autorisierungsentscheidung:

type ControlledTransaction = {
  transactionId: string;
  tenantId: string;
  agentId: string;
  accountableOwner: string;
  action: string;
  resource: string;
  purpose: string;
  counterparty?: string;
  destination?: string;
  amount?: { currency: string; minor: string };
  authorityRef: string;
  contextSnapshotDigest: string;
  requestDigest: string;
  audience: string;
  expiresAt: string;
};

Dies ist ein illustrativer interner Vertrag, kein Standardschema. Die Sicherheitsregel ist wichtiger als die Feldnamen: Jede Transformation muss die Felder beibehalten oder neu berechnen, die die Geschäftsbedeutung ändern. Wenn ein Adapter die Währung, das Ziel oder den Lieferanten nach der Genehmigung ändert, muss der endgültige Vollstrecker sie ablehnen.

Die Referenzsequenz lautet:

agent proposal
  -> authenticate runtime and resolve owner
  -> retrieve minimum permission-aware context
  -> normalize tool or API request
  -> verify mandate and current policy
  -> obtain independent approval when required
  -> reserve replay, budget and idempotency state
  -> broker a short-lived execution credential
  -> execute against the authoritative provider
  -> reconcile accepted, unknown and terminal outcomes
  -> issue a signed record with explicit assurance limits

Deterministische Komponenten müssen Autorität, Geldlimits, Wiederholung, Genehmigungsbindung und Freigabe von Berechtigungen durchsetzen.

Wo der aktuelle Markt passt

Marktpositionierung von Enterprise Agents

Produkt-Scope-Analyse, nicht Marktanteil, Qualität oder Reife

Textzusammenfassung der hervorgehobenen Unternehmen

Unternehmen oder Protokoll	Primärer Anwendungsbereich auf der Karte
Intelliger	Transaktionsspezifische Befugnis, deterministische Durchsetzung, Abgleich und tragbare Beweismittel.
Konkordion	Verifiziertes Eigentum, Agentenregister und identitätsgebundene Transaktionsinfrastruktur.
OriginTrail	Gemeinsame Kontextgraphen, Provenienz und dezentrale Wissensinfrastruktur.
Okta für AI Agents	Agent Identity, Lifecycle, Access und Governance.
Microsoft Entra Agent ID	Identität, Eigentum, Lebenszyklus und Zugriff auf Microsoft-Ökosysteme.
SailPoint	Agent Inventory, Ownership, Access Review und Rights Governance.
Oasis Sicherheit	Nicht-menschliche Identitätsfindung, Berechtigungen und Just-in-Time-Identitätskontrollen.
Aembit	Workload-Identität und geheimnisloser Just-in-Time-Zugriff für Agenten und MCP.
PlainID	Enterprise Policy Management und verteilte Autorisierung Durchsetzung.
Treuhand	Zweckkontrollen, Zuschüsse, Traces und Data Governance.
Kongreß	LLM, MCP und A2A Traffic Gateway, Authentifizierung und Beobachtbarkeit.
Portkey	AI und MCP Gateway, Credential Isolation, Observability und Leitplanken.
Wolkenflöte	Distributed Traffic, Security, Remote MCP und AI Gateway Infrastruktur.
MuleSoft	Enterprise API-Integration, Orchestrierung und Agent-Facing-Konnektivität.
Zenität	Agent Discovery, Runtime Threat Prevention und Sicherheitshaltung.
Astrix	Nicht-menschliche Identität und Agent Credential Risikoüberwachung.
Catena	Agent Finanzpolitik, Genehmigungen, Konten, Zahlungsausführung und Audit.
Circle Agent Stack	Programmierbare Wallets, USDC-Abwicklung und x402-Unterstützung.
Google AP2	Typisierte Checkout- und Zahlungsmandate, Rollenvalidierung und Quittungen.
UCP	Commerce Discovery, Checkout, Payment-Handler und Order-Lifecycle Protokoll.
Experian Agent Trust	Verbraucheridentität, Absicht, Betrug und Zahlungsvertrauenssignale.
BigID	Enterprise Data Discovery, Klassifizierung und Governance.
Immuta	Datenpolitik, Zweckkontrollen und geregelter Zugriff.
AGNTCY	Open Agent Discovery, Identity, Messaging und Observability Infrastruktur.

Die Karte ist nur dann nützlich, wenn ihre Achsen explizit bleiben. Umzug nach rechts bedeutet nicht, dass ein Unternehmen besser ist. Eine breite Identitäts- oder Gateway-Plattform löst absichtlich ein breiteres Infrastrukturproblem. Umzug nach oben bedeutet nicht, dass ausgereifter ist. Es bedeutet, dass der dokumentierte Umfang des Produkts weiter in die Ausführung zur Laufzeit, in die Abwicklung oder in den Ergebnisnachweis hineinreicht.

Verwenden Sie die Karte, um fehlende Handoffs zu identifizieren:

• Identitätsanbieter sollten ein stabiles Subjekt und Eigentümer in die Transaktionspolitik projizieren.
• Kontextsysteme sollten Fakten mit Herkunft, Zugangsrichtlinie und beobachteter Zeit zurückgeben.
• Gateways sollten die Anforderung normalisieren und die Entscheidung vor dem Upstream-Aufruf durchsetzen.
• Policy Engines sollten die genaue Transaktion anstelle von modellgeschriebener Prosa bewerten.
• Zahlungs- und Ausführungsanbieter sollten stabile Referenzen für den Abgleich zurückgeben.
• Evidenzsysteme sollten die unterzeichnete Bestätigung des Emittenten von der unabhängig verifizierten Geschäftswahrheit unterscheiden.

OriginTrail veranschaulicht, warum Kontext eine eigene Schicht verdient. Sein DKG V10-Repository beschreibt ein dreischichtiges Speichermodell, Kontextgraphen, RDF-Abfrageflüsse und Beweismechanismen. Das gleiche Repository beschriftet V10 als Release-Kandidat im testnet und sagt, dass es noch nicht für Produktions-Workloads empfohlen wird. OriginTrails DKG-Repository Unterstützt sowohl die Fähigkeits- als auch die Laufzeiterklärung.

Catena zeigt eine andere Form der Überlappung. Sein aktuelles Produkt positioniert Identität, deterministische Finanzpolitik, Genehmigungen, Konten und Multi-Rail-Zahlungen zusammen. Für ein Unternehmen, das einen integrierten Agenten-Banking- und Governance-Service möchte, kann dies die Integrationsarbeit reduzieren. Es beantwortet nicht jeden Anwendungsfall für nichtfinanzielle Transaktionskontrolle, weshalb die Architektur die erforderlichen Kontrollergebnisse vergleichen sollte, anstatt Merkmale zu zählen. Produktbeschreibung von Catena beschreibt den aktuellen Banking- und Governance-Bereich.

Wie Intelliger passt, ohne den Stack zu ersetzen

Die beabsichtigte Rolle von Intelliger ist die Transaktionskontrollschicht: Sie verbraucht Identität aus Unternehmens- oder Protokollsystemen, Kontext aus maßgeblichen Datenquellen, Policy-Ergebnisse aus einer bestehenden PDP, wenn angemessen, und Ausführung aus den Systemen, die bereits Eigentümer der Geschäftsmaßnahme sind.

Das differenzierte Objekt ist die Transaktionskette:

identity + owner
  -> bounded mandate
  -> canonical request digest
  -> deterministic decision and approval
  -> provider execution reference
  -> reconciled outcome
  -> portable receipt

Dies ist besser geeignet, wenn ein Authority-Modell Zahlungs- und Nichtzahlungsaktionen über mehrere Systeme oder Unternehmen hinweg abdecken muss, wenn die Delegation die Beschränkungen eines Mutterunternehmens nicht verstärken darf oder wenn eine andere Partei einen begrenzten Datensatz ohne Zugriff auf die vollständige Protokollplattform des Emittenten überprüfen muss.

Es ist kein Grund, Entra, Okta, Kong, OriginTrail, PlainID, einen Zahlungsdienstleister oder den Knowledge Graphen des Kunden zu ersetzen.

Testen Sie den Stack mit Fehlern, keine Happy-Path-Demo

Erstellen Sie eine Transaktionsvariante und mutieren Sie jeweils eine Eigenschaft:

{
  "transaction_id": "txn:refund:8421",
  "agent_id": "agent:support:17",
  "action": "refund.create",
  "resource": "order:8421",
  "purpose": "customer_service_resolution",
  "amount": { "currency": "EUR", "minor": "48000" },
  "destination": "original_payment_method"
}

Ein Stack ist unvollständig, wenn jeder das Problem protokolliert, aber keine Komponente die Denial besitzt.

Operatives Eigentum ist ebenso wichtig wie die Produktauswahl

Weisen Sie jedem Eigentümer eine Grenze zu:

• Identitätsteam: Agent Lifecycle, Sponsoren, Token-Emission und Notfall-Deaktivierung.
• Datenteam: Kontextprovenienz, Zugang auf Feldebene, Frische und Löschung.
• Plattformteam: Gateway-Routing, Schema-Normalisierung, Wiederholung und Identifizierungsisolierung.
• Geschäftskontrollinhaber: Mandat, Richtlinien, Genehmigungsschwellen und Ausnahmebehandlung.
• Anwendungs- oder Finanzteam: idempotente Ausführung, Anbieterzustand und Abgleich.
• Assurance-Team: Aufbewahrung von Beweisen, historische Schlüssel, Zugriff auf Streitigkeiten und Verifizierungsrichtlinien.

Ein Katalog-Lookup kann zwischengespeicherten Kontext tolerieren. Eine Zahlung darf nicht stillschweigend veraltete Autorität verwenden, weil die Police-Ebene nicht verfügbar ist. Ein Provider-Timeout darf weder Erfolg noch Misserfolg werden, bis der Zustand festgelegt ist.

Fragen von Unternehmensteams zum Control Stack

Welche Schicht sollten wir zuerst implementieren?

Beginnen Sie mit der Aktion, die den klarsten Verlust verursachen kann, und verfolgen Sie dann ihre Identität, ihren Kontext, ihre Autorität, ihre Ausführung und ihre Evidenzabhängigkeiten. Für eine Zahlungs- oder Produktionsänderung ist Identität allein keine sichere erste Version. Der erste nutzbare Teil sollte eine Out-of-Policy-Transaktion verweigern, eine Umgehung verhindern und eine mehrdeutige Antwort des Anbieters in Einklang bringen.

Brauchen wir für jede Schicht einen separaten Anbieter?

Eine Plattform kann mehrere Ebenen abdecken, und bestehende Identitäts-, Daten- und Gateway-Produkte sollten in der Regel bestehen bleiben. Der wichtige Test besteht darin, ob jedes Steuerelement einen expliziten Eigentümer hat und ob Informationen Produktgrenzen überschreiten, ohne die Identität von Mandanten, Transaktionen oder Richtlinien zu verlieren.

Kann eine Identitätsplattform eine Transaktionsautorisierung bereitstellen?

Es kann eine authentifizierte Identität, einen Lebenszyklusstatus, eine Gruppenmitgliedschaft und manchmal grobe Berechtigungen bereitstellen. Eine Folgetransaktion benötigt immer noch Grenzen, die an Zweck, Ressource, Menge, Ziel, Zeit und die genaue Anforderung gebunden sind. Diese Entscheidung gehört in eine transaktionsbewusste Autoritätsschicht, auch wenn die Identitätsplattform kritische Eingaben liefert.

Wo sollten Beweise leben?

Betriebsprotokolle können in der Beobachtbarkeitsplattform verbleiben. Kompakt signierte Quittungen und deren Verifizierungsmaterial müssen entsprechend den Prüfungs- und Streitbeilegungsanforderungen aufbewahrt werden. Anbieterreferenzen und Abgleichsaktualisierungen müssen von derselben Transaktionsidentität adressierbar sein, anstatt jede sensible Nutzlast in ein Geschäft zu kopieren.

Aktueller Intelliger und OATI Grenze

OATI bietet derzeit ein Entwickler-Vorschau-Framework mit öffentlichen Schemata, kanonischer Signatur, Verifizierung, Vertrauensauflösung, deterministischer Mandatsbewertung, Replay-Steuerungen, Quittungen und einer 73-Fall-Sprachkonformitätssuite. Ein gehosteter Vertrauens- und Lookup-Vertical-Slice wird bereitgestellt und ein Referenz-Envoy-Autorisierungspfad wird implementiert.

Das kommerzielle Enterprise Agent Gateway, der vollständige Richtlinien-Compiler, der dauerhafte Beweis- und Streitdienst, der vollständige Hub, die unabhängige Protokollüberprüfung und die Akzeptanz der Produktion für zwei Unternehmen sind nicht vollständig. Die breitere einheitliche Intelliger-Plattform bleibt eine kommerzielle Zielarchitektur, die auf den gemeinsamen Transaktionskontrolldiensten basiert.

Dieser Status ist wichtig, wenn etablierte Plattformen mit einer Entwicklervorschau verglichen werden.

Architektur-Checkliste

• Weisen Sie ein Aufzeichnungssystem für Agentenidentität und rechenschaftspflichtiges Eigentum zu.
• Suchen Sie den aufgabenspezifischen Kontext mit Herkunft, Zugriffsrichtlinie und beobachteter Zeit ab.
• Normalisieren Sie MCP-, A2A- und API-Anforderungen in einen stabilen Transaktionsumschlag.
• Halten Sie Mandatsgrenzen von der aktuellen Geschäftspolitik getrennt.
• Binden Sie die Genehmigung an den genauen Request Digest.
• Freigabe von Anmeldeinformationen nur nach deterministischer Autorisierung.
• Separate Beweiswiederholung von Business-Idempotenz.
• Repräsentieren Sie akzeptierte, unbekannte, bestätigte, fehlgeschlagene, umgekehrte und umstrittene Ergebnisse.
• Erklären Sie, was jede Signatur bestätigt und was sie nicht beweisen kann.
• Testmutation, Bypass, Ausfall, Parallelität und Abgleichfehler.

Für die Implementierungsmechanik verwenden Sie die AI Agent Authorization Guide, vergleichen Optionen für Enterprise AI Agent Registry, vergleichen PlainID mit Trust3 AI, vergleichen MCP Gateways mit API Gateways und die Überprüfung der AI Agent Audit-Trail-Modell.

Expertenüberprüfung vor der Veröffentlichung erforderlich: Identitäts-, Gateway-, Zahlungs- und Protokollspezialisten sollten die Produktkoordinaten, Quelleninterpretationen und Current-versus-Ziel-Anweisungen validieren.

Um eine begrenzte Transaktion über Ihren bestehenden Stack zu testen, Überprüfen Sie die Agent Trust-Architektur und kontaktieren Sie Intelliger.