AI Agent IAM-Referenzarchitektur: Identität und Zugriff

Trennen Sie die sieben Kontrollgrenzen¶

Eine erfolgreiche Netzwerkverbindung beweist die Erreichbarkeit. Durch die Authentifizierung wird eine Identität überprüft. Durch die Autorisierung wird festgelegt, worauf diese Identität zugreifen darf. Die Laufzeitrichtlinie wertet diese Aktion und diesen Kontext aus. Die Genehmigung gibt einer berechtigten Person eine begrenzte Entscheidung. Die Ausführung erzeugt den Nebeneffekt. Der Beweis erfasst die gesamte Einheit zur Überprüfung.

Halten Sie jede Grenze in der Architektur und im Ereignismodell explizit. Einem gültigen Berechtigungsnachweis kann es immer noch an Berechtigung für den angeforderten Zweck, die Menge, die Daten, die Umgebung oder die angeforderte Zeit mangeln. Für eine erfolgreiche Politikbewertung kann dennoch ein unabhängiger Gutachter erforderlich sein. Eine Genehmigung kann nur die genaue Anfrage und den Kontext freigeben, die sie abdeckt.

Systemkontext- und Identitätsklassen¶

Behandeln Sie die Agentenidentität als dauerhaftes Geschäftsobjekt und die Workload-Identität als laufende Softwareinstanz. Eine Dienstidentität stellt eine nichtmenschliche Abhängigkeit oder ein Gateway dar. Der Tool- oder Ressourcenserver authentifiziert den Aufrufer und erzwingt seine eigene Autorisierung. Ein Prüfer verwendet eine menschliche Identität mit aktueller Entscheidungsbefugnis.

Textalternative. Ein menschlicher Benutzer delegiert einen begrenzten Zweck an einen Agenten und eine Arbeitslast. Identitäts- und Tokendienste authentifizieren die Parteien. Autorisierung und Richtlinie bewerten die Anfrage. Ein Prüfer entscheidet über gehaltene Aktionen. Das Tool führt eine erlaubte Aktion aus. In jeder Phase werden Datensätze an den Beweisspeicher innerhalb der Vertrauensgrenze zwischen Mandant und Organisation gesendet.

Scrollen Sie horizontal, um die Grafik anzusehen.

Wählen Sie eine dedizierte, delegierte oder hybride Identität¶

Eine dedizierte Identität verleiht dem Agenten seine eigene unternehmenseigene Autorität. Eine delegierte Identität überträgt die aktuelle Autorität eines Benutzers in die Aufgabe. Ein Hybrid erfasst beide Parteien: Der Agent bleibt der Akteur und der Mensch bleibt das Subjekt oder der Sponsor. Diese Trennung unterstützt genaue Richtlinien, Widerrufe und Prüfungen.

Shared-Service-Konten schwächen die Zuordnung und bieten häufig weitreichenden Zugriff. Halten Sie sie hinter einem dienstvermittelten Gateway, wenn ein Zielsystem keine engen Agent-Anmeldeinformationen ausgeben kann. Erfassen Sie für jeden vermittelten Anruf den ursprünglichen Agenten, das menschliche Subjekt, die Richtlinienentscheidung und den nachgelagerten Empfang.

Anforderungs- und delegierte Autoritätssequenz¶

Binden Sie das menschliche Subjekt, den Agentenakteur, die Arbeitslast, die Delegation, den Zweck, das Ziel und den Ablauf vor der Token-Ausgabe. Verwenden Sie zielgruppengebundene, kurzlebige Anmeldeinformationen für die Zielressource. Lösen Sie die aktuelle Autorität an der Aktionsgrenze erneut auf, da sich Rollen, Zuweisungen, Risikofakten und Richtlinien während einer Sitzung ändern können.

Textalternative. Der Benutzer weist dem Agenten einen Zweck zu. Der Agent startet eine attestierte Arbeitslast. Der Workload fordert ein Token an. Der Token-Dienst validiert den Akteur und das delegierte Subjekt und stellt dann einen kurzlebigen, publikumsgebundenen Berechtigungsnachweis aus. Der Workload sendet den vollständigen Kontext an die Richtlinie. Das Tool empfängt nur eine zulässige oder gültig genehmigte Anfrage und sendet eine Ausführungsbestätigung zurück.

Scrollen Sie horizontal, um die Grafik anzusehen.

Besitzen Sie alle Anspruchsdimensionen¶

Die geringste Berechtigung wird testbar, wenn jede Dimension einen Besitzer, einen Entscheidungspunkt, einen Überprüfungspfad, einen Widerrufspfad und ein Beweisfeld hat. Bewerten Sie das vollständige Tupel für jede Folgeanforderung. Eine Rolle kann eine Basis liefern, während Zweck, Wert, Daten, Umgebung und Zeit den effektiven Zuschuss einschränken.

Kombinieren Sie Berechtigungsmuster bewusst¶

Die rollenbasierte Zugriffskontrolle sorgt für eine stabile Job- oder Service-Grundlinie. Die attributbasierte Zugriffskontrolle wertet Themen-, Ressourcen-, Aktions- und Umgebungsfakten aus. Die beziehungsbasierte Zugriffskontrolle löst Diagrammbeziehungen wie Zuweisung, Besitz oder Fallmitgliedschaft auf. Der fähigkeitsbasierte Zugriff beinhaltet ein eng begrenztes, übertragbares Autoritätsobjekt, das zielgebunden, zeitgebunden und widerrufbar bleiben sollte.

Verwenden Sie die kleinste Kombination, die die tatsächliche Entscheidung ausdrückt. Zeichnen Sie die gelösten Eingaben und den endgültigen effektiven Zuschuss auf, damit Prüfer das Ergebnis nach Änderungen an Gruppen, Attributen, Beziehungen oder Fähigkeitsstatus reproduzieren können.

Ablauf der Berechtigungs- und Genehmigungsentscheidung¶

Bewerten Sie Identität, Mandant, Delegation, Zielgruppe und Ablauf, bevor Sie Berechtigungen auflösen. Eine ungültige oder fehlende Berechtigung stoppt die Anfrage. Die Laufzeitrichtlinie wählt dann allow, warn, require_approval oder block aus. Eine erforderliche Genehmigung enthält den genauen Antrag und gibt ihn erst frei, nachdem ein berechtigter unabhängiger Prüfer vor Ablauf eine Entscheidung getroffen hat.

Textalternative. Der Fluss überprüft die Identität und den Tokenkontext und dann alle neun Berechtigungsdimensionen. Ungültige Kontextblöcke. Die Richtlinie wählt eines von vier Ergebnissen aus. Block stoppt. Mit „Genehmigung erforderlich“ wird die gebundene Anfrage an einen unabhängigen Prüfer gesendet. Ablehnung oder Ablauf stoppt. „Zulassen“, „warn“ oder „gültige Genehmigung“ wird einmal ausgeführt und erfasst den Empfang und den Nachweis.

Scrollen Sie horizontal, um die Grafik anzusehen.

Stellen Sie kurzlebige Anmeldeinformationen aus und kontrollieren Sie Identitätsdiebstahl¶

Geben Sie Anmeldeinformationen nach der Workload-Authentifizierung und der aktuellen Berechtigungsauflösung aus. Verknüpfen Sie jeden Berechtigungsnachweis mit einer Zielgruppe, einer Vertrauensdomäne, einer Umgebung, einer Subjekt- oder Akteursbeziehung, einem Zweck, einem Umfang und einer kurzen Lebensdauer. Halten Sie die Aktualisierungs- und Austauschberechtigungen enger als die ursprüngliche Berechtigung.

OAuth 2.0 Token Exchange definiert separate Subjekt- und Akteur-Tokens für die Delegation. Der act-Anspruch kann den aktuellen Akteur ausdrücken. Ressourcenindikatoren binden eine Token-Anfrage an die Zielressource. Umfangreiche Autorisierungsanfragen können strukturierte Aktions- und Ressourcendetails enthalten. Jedes Protokoll ist weiterhin auf den Autorisierungsserver und den Ressourcenserver angewiesen, um lokale Richtlinien und Widerrufe durchzusetzen.

• Just-in-time: Erteilen Sie den Zugriff, wenn die Aufgabe beginnt, nach Genehmigung oder Zuweisung, und verfallen Sie ihn mit der Aufgabe.
• Rotation: Automatisieren Sie den Austausch von Schlüsseln und Anmeldeinformationen, behalten Sie Generations- und Überlappungsnachweise bei und testen Sie die alten Anmeldeinformationen nach der Umstellung.
• Grenze des Identitätswechsels: Identitätswechsel für explizite Fälle reservieren, in denen der Akteur am Ziel nicht mehr zu unterscheiden ist; Bewahren Sie den ursprünglichen Schauspieler in einem separaten geschützten Datensatz auf.
• Delegierungsgrenze: Halten Sie sowohl Subjekt als auch Akteur sichtbar und reduzieren Sie die delegierte Autorität für die Aufgabe.
• Token-Verarbeitung: rohe Geheimnisse aus Protokollen ausschließen; Behalten Sie den Aussteller, die Token-ID oder den Digest, die Zielgruppe, die Bereiche, die Gültigkeitsdauer, den Ablauf und das Widerrufsergebnis bei.

Wiederverwendbare Richtlinie der geringsten Rechte¶

Bei der folgenden Richtlinie handelt es sich um ein herstellerneutrales Designbeispiel für ein Lesegerät für Bonitätsprüfungsdokumente. Es deckt alle neun Berechtigungsdimensionen ab und verknüpft fehlenden oder abgelaufenen Kontext mit einem block. Laden Sie die JSON-Datei herunter für Workshops und Tests. Ersetzen Sie alle synthetischen Identifikatoren und Schwellenwerte durch einen genehmigten lokalen Vertrag.

{
  „schema_version“: „1.0“,
  „policy_id“: „credit-review-document-reader“,
  „status“: „Beispiel“,
  „Betreff“: {
    „agent_id“: „credit-review-agent“,
    „workload_id“: „spiffe://bank.example/prod/credit-review“,
    „delegated_user_required“: wahr
  },
  „Berechtigungen“: {
    „Werkzeuge“: [
      „credit_application.read“,
      „credit_memo.draft“,
      „credit_decision.propose“
    ],
    „Ressourcen“: [
      „Kreditantrag:{case_id}“
    ],
    "Daten": {
      "Felder": [
        „declared_income“,
        „verified_income“,
        „existing_exposure“,
        „requested_amount“
      ],
      „denied_fields“: [
        „special_category_data“,
        „unrelated_household_records“
      ]
    },
    „Aktionen“: [
      „lesen“,
      „Entwurf“,
      „propose_credit_decision“
    ],
    „Zwecke“: [
      „credit_application_review“
    ],
    "Betrag": {
      „Währung“: „EUR“,
      „approval_threshold“: 25000,
      „authorization_ceiling“: 100000
    },
    „Umgebungen“: [
      „Produktion“
    ],
    „Zeit“: {
      „maximum_token_lifetime_seconds“: 900,
      „access_window“: „case_assignment“
    }
  },
  „Entscheidung“: {
    „allow_when“: [
      „case_id entspricht dem zugewiesenen Fall“,
      „delegierter Benutzer bleibt zugewiesen und aktiv“,
      „alle angeforderten Felder sind erlaubt“,
      „Zweck gleich credit_application_review“,
      „Angeforderter Betrag liegt bei oder unter 25.000 EUR“,
      „Token-Zielgruppe entspricht der Zielressource“
    ],
    „require_approval_when“: [
      „Der Makler schlägt eine Kreditentscheidung vor“,
      „Der beantragte Betrag übersteigt 25.000 Euro und liegt bei oder unter 100.000 Euro“
    ],
    „block_when“: [
      „Identität, Delegation, Mieter, Zweck oder Zielgruppe fehlen“,
      „Der Berechtigungsnachweis, die Zuweisung, die Berechtigung oder die Richtlinie ist abgelaufen“,
      „Die Anfrage zielt auf einen nicht zugewiesenen Fall oder ein verbotenes Feld ab“,
      „Der beantragte Betrag übersteigt 100.000 Euro“,
      „Der Bestimmungsort oder Zweck weicht von den zulässigen Werten ab“,
      „Der politische Entscheidungsdienst kann nicht das erforderliche Urteil fällen“
    ]
  },
  „Beweis“: [
    „principal_id“,
    „agent_identity_id“,
    „workload_identity_id“,
    „delegation_id“,
    „tenant_id“,
    „tool_id“,
    „resource_id“,
    „data_boundary_ref“,
    „Aktion“,
    „Zweck“,
    „Betrag“,
    „Umwelt“,
    „requested_at“,
    „expires_at“,
    „policy_id“,
    „policy_version“,
    „authentication_event_id“,
    „authorization_decision_id“,
    „policy_decision_id“,
    „approval_decision_id“,
    „reason_codes“,
    „Genehmigungs-ID“,
    „Rezensenten_ID“,
    „execution_receipt“
  ]
}

Führen Sie die Berechtigungsüberprüfung als Kontrolle durch¶

Eine Überprüfung beginnt mit einer abgeglichenen Identitäts- und Zugriffspopulation und testet dann die tatsächliche Autorität und die beobachtete Nutzung. Laden Sie die IAM-Architektur-Arbeitsmappe herunter für die vollständige Checkliste, Entscheidungstabellen und den Überprüfungsdatensatz.

• Vergleichen Sie die Bevölkerung. Vergleichen Sie registrierte Agenten und Dienstkonten mit Token-Ausstellern, Cloud-Principals, Secret Stores, Gateways, MCP-Erkennung, CI/CD-Identitäten, Paketausgaben und beobachteten Tool-Aufrufen.
• Wirksamen Zugriff auflösen. Einschließlich direkter Berechtigungen, Rollen, Attribute, Beziehungen, Fähigkeiten, Gruppen, Delegationen, temporärer Zugriff, Richtlinienregeln und nachgelagerter Berechtigungen.
• Kontrollausnahmen finden. Erfassen Sie verwaiste, geteilte, ruhende, doppelte, abgelaufene, unbeobachtete, mandantenübergreifende, selbstgenehmigende und zu weit gefasste Berechtigungen.
• Testdurchsetzung. Anforderungen für Ausübung zulässig, Genehmigung, blockiert, abgelaufen, fehlender Kontext, widerrufen und veraltete Beziehungen.
• Ergebnisse abgleichen. Verknüpfen Sie jede Probe mit dem Richtlinienergebnis, der Entscheidung des Prüfers, dem Werkzeugbeleg, dem Geschäftsstatus und dem Beweisdatensatz.
• Zertifizieren Sie das bereichsbezogene Ergebnis. Erfassen Sie Kriterien, Population, Zeitraum, Prüfer, Ausnahmen, Entscheidung, Ablauf, nächste Überprüfung und Nachweisreferenzen.

Entdecken und prüfen Sie Dienstkonten¶

Bauen Sie die nichtmenschliche Identitätspopulation aus mehreren unabhängigen Quellen auf. Allein in Identitätsverzeichnissen fehlen Anmeldeinformationen, die in Cloud-Projekten, CI/CD-Systemen, Geheimspeichern, lokalen MCP-Clients, Planern, Browserautomatisierung und nachgelagerten Anwendungen erstellt wurden. Gateway- und Netzwerkbeobachtungen offenbaren Identitäten, die den erwarteten Katalog umgehen.

Erfassen Sie für jedes Dienstkonto den besitzenden Prozess, die verantwortliche Person, Agenten und Workloads, die es verwenden können, den Speicherort der Anmeldeinformationen, zulässige Ziele, effektive Gewährungen, letzte Verwendung, Ablauf, Rotation, Widerrufsmethode und Beweisquelle. Quarantäne oder Sperrung von Konten ohne aktuellen Eigentümer oder genehmigte Nutzung nach der definierten Sicherheitsüberprüfung.

Widerrufen, stoppen, zurücksetzen und wiederherstellen¶

Durch den Widerruf erlischt die Befugnis zur künftigen Nutzung. Der Notstopp umfasst aktive und in der Warteschlange befindliche Arbeit. Rollback stellt eine bekanntermaßen funktionierende Version oder Konfiguration wieder her. Die Wiederherstellung nach Vorfällen gleicht nachgelagerte Auswirkungen ab, stellt neue Anmeldeinformationen aus, testet den sicheren Zustand und verwendet eine separate Neustartentscheidung.

Textalternative. Der Vorfalleigentümer zeichnet den betroffenen Bereich auf und aktiviert einen Verweigerungsstatus. Workflow-Steuerelemente brechen aktive und in der Warteschlange befindliche Arbeit ab. Identitätskontrollen deaktivieren den Agenten und die Arbeitslast, widerrufen Token und rotieren Anmeldeinformationen. Gateways lehnen neue Anfragen ab. Werkzeugbesitzer bringen akzeptierte und begangene Auswirkungen in Einklang. Die Beweisaufnahme erfasst Bestätigungen und Restzugriffe. Bei der Wiederherstellung werden ein bekanntermaßen funktionierendes Release, neue Anmeldeinformationen, eine enge Zulassungsliste und eine Neustartgenehmigung verwendet.

Scrollen Sie horizontal, um die Grafik anzusehen.

Setzen Sie Mieter- und Organisationsgrenzen durch¶

Behandeln Sie Mandant, Organisation, Vertrauensdomäne, Umgebung und Region als Autorisierungsfakten bei maßgeblichen Ausstellern. Validieren Sie sie an jeder externen Grenze und verwenden Sie sie in Datenspeicherabfragen, Token-Zielgruppen, Richtlinienkontext, Genehmigungssuche, Tool-Routing und Beweisauswahl.

Bewahren Sie Produktions- und Nichtproduktionsidentitäten in separaten Vertrauensdomänen oder gleichwertigen Namespaces auf. Qualifizieren Sie fremde Attribute und Rollen durch ihre ausstellende Behörde. Der Verbund legt fest, welche Anmeldeinformationen domänenübergreifend authentifiziert werden können. Die lokale Autorisierung entscheidet weiterhin, welche Aktion und Ressource jede ausländische Identität verwenden darf.

• Lehnen Sie einen Mandanten- oder Organisationsselektor ab, der mit dem authentifizierten Token in Konflikt steht.
• Binden Sie Ressourcenkennungen, Beziehungskanten, Fähigkeiten und Genehmigungen an einen Mandanten.
• Verwenden Sie zielspezifische Token-Zielgruppen und vermeiden Sie Inhaber-Tokens, die von mehreren unabhängigen Ressourcen akzeptiert werden.
• Testen Sie mandantenübergreifende Lese- und Schreibvorgänge, Genehmigungen, Delegierungen, Cache-Schlüssel, Warteschlangen und Beweisexporte.
• Erfassen Sie den maßgeblichen Mandanten und die Vertrauensdomäne in jedem Identitäts-, Richtlinien-, Ausführungs- und Beweisereignis.

Weisen Sie Verantwortung über den gesamten Lebenszyklus hinweg zu¶

Benennen Sie eine verantwortliche Rolle für jede Identität, Berechtigung, Entscheidung, Wirkung und Beweisgrenze. Beratergruppen können den Entwurf überprüfen. Die Betriebsbefugnis bleibt einer Person oder Rolle mit einem definierten Delegierten, einem Gültigkeitszeitraum und einem Eskalationspfad zugewiesen.

Wählen Sie ein Bereitstellungsmuster aus¶

Wählen Sie das Muster aus Autoritätsinhaber, Zielsystemfähigkeit, Aktionskonsequenz, Identitätsvolumen und erforderlicher Attribution aus. Eine einzelne Organisation kann mehrere Muster prozessübergreifend verwenden und gleichzeitig ein Beweismodell beibehalten.

Ausgearbeitetes Beispiel: regulierte Bonitätsprüfung¶

Eine Bank beauftragt einen Kreditprüfer mit dem Fall CR-1842. Der Agent verfügt über eine dedizierte Identität und wird unter einer attestierten Produktions-Workload ausgeführt. Ein benannter Underwriter ist der delegierte Beauftragte für diesen Fall. Der Token-Dienst stellt einen 15-minütigen Berechtigungsnachweis aus, dessen Zielgruppe der Dokumentendienst ist.

Die Autorisierung erlaubt vier genehmigte Felder, drei Aktionen und Beträge bis zu 100.000 EUR für den Zweck credit_application_review, solange der Auftrag aktiv bleibt. Die Richtlinie ermöglicht das Lesen dieser Felder und das Verfassen eines Memos. Bei einer vorgeschlagenen Kreditentscheidung oder einem Antrag über 25.000 EUR wird ein Entscheidungsantrag erstellt. Ein neuer Zweck, ein verbotenes Feld, ein Betrag über der Autorisierungsobergrenze oder fehlende Identität, Delegation, Mandant, Zielgruppe oder aktuelle Richtlinienblöcke. Die Genehmigung erfolgt innerhalb der Genehmigungsobergrenze.

Der anfragende Versicherer kann über den zurückgehaltenen Antrag nicht entscheiden. Ein qualifizierter Zweitgutachter sieht die genaue Maßnahme, Quellennachweise, Richtliniengründe, Autoritätsanforderungen, Ablauf und erwartete Wirkung. Die Genehmigung gibt dieselbe gebundene Anforderung einmal frei. Der nachgelagerte Empfangs- und Fallstatus wird mit den Identitäts-, Delegations-, Berechtigungs-, Richtlinien-, Prüfer- und Ausführungsdatensätzen verknüpft.

Wie sich die Architektur auf aktuelle KLA-Verträge abbildet¶

Die KLA-Kontrollebene regelt instrumentierte Agentenaktionen. Die aktuelle Implementierung stellt eine Laufzeitrichtlinie, eine Genehmigungs-, Ausführungs-, Abstammungs- und Beweisebene bereit. Unternehmensidentitätsanbieter, Ressourcenserver und Anmeldeinformationssysteme behalten die Autorität für ihre Identitäten und Gewährungen.

Die folgende Zuordnung spiegelt den Code wider, der in der Repository-Quelle beim Commit a4e8087f vorhanden ist. Bereitstellungs- und Produktionsverhalten bleiben ungeprüft. Quelllinks sind an diesen Commit angeheftet. Der Status unterscheidet einen aktuellen Vertrag von einer Teilabbildung oder einer konzeptionellen Abstraktion.

Aktuelle KLA-Lücken und konzeptionelle Abstraktionen¶

Die KLA bewertet und zeichnet die Autorität an der Grenze des geregelten Handelns auf. Es liegt außerhalb der IAM-Verantwortlichkeiten einiger Unternehmen in dieser Referenz. Behandeln Sie die folgenden Felder und Abläufe als Integrationsanforderungen, bis für die angegebene Lücke ein aktueller implementierter Vertrag vorliegt.

• Delegiertes Subjekt. Bei der Ausführungserstellung wird onBehalfOfSubject derzeit auf das initiierende Subjekt gesetzt und der aufrufende Client aufgezeichnet. Dem vollständigen öffentlichen Ausführungsvertrag fehlt derzeit eine gesondert attestierte Endnutzersubjekt- und Delegationskette.
• Identitätslebenszyklus. Unternehmensidentitätsanbieter, Workload-Bescheinigungsstellen, HR-Verzeichnisse und universelle Service-Kontoerkennungssysteme bleiben externe Abhängigkeiten.
• Lebenszyklus von Anmeldeinformationen. Konnektoren und Zielsysteme verfügen über ein Downstream-Tool für die Ausstellung, Rotation, Sperrung, Vermittlung und Auslösung von Vorfällen.
• Berechtigungsnormalisierung. Aktuelle Verträge unterstützen Prinzipal, Ressource, Aktion, Attribute, Toolargumente, Umgebung und flexiblen Kontext. Jeder Pfad kann über flexible Felder Zweck, Menge, Daten und Beziehungsfakten darstellen; Der Vertrag überlässt ihre Normalisierung dem Produzenten.
• Autorisierungsmodelle. RBAC-, ABAC-, Beziehungs- und Fähigkeitsmuster in dieser Referenz sind Architekturoptionen. Der aktuelle KLA-Vertrag ist modellunabhängig.
• Zertifizierung. Das aktuelle Produkt dokumentiert Kontrollen und Nachweise. Die universelle Zertifizierung einer Agentenidentität oder einer Berechtigungsgruppe bleibt außerhalb des aktuellen Vertrags.
• Widerrufs-Fanout. Laufzeitabbruch ist implementiert. End-to-End-Identitätsdeaktivierung, Token-Widerruf, Netzwerkisolation, Downstream-Stornierung und Entschädigung bleiben koordinierte externe Aktionen.
• Portabler Datensatz. Das AI Agent Audit Log Schema normalisiert mehrere KLA-Produzenten in einem herstellerneutralen Ereignis. Aktuelle Produzenten geben ihre maßgeblichen lokalen Aufzeichnungen ab, die die Referenz in den öffentlichen Umschlag abbildet.

Primärquellen und Frische¶

Diese Architektur wurde am 28. Juli 2026 überprüft. Identitätsstandards, Protokollspezifikationen, Leitlinienentwürfe und Implementierungsprofile können sich ändern. Überprüfen Sie die Live-Quelle und die lokale Bereitstellung erneut, bevor Sie einen Status in einer Prüfung, Beschaffung oder Sicherheitsentscheidung verwenden.

• NIST NCCoE-Software- und KI-Agentenidentitäts- und Autorisierungskonzeptpapier (Entwurf, veröffentlicht am 5. Februar 2026)
• NIST SP 800-162, Leitfaden zur attributbasierten Zugriffskontrolle
• NIST Role Based Access Control-Projekt und aktuelle Standardreferenz
• NIST SP 800-207, Zero Trust-Architektur
• RFC 8693, OAuth 2.0 Token Exchange
• RFC 8707, Ressourcenindikatoren für OAuth 2.0
• RFC 9396, OAuth 2.0 Rich-Autorisierungsanfragen
• SPIFFE-Standard 1.15.2 und Workload-Identitätsspezifikationen
• Model Context Protocol-Autorisierungsspezifikation, 25. November 2025
• Best Practices für die Sicherheit des Model Context Protocol