Die Befugnisse eines Agenten begrenzen

Beschreiben Sie die Aufgabe vor der Zugriffsvergabe

Ein Agent, der Code liest, braucht andere Befugnisse als ein Agent, der einen Dienst bereitstellt. Gewähren Sie nicht beide Berechtigungsgruppen, nur weil dasselbe Produkt beide Aktionen unterstützt.

Definieren Sie Befugnisse mit drei Teilen: Aktion, Ressource und Bedingung. Bei einer fiktiven Berichtskorrektur darf der Agent während der aktiven Aufgabe in einen Feature-Branch schreiben. Er darf freigegebene Repository-Dateien lesen. Er darf weder Produktionsdaten noch Repository-Schutzregeln ändern.

Die genaue Durchsetzung hängt vom Werkzeug ab. Kann ein Token keine Branch-Beschränkung ausdrücken, nutzen Sie zusätzliche Repository-Kontrollen oder einen Ausführungsdienst. Dokumentieren Sie die verbleibenden Befugnisse ehrlich.

Setzen Sie die Grenze außerhalb des Modells durch

Ein Prompt ist kein Zugriffskontrollsystem. Die Ausführungskomponente muss angeforderte Aktion und Ziel gegen die aktuellen Berechtigungen prüfen. Sie darf nicht die Aussage des Modells akzeptieren, eine Genehmigung liege bereits vor.

AWS empfiehlt begrenzte Berechtigungen und temporäre Zugangsdaten für geeignete Workloads. OWASP wendet ähnliche Least-Privilege-Grundsätze auf Agenten und ihre Werkzeuge an. Diese Prinzipien müssen in den tatsächlichen Identitäts- und Ausführungssystemen umgesetzt werden. AWS-IAM-Leitfaden, OWASP-Agentenleitfaden.

Nutzen Sie kurzlebige Zugangsdaten, wo dies unterstützt wird. Halten Sie für die Aufgabe nicht benötigte Secrets aus der Umgebung fern. Eine reine Leseaufgabe im Repository sollte kein Produktionsdatenbankpasswort aus der Shell des Entwicklers erben.

Binden Sie Genehmigung an die tatsächliche Aktion

Die Genehmigung, eine Änderung vorzubereiten, erlaubt nicht automatisch ihr Deployment. Eine Deployment-Entscheidung sollte Artefakt, Zielumgebung und relevante Bedingungen benennen. Ändern sie sich, gilt die vorherige Entscheidung möglicherweise nicht mehr.

Betrachten Sie einen Agenten, der einen sicheren Datenbanklesezugriff vorschlägt und nach der Genehmigung eine andere Abfrage ausführt. Ein nützlicher Genehmigungsmechanismus prüft den tatsächlich ausgeführten Vorgang. Eine allgemeine Nachricht „Fortfahren“ ohne definiertes Ziel kann diesen Unterschied verbergen.

Trennen Sie auch Identität und Fähigkeit. Erfassen Sie, welche Person oder welcher Workload den Lauf gestartet hat. Prüfen Sie bei der Aktion, ob die auslösende Identität weiterhin berechtigt ist. Der Entzug eines Personenzugriffs sollte eine ausdrückliche Wirkung auf wartende Arbeit haben.

Testen Sie Ablehnung und Unterbrechung

Prüfen Sie mehr als den Erfolgsfall. Versuchen Sie in einer isolierten Testumgebung eine Aktion außerhalb der erlaubten Ressource. Bestätigen Sie, dass das Ausführungssystem sie zurückweist. Untersuchen Sie das Audit-Ereignis, ohne Zugangsdaten aufzuzeichnen.

Testen Sie anschließend Abbruch oder Ablauf von Zugangsdaten. Bestimmen Sie, welche Arbeit sofort stoppt und welcher Vorgang noch abgeschlossen werden kann. Eine Stoppschaltfläche macht eine Aktion, die bereits ein anderes System erreicht hat, nicht unbedingt rückgängig.

Halten Sie bei der Aufgabe eine kurze Berechtigungsdokumentation. Nennen Sie Verantwortliche, genehmigten Umfang, tatsächliche Kontrollen, Ablehnungstest und Ablaufzeit. So wird ein späteres Review konkret genug, um den Ablauf zu verbessern.