KI-Agenten-Berechtigungen: Allow-List statt Prompt.

Berechtigungen legen fest, welche Werkzeuge ein Agent nutzen und welche Daten er erreichen darf. Der verbreitete Ansatz verwechselt zwei Dinge: Man gibt dem Agenten breiten Zugriff und schreibt einen Prompt, der ihn einschränken soll. Doch der Prompt ist eine Anweisung an das Modell, und genau das Modell wollen wir ja begrenzen. Das steht auf dem Kopf.

Wir entwickeln Pinchy und haben dazu eine klare Meinung, sind hier also nicht neutral. Eine breitere Einordnung gibt der Leitfaden zu souveränen KI-Agenten.

Ein Prompt ist eine Bitte, keine Grenze

Zwei Fehlerquellen machen das konkret. Erstens Prompt Injection: Ein bösartiges Dokument, eine E-Mail oder eine Webseite kann Anweisungen einschleusen. Liest der Agent sie, bringen sie ihn dazu, Ihre eigenen Anweisungen zu ignorieren. Zweitens Drift: Auch ohne Angreifer befolgt ein Modell eine Anweisung nicht jedes Mal. Ein „Niemals“ im Prompt ist eine Wahrscheinlichkeit, keine Garantie. Steht zwischen Ihrem Agenten und Ihrer Produktionsdatenbank nur ein Satz im Prompt, haben Sie kein Berechtigungsmodell, sondern einen Vorschlag.

Die Grenze gehört in den Code, außerhalb des Modells

Die Lösung verschiebt die Grenze aus dem Prompt in das System rund um das Modell. Ist ein Werkzeug nicht freigegeben, kann der Agent es nicht aufrufen. Daran ändert nichts, was der Prompt sagt, was ein Dokument ihm einredet oder was die Nutzerin verlangt. Der Agent bekommt also nie volle, ungefilterte Fähigkeiten: keine Shell, kein Dateisystem, keinen offenen HTTP-Client. Er bekommt einzeln freigegebene, eng begrenzte Werkzeuge, jedes in einem Plugin mit eigener Konfiguration und Autorisierung. Nicht „Code ausführen“, sondern „Odoo-Aufträge lesen“. Das Plugin zieht die Grenze, und das Modell arbeitet darin.

Allow-List, nicht Deny-List

Sobald Berechtigungen im Code liegen, bleibt die Wahl des Standards. Aus ihr kommt der größte Teil der Sicherheit. Entscheidend ist eine Frage: Was passiert, wenn Sie etwas vergessen?

• Deny-List. Alles ist erlaubt, Sie entfernen Einzelnes. Vergessen Sie eine Sperre, bleibt die Fähigkeit offen. Ein Versehen kostet Sie eine offene Tür.
• Allow-List. Nichts ist erlaubt, Sie geben Einzelnes frei. Vergessen Sie eine Freigabe, kann der Agent diese Fähigkeit schlicht nicht nutzen. Ein Versehen kostet Sie ein Support-Ticket.

Für alles, was echte Systeme berührt, taugt nur der Allow-List-Fehlermodus. Ein neuer Agent startet deshalb mit null Werkzeugen und kann nichts, bis eine Administratorin jede Fähigkeit einzeln freischaltet. Eine „Alles erlauben“-Abkürzung gibt es bewusst nicht, denn genau über sie leckt am Ende jede Deny-List.

Granularität ist der Punkt

„Darf Odoo nutzen“ ist keine Berechtigung, sondern eine Kategorie. Was ein Unternehmen wirklich braucht, ist feiner: „Darf Aufträge lesen, aber nicht schreiben, für diesen einen Agenten“. Je enger die Freigabe, desto kleiner der Schaden, wenn ein Agent sich falsch verhält. Und das tut er, denn er arbeitet mit Wahrscheinlichkeiten. Also gilt: minimale Rechte je Agent (Least Privilege). Ein Support-Agent, der Antworten entwirft, braucht keinen Schreibzugriff auf das ERP.

Zwei Achsen, die oft verwechselt werden

Ein vollständiges Modell braucht zwei unabhängige Kontrollen. Wer darf den Agenten nutzen (Identität, Rollen, gruppenbasierte Sichtbarkeit), und was darf der Agent tun (die Werkzeug-Allow-List von oben). Diese Achsen bleiben getrennt: Ein Finanz-Agent ist vielleicht nur für die Finanzgruppe sichtbar (das Wer) und darf zugleich nur Buchhaltungsdaten lesen (das Was). Wer beide richtig setzt, sorgt dafür, dass die Praktikantin im Gespräch mit dem Buchhaltungs-Agenten nicht die Rechte der Administratorin erbt.

Die ehrliche Grenze

Berechtigungen begrenzen, was ein Agent erreichen kann. Sie machen die Entscheidungen des Modells innerhalb dieser Grenze nicht richtig. Ein Agent mit der Freigabe „Antwort entwerfen“ kann eine schlechte Antwort entwerfen. Berechtigungen sind also notwendig, aber nicht hinreichend, und gehören mit einem Audit-Trail zusammen: Die eine Schicht hält den Agenten in Schranken, die andere weist nach, was in diesen Schranken geschah.

So setzt Pinchy das um

Dieser Abschnitt beschreibt unser eigenes Produkt. In Pinchy startet ein neuer Agent mit null Werkzeugen, und Admins schalten jedes Werkzeug einzeln und je Agent frei. Zusammen mit Rollen und Gruppen steuert das beides: was ein Agent tun und wer ihn beauftragen darf. Die volle Sicht zeigt die Agent-Permissions-Seite.