AI Agent Permissions: Vom Umfang bis zu Transaktionsbeschränkungen
Entwerfen Sie KI-Agentenberechtigungen, die die genaue Aktion, Ressource, Ziel, Wert, Zeit und Delegationspfad einschränken, anstatt sich auf breite OAuth-Umfänge zu verlassen.
KI-Agentenberechtigungen sollten die Transaktion beschreiben, die ein Agent durchführen kann, nicht nur die API, die er erreichen kann. payments:write Das ist eine sinnvolle Zutrittskontrolle, denn es kann kein Limit von 2.000 Euro, keinen zugelassenen Lieferanten, kein verifiziertes Bankziel, kein Zwei-Stunden-Fenster oder kein Verbot der Weiterverbreitung geben.
Dieser Leitfaden richtet sich an Sicherheitsteams für Identität, Plattform und Anwendung, die die Zugriffskontrolle auf Folgeaktionen von Agenten erweitern. AI Agent Authorization Guide Hier ist der Fokus das Berechtigungsobjekt und die Tests, die es eng halten.
Verwenden Sie eine Berechtigungsleiter
Behandlungserlaubnis als vier verwandte Schichten:
| Schicht | Fragestellung | Beispiel |
|---|---|---|
| Authentifizierung | Wer oder was präsentierte das Credential? | agent:ap-worker-3 |
| Zugang zu Ressourcen | Welchen Service kann er erreichen? | payments:write für api.payments.example |
| Beauftragte Befugnis | Welche Klasse von Arbeiten wurde zugewiesen? | Rechnungen zugelassener Lieferanten begleichen |
| Transaktionsbeschränkungen | Ist diese genaue Anfrage innerhalb der Aufgabe? | Lieferanten, Bestimmungsort, Betrag, Währung und Auslaufübereinstimmung |
Die früheren Schichten bedeuten nicht die späteren. RFC 8707 kann eine OAuth-Anfrage an eine Zielressource binden. RFC 9700 empfiehlt Publikumsbeschränkung und Mindestprivilegien, keines der Standardmodelle einer Unternehmensrechnung, Rückerstattung, Bestellung oder Produktionsänderung.
Einschränkungen als Daten kodieren
Ein Berechtigungsprotokoll sollte typisiert, versioniert, widerrufbar und spezifisch genug für eine deterministische Bewertung sein.
type AgentGrant = {
grantId: string;
subject: string;
audience: string;
actions: string[];
resources: string[];
counterparties?: string[];
destinations?: string[];
limits?: {
currency?: string;
maxAmountMinor?: number;
maxUses?: number;
};
delegation: { allowed: boolean; maxDepth: number };
notBefore: string;
expiresAt: string;
policyVersion: string;
};
Abwesenheit braucht eine Bedeutung. destinations Feld sollte nicht jedes Ziel bedeuten: entweder die Gewährung ablehnen oder eine explizite Platzhalterkarte definieren, die die Richtlinie für diese Aktionsklasse verbietet; ganzzahlige kleinere Einheiten für Geld, stabile Identifikatoren für Gegenparteien und absolute Zeitstempel verwenden.
Zur Laufzeit ist die normalisierte Anforderung mit jeder anwendbaren Einschränkung zu vergleichen.
Testmutationen, nicht nur gültige Anfragen
Ein Happy-Path-Test beweist wenig über die Grenze. Beginnen Sie mit einer erlaubten Befestigung, mutieren Sie ein Feld nach dem anderen und erwarten Sie einen stabilen Denial-Code.
| Mutation | Erwartetes Ergebnis |
|---|---|
Betrag 200000 wird 200001 | AMOUNT_LIMIT_EXCEEDED |
| Zieländerungen | DESTINATION_NOT_ALLOWED |
| Publikumsveränderungen | Ablehnung vor Richtliniebewertung |
| Verfall ist eine Sekunde in der Vergangenheit | GRANT_EXPIRED |
| Kindergeld hat einen späteren Ablauf | DELEGATION_WIDENS_AUTHORITY |
| Zwei Anfragen verbrauchen die letzte Verwendung | Genau eine Reservierung gelingt |
Fügen Sie Tests für Unicode-Normalisierung, doppelte JSON-Schlüssel, unerwartete Felder und Ganzzahlüberlauf hinzu. Laufzeitberechtigungsmuster zeigt, wo diese Kontrollen laufen. Genaue menschliche Zustimmung deckt Anträge ab, die eine andere Entscheidung erfordern.
Wissen, was der Rekord beweist
Ein unterzeichneter Zuschuss kann nachweisen, was der Emittent bescheinigt hat und ob sich der Datensatz geändert hat. Er kann nicht nachweisen, dass der Lieferantendatensatz korrekt ist, dass keine Umgehungsroute existiert oder dass der geschützte Dienst die Entscheidung durchgesetzt hat. AI Agent Audit Trail.
NIST AI Risk Management Framework Die Überprüfung von Genehmigungen sollte daher Eigentümerwechsel, Widerrufsfrische, ungenutzte Zuschüsse, Ablehnungsraten und Vollständigkeit der Nachweise umfassen und nicht nur eine einmalige Entwurfsprüfung.
Zu den öffentlichen OATI-Materialien von Intelliger gehören Schemata, Beispiele und Verifizierungspfade in der Entwicklervorschau. OATI Architektur oder Kontaktieren Sie Intelliger um das Muster mit einem bestimmten Workflow zu bewerten.
Fragen, die bei der Entwurfsprüfung zu klären sind
Sollten Berechtigungen in Token oder in einem separaten Grant leben?
Setzen Sie stabilen Ressourcenzugriff in kurzlebige Token und Transaktionsbeschränkungen in einem separat versionierten Grant, wenn sich diese Einschränkungen unabhängig ändern. Ein Token kann eine Grant-Kennung tragen und verdauen, so dass der Durchsetzungspunkt Substitution erkennt. Einbetten jeder Gegenpartei, Limit und Nutzungszustand in das Token schafft übergroße Anmeldeinformationen und veraltete Autorität. Alles fernzuhalten schafft auch eine Live-Abhängigkeit. Viele Systeme verwenden lokal verifizierbare Grant-Snapshots plus neue Überprüfungen für Widerruf, Nutzung und Geschäftszustand.
Wie eng sollte ein Aktionsname sein?
Wählen Sie eine Aktion aus, die einer Domänenoperation mit einer Richtlinienbedeutung entspricht. write ist meist zu breit. supplier-payment.create und supplier-destination.propose Der geschützte Dienst sollte die Aktion auf einen idempotenten Adapter abbilden und eine Aktion-Ressource-Kombination ablehnen, die er nicht erkennt.
Was passiert, wenn eine Constraint-Quelle nicht verfügbar ist?
Entscheiden Sie sich für jede Aktionsklasse. Wenn das Register für genehmigte Zielorte nicht verfügbar ist, kann eine Zahlungsaufforderung keine erforderliche Tatsache feststellen und sollte normalerweise angehalten oder überprüft werden. Eine risikoarme öffentliche Lektüre kann unter einem begrenzten Snapshot fortgesetzt werden. Geben Sie intern einen abhängigkeitsspezifischen Grund zurück und notieren Sie die Snapshot-Version und das Alter. Fangen Sie keine Nachschlageausnahme und interpretieren Sie eine fehlende Liste als uneingeschränkten Zugriff.
Wie werden kumulative Grenzwerte durchgesetzt?
Ein Vergleich pro Transaktion reicht für ein Tages- oder Monatsbudget nicht aus. Reservieren Sie den vorgeschlagenen Betrag atomar gegen den Zuschuss und den Zeitraum vor dem Versand. Schließen, Freigabe oder Abstimmung dieser Reservierung entsprechend dem externen Ergebnis ab. Definieren Sie, ob unsichere Transaktionen weiterhin das Budget verbrauchen; die sofortige Freigabe kann eine weitere Zahlung ermöglichen, während die erste noch abgewickelt werden kann. Testen Sie gleichzeitige Anfragen zum endgültig verfügbaren Betrag.
Wie sollten Teams bestehende Berechtigungen überprüfen?
Beginnen Sie mit geschützten Domänenaktionen und arbeiten Sie rückwärts zu allen Anmeldeinformationen und Routen, die sie erreichen können. Vergleichen Sie die tatsächliche Nutzung mit gewährter Aktion, Gegenpartei, Ziel, Wert und Zeit. Entfernen Sie veraltete Grants, aber auch Test-Widerrufsausbreitung. Ein sauberer Verwaltungsbildschirm beweist nicht, dass ein alter Token, in der Warteschlange befindlicher Job oder Kinderzuschuss nicht mehr funktioniert. Beispiel Domänensystemoperationen und finden Sie den Entscheidungsprotokoll, das jede einzelne erlaubt.