AI Agent Identity vs Authorization: Welche Identität nicht genehmigt werden kann

Rezensiert 17. August 2026 · 16 Minuten gelesen

Die Identität von KI-Agenten beantwortet, wer oder was handelt, wem sie gehört und welche Anmeldeinformationen sie kontrolliert. Die Autorisierung beantwortet, ob dieser Agent eine bestimmte Aktion ausführen kann, für eine bestimmte Ressource, für einen bestimmten Zweck, gemäß der aktuellen Richtlinie. Unternehmensimplementierungen benötigen beides. Eine verifizierte Identität wird zu einem Input für die Entscheidung; es ist nicht die Entscheidung selbst.

Die TLS-Verbindung ist gültig. Der OAuth-Token hat die erwartete Zielgruppe. Der Agent gehört einem großen Unternehmenskäufer.

Dürfen 50.000 Euro bestellt werden?

Nichts in diesem Identitätsnachweis beantwortet die Frage, es sagt nicht aus, welche Mitarbeiter- oder Geschäftsfunktion delegierte Einkaufsbehörde ist, welche Lieferanten zugelassen sind, ob das Budget 500 oder 50.000 Euro beträgt, ob sich die Lieferadresse ändern kann oder ob eine Genehmigung erforderlich ist.

Durch die Behandlung der Authentifizierung als Autorisierung bleibt Agentic Commerce ohne eine transaktionsspezifische Entscheidung; eine verifizierte Identität ist Gegenstand dieser Entscheidung, nicht die Entscheidung selbst.

Fünf Behauptungen verstecken sich hinter einem "vertrauenswürdigen" KI-Agenten

Wenn ein Team sagt, dass ein Agent vertrauenswürdig ist, fragen Sie, welche Behauptung es bedeutet:

1. Die Laufzeit steuert ein gültiges Credential.
2. Der Agent wird von einer benannten Organisation betrieben.
3. Ein Auftraggeber delegierte eine begrenzte Aktion an diesen Agenten.
4. Die aktuelle Geschäftspolitik erlaubt diese Transaktion.
5. Das ausgeführte Ergebnis kann auf die vorhergehenden Ansprüche zurückgeführt werden.

Diese Forderungen haben unterschiedliche Emittenten, Laufzeiten und Ausfallarten.

OAuth kann Bereiche authentifizieren und übermitteln. Die Workload-Identität kann einen Prozess an einen Schlüssel binden. Eine Agentenkarte oder ein Reisepass kann Fähigkeiten und Besitz benennen. Ein Mandat kann aufgabenspezifische Befugnisse ausdrücken. Eine Policy-Engine kann sich gegen aktuelle Budgets und den Lieferantenstaat entscheiden. Eine unterzeichnete Quittung kann das aufgezeichnete Durchsetzungssystem binden.

Diese in einem einzigen Träger-Token zusammenzufassen, macht das System bis zum ersten Streit einfach.

Wie Entra, Okta, SailPoint und Concordium das Identitätsproblem teilen

Die Produkte machen keine identischen Behauptungen, sondern gehen von unterschiedlichen Vertrauenssystemen und Käuferbedürfnissen aus.

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

Die aktuelle Agent-ID-Dokumentation von Microsoft umfasst unterschiedliche Agent-Identitäten, Blaupausen, Eigentümer- und Sponsor-Beziehungen, Lifecycle-Kontrollen und Conditional Access. Es beschreibt auch Agent-Benutzerkonten für Fälle, in denen ein digitaler Mitarbeiter Ressourcen benötigt, die normalerweise auf Benutzeridentitäten beschränkt sind. Microsoft Entra Agent ID ist besser geeignet, wenn Microsoft-Identität und Microsoft 365-Teilnahme die zentrale Bereitstellungsgrenze sind.

Das Produkt von Okta wurde laut Support-Dokumentation im April 2026 allgemein verfügbar: Aktuelle Materialien beschreiben die Entdeckung von Agenten, die Registrierung, Lebenszyklusereignisse und zentrale Zugangskontrollen. Okta für AI Agents Produktstatus und Okta's AI Agent Discovery Dokumentation Okta ist die bessere Lösung, wenn ein Unternehmen Agent Governance an ein bestehendes Okta Estate bindet.

SailPoint beschreibt die Aggregation von Agenten über Systeme hinweg und die Verwaltung von Eigentum, Berechtigungen und Zugriff mit seinem Identitätssicherheitsmodell. SailPoint's Agent Identity Security Übersicht macht es zu einer natürlichen Passform für Inventar, Zertifizierung und Rights Governance.

Concordium beginnt mit einem tragbaren Registry- und Verifiziert-Eigentümer-Modell. Seine technische Dokumentation beschreibt ein On-Chain-Register, Agentenkarten, deren Bytes durch einen On-Chain-SHA-256-Hash und optionale Verknüpfung mit einem verifizierten menschlichen Eigentümer geschützt sind. Concordium Agent Registry Dokumentation ist relevant, wenn es auf die öffentliche oder kettenübergreifende Identitätsprüfung ankommt.

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.
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.
Experian Agent Trust	Verbraucheridentität, Absicht, Betrug und Zahlungsvertrauenssignale.

Wenn Entra, Okta, SailPoint oder Concordium die Identität bereits angeben, behalten Sie sie bei. Projizieren Sie den verifizierten Subjekt, Eigentümer, Mieter, Anmeldemethode und Status in die Transaktionskontrollentscheidung.

Authentifizierung beweist die Kontrolle über ein Credential

In einem gewöhnlichen API-Fluss überprüft der Händler ein Token, ein Zertifikat oder eine Anforderungssignatur, die belegen kann, dass der Anrufer über einen Berechtigungsnachweis verfügt, der mit einem Client oder einer Workload verbunden ist, vorbehaltlich der Emittenten- und Verifizierungsrichtlinie.

Sie kann den gegenwärtigen Geschäftszweck des Anrufers nicht nachweisen.

• zu weit gefasst;
• kopiert von einer anderen Laufzeit;
• gültig, nachdem ein Mitarbeiter eine Aufgabe zurückgezogen hat;
• mit der richtigen Firma, aber der falschen Abteilung verbunden sind;
• für einen Betrag oder Lieferanten verwendet, den der Hauptverpflichtete nie genehmigt hat.

Absenderbeschränkte Anmeldeinformationen wie DPoP und mTLS reduzieren die Wiedergabe von Token. Sie erfinden immer noch nicht die fehlende Geschäftsdelegation. Der OAuth DPoP-Standard beschreibt Mechanismen zum Nachweis des Besitzes für Zugriffs- und Aktualisierungstoken, einschließlich der Bindung von Token an einen öffentlichen Schlüssel. RFC 9449 löst ein Credential-Diebstahlproblem, nicht das Problem der vollen Handelsbehörde.

Die Autorisierungsschicht braucht ein stabiles Subjekt, eine verantwortliche Organisation, einen vertrauenswürdigen Emittenten, einen aktuellen Schlüssel und einen Widerrufsstatus.

Scopes sind zu grob für einen Kauf

Ein Token mit orders:write Die Handelsbehörde ist in der Regel von Transaktionsfeldern abhängig:

action       order.create
supplier     approved-supplier-17
product      industrial-sensor/SKU-882
quantity     12
unit price   EUR 640.00
total        EUR 7,680.00
destination  plant-7/receiving
purpose      maintenance-work-order-491
expiry       2026-08-11T12:00:00Z

Das Hinzufügen von Tausenden von OAuth-Bereichen für Lieferanten, Budgets, Destinationen und Zwecke schafft ein unüberschaubares Autorisierungsvokabular. Setzen Sie stabile API-Berechtigungen in Anwendungsbereichen. Setzen Sie transaktionsspezifische Delegationen in ein typisiertes Mandat und aktuelle Geschäftsbedingungen in Richtlinien.

Googles AP2-Arbeit erkennt die gleiche Lücke für Zahlungen an. Seine offizielle Ankündigung rahmt die Autorisierung als Beweis dafür, dass ein Benutzer einem Agenten eine spezifische Autorität für einen bestimmten Kauf gegeben hat, und führt einen Rahmen für Absicht und Rechenschaftspflicht ein. Die AP2-Ankündigung Behandelt agent authority als protokollobjekt und nicht als prompte konvention.

Der Unternehmenshandel braucht ein Muster, das über die Bezahlung hinausgeht, und auch Verhandlungen, Datenweitergaben, Rückerstattungen, Auftragsänderungen und die Delegation an Kinderagenten brauchen Autorität.

Vertretung der delegierten Befugnis als typisierte Daten

Ein Mandat sollte kurzlebig, explizit und an den Beweisschlüssel des Agenten gebunden sein.

{
  "id": "mandate:procurement:wo-491",
  "issuer": "org:manufacturer:maintenance",
  "subject": "agent:procurement:12",
  "proof_key": "key:agent:procurement:12#runtime-4",
  "purpose": "maintenance-work-order-491",
  "actions": ["catalog.search", "offer.request", "order.create"],
  "resources": ["category:industrial-sensors"],
  "counterparties": ["supplier:17", "supplier:23"],
  "destinations": ["plant:7/receiving"],
  "constraints": {
    "currency": "EUR",
    "max_unit_price": "700.00",
    "max_total": "8000.00",
    "max_uses": 1,
    "delegation_depth": 1
  },
  "not_before": "2026-08-11T09:00:00Z",
  "expires_at": "2026-08-11T12:00:00Z"
}

Dezimalarithmetik für Geld. Definieren Sie, ob Steuern und Versand auf jedes Limit angerechnet werden. Geben Sie Ressourcen und Zielorte stabile Identifikatoren. counterparties Feld darf nicht bedeuten, dass jeder Lieferant erlaubt ist.

Wenn ein Agent an ein Kind delegiert, muss jeder Kinderzwang gleich oder schmaler als der Elternteil sein. Die Haushaltskapazität muss zugewiesen werden, nicht kopiert.

Bindende Autorität für die genaue Transaktion

Das Gateway sollte den eingehenden Protokollaufruf in einen kanonischen Transaktionsumschlag normalisieren und alle sicherheitsrelevanten Felder signieren oder verdauen.

type CommerceTransaction = {
  id: string;
  agentId: string;
  organisationId: string;
  mandateId: string;
  action: string;
  resource: string;
  counterparty: string;
  destination: string;
  purpose: string;
  amount: { value: string; currency: string };
  requestDigest: string;
  audience: string;
  issuedAt: string;
  nonce: string;
};

Die requestDigest sollte die gewählte Variante, Menge, Preisbedingungen, Lieferadresse, Zahlungs- oder Checkout-Referenzen und jedes Feld abdecken, das die Geschäftsbedeutung ändert.

Dann überprüfen Sie in einer absichtlichen Reihenfolge:

schema
-> issuer chain and key
-> signature
-> status and revocation
-> activation, expiry and audience
-> request digest binding
-> replay claim
-> mandate subject and proof key
-> action, resource, purpose and counterparty
-> amount, usage and delegation
-> current business policy
-> approval when required

Bestellen ist nicht kosmetisches. Reservieren Sie kein Budget für eine fehlerhafte Anfrage. Nicht ausführen, bevor der Replay-Anspruch dauerhaft ist. Lassen Sie nicht zu, dass eine zwischengespeicherte Genehmigung ein abgelaufenes Mandat wiederbelebt.

Richtlinie deterministisch halten

Das Modell kann "Ersetzen der ausgefallenen Sensoren in Anlage 7" interpretieren und Kandidatenprodukte vorschlagen. Es kann erklären, warum Lieferant 17 gut passt. Es sollte nicht entscheiden, ob die Summe in der Zuständigkeit liegt.

function evaluateOrder(
  tx: CommerceTransaction,
  m: Mandate,
  state: State,
): Decision {
  if (m.status !== 'active') return deny('mandate_inactive');
  if (!m.actions.includes(tx.action)) return deny('action_not_allowed');
  if (!m.counterparties.includes(tx.counterparty))
    return deny('supplier_not_allowed');
  if (!m.destinations.includes(tx.destination))
    return deny('destination_not_allowed');
  if (tx.purpose !== m.purpose) return deny('purpose_mismatch');
  if (tx.amount.currency !== m.constraints.currency)
    return deny('currency_mismatch');
  if (decimal(tx.amount.value).gt(decimal(m.constraints.max_total))) {
    return deny('total_above_mandate');
  }
  if (!state.approvedSuppliers.has(tx.counterparty))
    return deny('supplier_suspended');
  if (state.remainingBudget.lt(decimal(tx.amount.value))) {
    return deny('business_budget_exceeded');
  }
  return allow();
}

Das Mandat beantwortet, was delegiert wurde. Policy beantwortet, ob die Transaktion jetzt akzeptabel ist. Ein Lieferant könnte nach der Mandatserteilung suspendiert werden. Ein Budget könnte durch eine andere Transaktion verbraucht worden sein. Ein Zielort kann in einen eingeschränkten Staat gelangen.

Strukturierte Entscheidungen wie z.B. allow, deny, transform oder approval_requiredWenn eine Transformation den Betrag, das Produkt, den Lieferanten oder den Bestimmungsort ändert, erstellen Sie eine neue Transaktionsverdauung und bewerten Sie die Genehmigung neu.

Broker-Ausführungsdaten nach der Entscheidung

Nach der Autorisierung kann ein Gateway eine kurzlebige Fähigkeit erhalten, sie in den Connector einspeisen und die kanonische Anforderung ausführen.

agent proposal
  -> runtime identity verification
  -> mandate verification
  -> deterministic policy
  -> human approval when required
  -> temporary credential broker
  -> supplier or payment API
  -> outcome reconciliation
  -> signed receipt

Dies schränkt die sofortige Injektion ein. Böswilliger Katalogtext könnte das Modell davon überzeugen, ein anderes Ziel zu versuchen. Es kann das unterzeichnete Mandat nicht ändern, die Richtlinien erweitern oder einen Ausweis preisgeben, den das Modell niemals erhält.

Widerruf ist Teil der Autorisierung

Unternehmen müssen die autorität beenden, wenn ein agent kompromittiert wird, ein mitarbeiter eine aufgabe abbricht, ein lieferant blockiert wird oder ein runtime-schlüssel durchsickert.

Beheben Sie den Widerruf nach Ziel: Aussteller, Agentenidentität, Laufzeitschlüssel und Mandat. Cache-Neuheit nach Risiko definieren. Eine wesentliche Zahlung sollte nicht geschlossen werden, wenn der erforderliche Vertrauens- oder Wiedergabezustand nicht überprüft werden kann. Ein Katalog mit geringem Risiko kann einen separat konfigurierten verschlechterten Modus haben.

Halten Sie den Widerruf so lokal, dass der Transaktionspfad nicht jedes Mal von einem zentralen SaaS-Aufruf abhängt. Signierte Richtlinienpakete und kurzlebige Vertrauens-Caches können die lokale Durchsetzung unterstützen, aber die Ausfallregeln müssen explizit und getestet sein.

Evidenz ohne Übertreibung

Nach der Ausführung kann eine Quittung den Agenten, die Organisation, das Mandat, den kanonischen Anforderungsverdau, die politische Entscheidung, die Genehmigung, die Anbieterreferenz und das beobachtete Ergebnis binden.

{
  "transaction_id": "tx:order:491-12",
  "agent_id": "agent:procurement:12",
  "mandate_id": "mandate:procurement:wo-491",
  "decision": "allow",
  "outcome": "accepted",
  "request_digest": "sha256:...",
  "policy_digest": "sha256:...",
  "provider_reference": "supplier-order:SO-18827",
  "occurred_at": "2026-08-11T09:44:12Z",
  "issuer": "org:manufacturer:gateway"
}

Eine gültige Signatur unterstützt die Überprüfung, dass der Inhaber des Signaturschlüssels den Erhalt bescheinigt hat. Die Vertrauensauflösung verbindet diesen Schlüssel mit einem Emittenten im Rahmen einer Police. Weder stellt fest, dass der Lieferant den Auftrag erfüllt hat noch dass jede vorgelagerte Tatsache wahr war. Abgleich von Annahme, Versand, Lieferung, Rückgabe und Streit als separate Ergebnisereignisse.

Wenn nur der Käufer die Vertrauensschicht betreibt, ist der Nachweis einseitig zu kennzeichnen. Eine Lieferantengegenzeichnung kann die Sicherheit für die Felder erhöhen, die der Lieferant unterschreibt.

Angriffe vor dem Start testen

Mandatsersetzung. Fügen Sie ein gültiges Mandat für eine andere Anlage oder einen anderen Arbeitsauftrag bei.

Menge Mutation. Autorisieren Sie EUR 768, senden Sie dann EUR 7.680 vorgelagert.

Bestimmungsaustausch. Behalten Sie das Produkt und den Betrag, aber ändern Sie die Lieferung an eine Mitarbeiteradresse.

Anwendungsbereichwäsche. Tauschen Sie einen breiten OAuth-Token aus und behandeln Sie den neuen Token als Transaktionsautorität.

Klonen von Haushaltsmitteln. Delegieren Sie das gesamte verbleibende Budget gleichzeitig an mehrere Kinderagenten.

Stale Aufhebung. Akzeptieren Sie weiterhin ein zwischengespeichertes Mandat nach einer Notfallstornierung.

Publikum Verwirrung. Wiedergabe einer signierten Testanforderung gegen die Produktion.

Semantische Wiederholung. Wiederholen Sie die gleiche Reihenfolge mit einer neuen Transaktions-ID nach einem Timeout.

Wiederverwendung der Genehmigung. Fügen Sie dem Lieferanten 17 eine Genehmigung zu einer ansonsten ähnlichen Bestellung des Lieferanten 23 bei.

Umgehung. Lassen Sie den Agenten die Lieferanten-API direkt mit einem Standing Credential anrufen und vermeiden Sie das Policy Gateway.

Checkliste der Durchführung

• Authentifizieren Sie Laufzeit-Anmeldeinformationen und leiten Sie den Mieter aus verifizierten Ansprüchen ab.
• Verbinden Sie jeden Agenten mit einer rechenschaftspflichtigen Organisation und einem Emittenten.
• Führen Sie Ausweise getrennt von der delegierten Befugnis.
• Verwenden Sie typisierte, kurzlebige Mandate für Folgemaßnahmen.
• Bindende Autorität zu Zweck, Ressourcen, Gegenparteien und Zielen.
• Definieren Sie Geld, Nutzung, Ablauf und Delegation Semantik genau.
• Canonicalize und verdauen Sie die genaue Transaktionsanfrage.
• Überprüfen Sie Publikum, Zeit, Widerruf und Wiedergabezustand.
• Bewerten Sie harte Einschränkungen in deterministischen Code oder Richtlinie.
• Reservebudgets und einmalige Nutzung atomar.
• Binden Sie die menschliche Zustimmung zum Transaktionsverdau.
• Broker temporäre Anmeldeinformationen nur nach Genehmigung.
• Machen Sie es schwierig, das Gateway mit Netzwerk- und API-Steuerelementen zu umgehen.
• Unterzeichnen Sie Quittungen und vereinbaren Sie spätere Ergebnisse separat.
• Testen Sie Substitution, Wiederholung, Widerruf, Parallelität und teilweises Versagen.

Fragen zur Identität und Autorisierung von KI-Agenten

Ist die Agentenidentität die gleiche wie die Agentenautorisierung?

Eine gültige Identität kann immer noch eine ungültige oder exzessive Transaktion darstellen.

Kann OAuth Scopes einen Unternehmenskauf genehmigen?

Scopes können den Zugriff auf eine API oder eine Operationsfamilie einschränken. Sie drücken selten Lieferanten, Betrag, Kostenstelle, Lieferziel, Genehmigungsverdau, kumulatives Budget und Delegationstiefe zusammen aus. Verwenden Sie Scopes als äußere Zugangsgrenze und eine transaktionsbewusste politische Entscheidung für den Kauf selbst.

Ersetzen Entra, Okta oder SailPoint Intelliger?

Die komplementäre Rolle von Intelliger besteht darin, verifizierte Identität und Geschäftsautorität in eine deterministische Entscheidung zu übersetzen, die an eine normalisierte Transaktion gebunden ist, und dann die resultierenden Beweise zu bewahren.

Gewährt ein Concordium-Identitätsnachweis eine Unternehmenserlaubnis?

Eine öffentliche Identitäts- oder Rechenschaftspflicht kann stärken, wer ein Akteur ist und welche Registererklärung erstellt wurde. Das Unternehmen muss immer noch entscheiden, ob dieser Akteur ein gültiges Mandat für die angeforderte Geschäftsmaßnahme hat und ob die derzeitige Richtlinie dies zulässt.

Aktuelle Grenze von OATI

OATI trennt Agent Passport, Mandate, Transaction Envelope, Decision and Receipt. Die Public Developer Preview implementiert Schemata, RFC 8785 kanonische Nutzlasten, Ed25519- und ES256-Profile, Emittenten- und Schlüsselüberprüfung, Widerrufsauflösung, Zeit- und Publikumsprüfungen, Replay-Schutz, deterministische Mandatsbewertung und nicht verstärkende Delegation. TypeScript, Python und Go führen die gleichen 73 Konformitätsfälle aus.

Das implementierte Framework ist keine abgeschlossene kommerzielle Durchsetzungsflotte. Der Compiler für Produktionsrichtlinien und der dauerhafte Evidenz- und Streithelfer bleiben unvollständig, das Kunden-Gateway ist eine Referenzintegration, und die unabhängige Protokoll- und Implementierungsprüfung ist noch offen. Intelligers breiteres Handelsregister, Händlerlaufzeit und universelle Konnektoren sind Zielstaatsplattformfähigkeiten.

Die Architektur ist nützlich, unabhängig von der Wahl des Protokolls. Authentifizieren Sie den Agenten, dann fragen Sie, was er tun darf, unter wessen Autorität, innerhalb welcher Grenzen, gegen welche genaue Transaktion und mit welchem Widerrufszustand.

Die gleiche Trennung gilt, wenn ein Agent Geld erreicht. Enterprise AI Agent Identity Platform Shortlist, vergleichen Microsoft Entra Agent ID mit Okta für AI Agents und die Überprüfung der Concordium Agent Registry Unternehmensarchitektur Bevor Sie eine Identitätsquelle auswählen, verwenden Sie dann die breitere AI Agent Authorization Guide, deterministische Architektur für agentische Zahlungen und die AI-Audit-Trail aus signierten Aktionsquittungen.

Expertenüberprüfung vor der Veröffentlichung erforderlich: Ein Überprüfungsprüfer für Unternehmensidentität und -autorisierung sollte den Produktvergleich, die Token- und Lifecycle-Ansprüche, die Mandatssemantik und die aktuelle Implementierungsgrenze validieren.

Um einen bestehenden Identitätsanbieter in einen begrenzten Aktionsfluss abzubilden, Überprüfen Sie die Agent Trust-Architektur und kontaktieren Sie Intelliger.