AI Agent Access Control Checkliste für die Produktion

10 Minuten lesen · Sicherheitsexperte Überprüfung vor Veröffentlichung erforderlich

Eine Überprüfung der Zugriffskontrolle von KI-Agenten sollte mit Beweisen enden: Testergebnisse, Konfigurationsversionen, Denial-Fixes und benannte Besitzer. Ein Kontrollkästchen mit der Aufschrift "Least privilege enabled" ist zu vage, um eine riskante Veröffentlichung zu blockieren. Autorisierungsmodell für KI-Agenten In überprüfbare Gates.

Verwenden Sie es für Agenten, die Datensätze ändern, Workflows auslösen, Geld ausgeben, sensible Daten offenlegen oder Produktionssysteme betreiben können. Frische, Genehmigung und Aufbewahrungsschwellen an die Wesentlichkeit der Aktion anpassen.

Identität und Access Gates

• Jede Laufzeit hat eine einzigartige, drehbare Workload-Identität.
• Die Kennungen Mensch, Organisation, Agent und Workload bleiben in Logs und Token unterschiedlich.
• Jeder geschützte Dienst validiert den Emittenten, die Unterschrift, die Zielgruppe, den Ablauf und den erforderlichen Umfang.
• Von Anrufern bereitgestellte Identitäts-Header werden nach der Verifizierung entfernt und regeneriert.
• Token werden niemals an einen unbeabsichtigten MCP-Server oder eine Domain-API weitergeleitet.
• Direkte Servicerouten werden durch Netzwerkrichtlinien und Dienstauthentifizierung blockiert.
• Durch das Deaktivieren eines Agenten werden neue Aktionen gestoppt, auch wenn ein älteres Zugriffstoken gültig bleibt.

Verwendung RFC 9700 für aktuelle OAuth-Sicherheitspraktiken und RFC 8707 für Resource Audience Binding.

Authority und Policy Gates

• Grants Name erlaubte Aktionen, Ressourcen, Gegenparteien, Ziele, Limits und Ablauf.
• Fehlende Hochrisikobeschränkungen leugnen, anstatt eine Wildcard zu implizieren.
• Die Delegation kann nur die Elternautorität erhalten oder einschränken.
• Die Modellausgabe wird vor der Richtliniebewertung in ein strenges Schema unterteilt.
• Die Autorisierung bewertet den aktuellen Geschäftszustand, nicht nur Token-Forderungen.
• allow, deny und approval_required haben stabile Grundcodes.
• Die zurückgegebene Entscheidung bindet die kanonische Anforderung Digest und Policy-Version.
• Unbekannte politische Verpflichtungen führen zu Ablehnung.

release_gate:
  action: supplier-payment.create
  required_tests:
    - wrong_audience_denied
    - changed_destination_denied
    - expired_grant_denied
    - widened_child_grant_denied
    - concurrent_last_use_exactly_one
    - direct_route_blocked
  evidence_required:
    - policy_digest
    - test_run_id
    - reviewer_identity

Die Leitfaden für Transaktionsbeschränkungen stellt das zugrunde liegende Subventionsschema dar.

Genehmigungs-, Wiedergabe- und Ausführungsgates

• Die Genehmigung zeigt jedes Materialfeld aus der kanonischen Anfrage an.
• Jede Materialmutation macht die vorherige Genehmigung ungültig.
• Ablauf der Genehmigung, Widerruf und einmalige Verwendung werden unmittelbar vor dem Versand überprüft.
• Replay-Nonces und begrenzte Verwendungen werden atomar beansprucht.
• Business Operations verwenden Idempotenzschlüssel, die von Credential Replay Keys getrennt sind.
• Provider Timeout wird uncertain, keine automatische Wiederholung oder falsches Versagen.
• Abstimmung kann ein spät akzeptiertes, vereinbartes, umgekehrtes oder fehlgeschlagenes Ergebnis entdecken.

Führen Sie zwei Worker gegen die letzte erlaubte Verwendung und den gleichen Idempotenzschlüssel aus. Das erwartete Ergebnis ist eine geschützte Operation, nicht nur eine erfolgreiche HTTP-Antwort. Genaue menschliche Zustimmung umfasst die Mutationstests.

Nachweis und Betriebsgates

• Protokolle verbinden Agenten-, Transaktions-, Trace- und Policy-Identifier, ohne Rohgeheimnisse zu speichern.
• Die Evidenzaufzeichnung trennt Autorisierung, Versand, Anbieterakzeptanz und Endergebnis.
• Signaturverifizierung, Schlüsselrotation und Schemamigration haben Vorrichtungen.
• Revocation und Policy Caches haben maximale Stalness nach Risikoklasse dokumentiert.
• Das Team hat Trust-Service, Replay-Store und Evidenz-Senk-Ausfälle geprobt.
• Ein Besitzer erhält Warnungen für Umgehungsversuche, abgestandene Zuschüsse und fehlende Quittungen.
• Ein Reviewer kann eine Transaktion ohne eine modellgenerierte Erklärung rekonstruieren.

OWASP Agentic Threat Guidance ist eine nützliche Quelle für Missbrauchsfälle. AI Risk Management Framework hilft, Release Gates mit Continuing Governance zu verbinden.

Aufnahme einer Freigabeentscheidung

Veröffentlichen Sie keinen perfekt aussehenden Prozentsatz, notieren Sie fehlgeschlagene Tests, akzeptierte Ausnahmen, Ausgleichskontrollen, Ablauf und den rechenschaftspflichtigen Genehmiger.

Intelliger Agent Trust Materialien und OATI-Entwicklervorschau können die Entwurfsbewertung unterstützen und ersetzen keine unabhängige Bewertung des eingesetzten Identitätsanbieters, Gateways, Domänendienstes, Netzwerkpfade und Betriebsverfahren.

Wie man die Checkliste in einem Release Review verwendet

Weisen Sie jedem Element einen Eigentümer, Beweisreferenz, Ergebnis und Überprüfungsdatum zu. Not applicable Eine Ablehnung des falschen Publikums und eine blockierte direkte Route können Freigabetore sein, selbst wenn Dutzende von Protokollierungs- und Dokumentationsprüfungen bestehen.

Führen Sie die Checkliste mit einer benannten Agentenversion, einem Aktionssatz, einem Mandantenumfang, einer Gateway-Version und einem Policy-Digest aus. Wenn sich eine dieser Änderungen vor dem Start ändert, identifizieren Sie, welche Prüfungen veraltet sind. Die Wiederverwendung einer Checkliste von einem harmlosen Pilot-Lese-Piloten für eine Zahlungsaktion ist kein Beweis.

Gateway-Besitzer können nachweisen, dass eine Anfrage abgelehnt wurde, aber nur das Service-Team nachweisen kann, dass es keine alternativen Anmeldeinformationen oder Routen gibt und dass sich Idempotenz korrekt verhält.

Beispielbeweis nach der Veröffentlichung: Domänensystemaktionen mit Gateway- und Entscheidungsaufzeichnungen vergleichen, überprüfen, ob verweigerte Mutationen keinen Upstream-Aufruf erzeugt haben, und Widerruf mit einer aktiven Sitzung wiederholen, die verstrichene Zeit beim endgültigen Dienst aufzeichnen, nicht die Zeit, zu der ein Administrator geklickt hat.

Ausnahmen am Anfang und nicht am Ende des nächsten Zyklus überprüfen. Abgelaufene Ausnahmen sollten die betroffene Aktion aus dem Dienst nehmen oder eine neue, rechenschaftspflichtige Risikoentscheidung erfordern. Eine Release-Checkliste ist nur dann nützlich, wenn sich durch Ausfälle das Einsatzverhalten ändert.

Bewahren Sie den signierten Release-Record neben den genauen Artefakten auf, die er überprüft hat: Agent-Version, Tool-Schemata, Gateway-Konfiguration, Policy-Digest und Fixture-Ergebnisse. Ein späterer Operator sollte in der Lage sein zu beantworten, ob eine Produktionsaktion unter dieser akzeptierten Konfiguration oder unter etwas, das sich danach geändert hat, ausgeführt wurde. Dies schränkt auch die Wiederverwendung der Checkliste ein. Wenn ein Tool einen Nebeneffekt hinzufügt oder einen Anmeldenachweis eine neue Ressource erreicht, kehren die betroffenen Gates zu pending zurück, auch wenn der Anzeigename und die Modellversion des Agenten gleich bleiben.

Wählen Sie eine Person außerhalb des Implementierungsteams aus, um einen Denial-, Revocation- und Evidenz-Retrieval-Test anhand der schriftlichen Anweisungen zu wiederholen.