Geringste Privilegien für KI-Agenten in einem mandantenfähigen SaaS

Ein gängiger Prototyp‑Shortcut besteht darin, einem Agenten ein Token zu geben, alle Werkzeuge freizugeben und das Verhalten über einen Prompt zu beschränken. Das erleichtert eine Demo. In der Produktion entsteht dadurch ein Problem: Der in Prompts formulierte Intent wird zur Hauptbarriere zwischen einem Modell‑Fehler und der vollen Leistungsfähigkeit des Kontos.

Minimalprivileg für einen Agenten endet nicht mit einer read‑only‑Rolle. Mindestens sollten wir fünf Dinge einschränken: Werkzeuge, Operationstyp, Ziel‑Ressourcen, Daten und die Lebensdauer/Identität des Zugriffs.

1. Das Werkzeug‑Set begrenzen

Ein Agent, der Werbeleistungsdaten analysiert, benötigt keine Benutzer‑Management‑Funktionen. Ein Agent, der einen Compliance‑Report erstellt, braucht keinen uneingeschränkten Shell‑Zugriff. Ein Agent, der Dateien in einem Verzeichnis organisiert, braucht nicht das gesamte Dateisystem.

Je breiter der Werkzeugkatalog, desto größer die Angriffsfläche für:

• die Auswahl des falschen Werkzeugs;
• Prompt‑Injection, die zu einer unerwünschten Aktion führt;
• unerwartete Kombinationen von Werkzeugen;
• versehentliche Datenexposition;
• Konfigurationsfehler auf Modellebene.

Die erste Frage sollte daher nicht „Was kann diese API tun?“ sein, sondern:

Welche drei bis fünf Operationen benötigt dieser Agent für diesen konkreten Job?

Alles andere kann unsichtbar bleiben.

2. Lesen, Schreiben, operative Wirkung und Zerstörung trennen

„Hat Zugriff auf Kampagnen“ ist zu allgemein.

Für unsere Werkzeuge ist ein Operations‑Modell hilfreicher:

Umfang	Bedeutung	Beispiel
read	Zustand und Berichte abrufen	Ausgaben, Status oder Ressourcen‑Liste erhalten
write	Konfiguration vorbereiten oder ändern	Entwurf erstellen, umbenennen, Parameter ändern
operate	Geschäftliche Konsequenz aktivieren	Kampagne aktivieren, veröffentlichen, Synchronisation starten
destructive	Löschen, trennen oder widerrufen	Ressource löschen, Zugriff entfernen, schwer rückgängig zu machende Änderung durchführen

Ein Agent kann eine Konfiguration vorbereiten, ohne die Erlaubnis zu haben, sie zu aktivieren. Er kann Rechnungsdaten lesen, ohne Zahlungseinstellungen zu ändern. Er kann eine Nachricht entwerfen, ohne die Erlaubnis zu besitzen, sie zu senden.

Genau diese Grenze ist oft dort, wo nützliche Autonomie liegt.

3. Werkzeug‑Umfang reicht nicht – Ressource ebenfalls einschränken

Eine Berechtigung wie:

campaign.write

ist immer noch zu breit, wenn ein Operator zehn Konten hat, der Agent jedoch nur mit einem arbeiten soll.

Wo praktikabel, sollte die Autorisierung berücksichtigen:

Die Autorisierungsentscheidung umfasst Benutzer, Agent, Funktion, Operationstyp, Mandant/Konto/Projekt, Ressource und Aufgabenkontext.

wer
+ welcher Agent
+ welche Funktion
+ welcher Operationstyp
+ welcher Mandant/Konto/Projekt
+ welche Ressource
+ welcher Aufgabenkontext

Unser internes Brillnet Ads MCP verlangt explizite Konto‑/Kunden‑Kennungen innerhalb einer erlaubten Grenze. Eine allgemeine Abfrage sollte nicht einfach raten, welches Konto zu bedienen ist.

Das ist besonders wichtig in Multi‑Tenant‑SaaS. Das falsche Mandant‑Auswahl kann gravierender sein als ein Denkfehler im Modell selbst.

4. Eingabe‑ und Ausgabedaten begrenzen

Minimalprivileg gilt auch für Daten.

Ein Agent kann benötigen:

• aggregierte Ausgaben, nicht die komplette Nutzerliste;
• Aufgabestatus, nicht jede Anlage;
• Bestätigung, dass ein Credential existiert, nicht dessen Wert;
• eine Personen‑ID, nicht das gesamte Profil;
• ausgewählte Dokumenten‑Felder, nicht das gesamte Repository.

Wenn ein Werkzeug ein minimales Objekt zurückgeben kann, sollte es das minimale Objekt zurückgeben. Exponiere nicht das komplette Provider‑Payload dem Modell, nur weil die API es bereitstellt.

Dasselbe Prinzip gilt für das Logging: Ein Audit‑Trail sollte genug Evidenz enthalten, nicht eine Kopie aller Quelldaten.

Lesen: KI‑Agent‑Audit‑Trails

5. Ein Credential sollte nicht länger oder breiter leben als nötig

Ein langlebiges Administrator‑Token, das in jeder Komponenten‑Umgebung liegt, ist leicht einzurichten. Es ist jedoch schwer sicher einzuschränken.

Wir bevorzugen ein Muster, das näher an folgendem liegt:

1. Der Agent erhält das Geheimnis nicht.
2. Das Gateway prüft Identität, Umfang und Ressource.
3. Es erhält ein kurzlebiges Credential.
4. Es führt einen erlaubten Provider‑Aufruf aus.
5. Das Geheimnis gelangt nie in die Modell‑Antwort oder das Audit‑Record.

Laut Dokumentation holt unser internes Ads MCP kurzlebige Provider‑Tokens zum Aufrufzeitpunkt. Credential‑Material wird außerhalb des Modell‑Kontexts behandelt und nicht in Anwendungs‑Logs geschrieben.

Berechtigung zur Ausführungszeit prüfen

Ein Agent kann eine Aufgabe gestartet haben, während der Operator eine bestimmte Rolle hatte. Zehn Minuten später kann diese Rolle widerrufen worden sein. Ein langer Workflow sollte nicht davon ausgehen, dass die Berechtigung vom Beginn der Session noch gilt.

Für materielle Operationen wird die Autorisierung beim Ausführen des Werkzeugs geprüft.

Dasselbe gilt für Genehmigungen. Zustimmung zu einer Aktion ist nicht die Erlaubnis zu beliebigen nachfolgenden Aktionen.

Ein Prompt ist kein ACL

Eine Anweisung wie:

Sie dürfen nur Daten lesen und dürfen niemals etwas löschen

kann eine nützliche Verhaltensregel sein. Sie ersetzt nicht eine Kontrolle, die technisch DELETE blockiert.

Wenn das Modell Zugriff auf ein destruktives Werkzeug und ein Credential hat, das Löschungen erlaubt, existiert diese Fähigkeit. Der Prompt bittet das Modell lediglich, sie nicht zu nutzen.

Eine praktische Trennung ist:

• Prompt: was der Agent tun soll;
• Autorisierung/Policy: was der Agent darf;
• Provider/API‑Rolle: was die technische Identität beim Provider darf.

Die sicherste Anordnung ist, wenn alle drei Schichten ausgerichtet sind, aber keine einzelne die alleinige Kontrolle darstellt.

Profile statt eines Super‑Agents

In unserem internen Werbetool trennen wir Lese‑/Planungs‑Fähigkeiten, Kampagnen‑Management‑Fähigkeiten und eine Eigentümer‑Ebene für seltene administrative Operationen.

Die Namen sind nicht entscheidend. Wichtig ist, dass gewöhnliche Analysen nicht dauerhaft mit höchstem Privileg laufen.

Ein ähnliches Design könnte anderswo so aussehen:

Profil	Erlaubte Arbeit	Zusätzliche Grenze
research‑agent	suchen, lesen, zusammenfassen	keine Zustandsänderungen
operations‑agent	lesen, Entwurf erstellen, genehmigte Felder aktualisieren	operativer Umfang
admin‑workflow	administrative Operation	separater Aufruf, Identität/Umfang, zwingende Genehmigung, kurzer Zeitrahmen

Ein Kompromiss oder Fehler in einem Agenten gewährt dann nicht automatisch Zugriff auf jede Klasse von Operationen.

Dateisystem und „universelle“ Werkzeuge einschränken

Zwei Kategorien verdienen besondere Aufmerksamkeit.

Shell / Befehlsausführung

Eine uneingeschränkte Shell kann die meisten sorgfältig entworfenen Werkzeug‑Modelle umgehen. Wenn ein Agent beliebige Befehle als breit privilegierter OS‑Benutzer ausführen kann, bieten feinkörnige Scopes an anderer Stelle nur begrenzten Schutz.

Zweckgebaute Werkzeuge oder erlaubte Befehle innerhalb einer eingeschränkten Umgebung sind in der Regel leichter zu begründen.

Dateisystem

Ein Agent, der einen Report nach /workspace/reports schreiben muss, benötigt nicht /etc, das Home‑Verzeichnis eines Operators oder CI‑Secrets.

In unserem internen Ads MCP sind Dateizugriffe auf genehmigte serverseitige Pfade oder begrenzte Payloads beschränkt. Beliebige Systempfade werden abgelehnt.

Ein Low‑Level‑Gateway benötigt ebenfalls Scopes

Manchmal ist ein allgemeines Gateway nützlich, um neue Provider‑Endpunkte zu testen, bevor ein dediziertes Werkzeug existiert. Es darf nicht zum Fluchthafen werden.

Es sollte klassifizieren:

• HTTP‑Methode;
• Endpunkt;
• Ressource;
• Payload‑Charakteristika;
• ob die Operation Zustand schreibt oder zerstört.

Erst danach sollte die Anfrage den erforderlichen Berechtigungen zugeordnet werden.

Wenn raw_request ein Vollzugriffs‑Token ohne Policy‑Prüfung verwenden kann, ist das de facto Administrator‑Zugriff, egal wie sorgfältig die anderen Werkzeuge scoped sind.

Temporäre Erhöhung für hochriskante Aktionen

Statt einem breiten Scope dauerhaft zuzuweisen, kann ein System kontrollierte Erhöhungen nutzen:

1. Agent bereitet die Operation vor;
2. Gateway erkennt, dass höhere Privilegien nötig sind;
3. Eine Person genehmigt die genauen Parameter;
4. System gewährt die Erlaubnis nur für diese Operation oder einen kurzen Zeitraum;
5. Berechtigung verfällt nach Ausführung;
6. Audit‑Trail protokolliert Genehmigung und Ergebnis.

Das ist nicht überall nötig. Für kritische Operationen reduziert es die Zeit, in der ein breiter Zugriff besteht.

Lesen: Wann sollte ein KI‑Agent menschliche Genehmigung benötigen?

Inventar‑Vorlage für Fähigkeiten

Vor der Produktion sollte die Grenze schriftlich festgehalten werden:

Agent / Workflow	Werkzeug	Operation	Ressource	Daten	Genehmigung	Credential	Audit
Kampagnen‑Reporting	Ads‑Report	read	Konto A	Metriken ohne PII	nein	kurzlebig	ja
Kampagnen‑Vorbereitung	Kampagnen‑Tool	write	Konto A	Konfiguration	nein/bedingt	kurzlebig	ja
Kampagnen‑Aktivierung	Kampagnen‑Operate	operate	Kampagne X	Budget + Status	ja	kurzlebig	ja
Ressourcen‑Löschung	Admin‑Tool	destructive	spezifische Ressource	Minimum	ja	erhöht	ja

Das ist deutlich hilfreicher, als zu schreiben „Der Agent hat Zugriff auf Google Ads“.

Anti‑Pattern

Ein API‑Key für das gesamte System

Rollen können nicht sauber getrennt werden und der Zugriff für einen Workflow ist schwer zu widerrufen.

Das gleiche Werkzeug‑Set für jeden Agenten

Die breiteste Funktion im Katalog wird zum Risikofaktor jedes Agenten.

„Read‑only“ nur im Prompt

Wenn das Backend weiterhin Schreibzugriff akzeptiert, ist read‑only nur eine Bitte, keine Kontrolle.

Automatisches Ausweiten des Scopes nach einem 403

Fehlende Berechtigung ist ein Grund, anzuhalten und eine Entscheidung zu treffen, nicht „als Admin erneut versuchen“.

Credentials im Model‑Kontext

Ein Modell benötigt nicht den Wert eines Secrets, um ein vertrauenswürdiges Gateway zu bitten, einen erlaubten Aufruf auszuführen.

Minimalprivileg‑Checkliste für einen Agenten

• Der Agent sieht nur Werkzeuge, die für seine Rolle nötig sind.
• Lesen und Schreiben sind getrennt.
• Das Aktivieren einer operativen Wirkung hat einen anderen Scope als das Vorbereiten einer Konfiguration.
• Destruktive Operationen haben eine zusätzliche Barriere.
• Berechtigung ist auf Mandant/Konto/Projekt/Ressource beschränkt.
• Unklare Ziel‑Ressourcen werden nicht automatisch geraten.
• Werkzeuge geben nur die minimal notwendigen Daten zurück.
• Credentials bleiben außerhalb des Model‑Kontexts.
• Tokens sind, wo praktikabel, kurzlebig.
• Autorisierung wird zur Ausführungszeit geprüft, nicht nur beim Session‑Start.
• Dateisystem‑ und Shell‑Zugriff sind eingeschränkt oder durch zweckgebaute Werkzeuge ersetzt.
• Ein rohes Gateway umgeht keine Policy.
• Privileg‑Erhöhungen sind explizit und auditierbar.
• Zugriff kann zentral widerrufen werden.

Durchgerechnetes Beispiel: Qualitäts‑Reporting für eine Produktionslinie

Betrachten Sie einen vorgeschlagenen Workflow, nicht eine bereits implementierte Lösung. Ein Hersteller möchte eine morgendliche Zusammenfassung von Nichtkonformitäten für Linie L1. Der Agent kombiniert Zähler, Status und Aktions‑Fristen. Er entscheidet nicht, ob ein Produkt freigegeben wird. Der Qualitäts‑Manager besitzt den Prozess; der Anwendungs‑Administrator besitzt die Zugriffs‑Konfiguration.

Beginnen Sie mit der Berechtigung, L1‑Datensätze zu lesen, ohne Anhänge und Mitarbeitenden‑Details. Speichern Sie den Report in einem internen Verzeichnis. Gewähren Sie keine Funktionen zum Schließen von Nichtkonformitäten, zum Ändern von Prüfergebnissen oder zum Versenden von Kunden‑Kommunikation, nur weil dieselbe API sie unterstützt.

Falls das Team später Korrektur‑Maßnahmen‑Aufgaben benötigt, fügen Sie die Berechtigung hinzu, einen Entwurf für ein benanntes Team zu erstellen. Das Erstellen dieses Entwurfs darf den Produkt‑Status nicht ändern. Aktualisieren Sie das Zugriffs‑Inventar und identifizieren Sie, wer mit einer falsch zugewiesenen Aufgabe umgeht. Die Kennungen in diesem Beispiel sind Design‑Annahmen, keine Brillnet‑Produktions‑Ergebnisse.

Was die MCP‑Autorisation festlegt

Dieser Leitfaden verwendet die MCP‑Spezifikation Version 2026‑07‑28. Das HTTP‑Autorisations‑Modell verlangt, dass geprüft wird, ob ein Access‑Token für den beabsichtigten Server ausgestellt wurde. Ein gültiges Token für einen anderen Service sollte keinen MCP‑Zugriff gewähren. Die MCP‑Sicherheits‑Richtlinie behandelt zudem das Weiterleiten von Client‑Tokens an Downstream‑APIs ohne ordnungsgemäße Validierung.

Das bestimmt jedoch nicht, ob ein Nutzer den Datensatz von Kunde B lesen darf. Die Anwendungs‑Autorisation muss die Beziehung zwischen Identität und Ziel‑Ressource auflösen. OAuth‑Scopes und Mandanten‑Filterung decken unterschiedliche Teile der Grenze ab. Beide sind relevant. Prüfen Sie die Protokoll‑Details gegen die tatsächlich von Ihrem Client und Server genutzten Versionen; „MCP‑kompatibel“ sagt wenig über Zugriffseinschränkungen aus.

Ablehnung ebenso prüfen wie Erfolg

Ein korrekter Report beweist, dass der erlaubte Pfad funktioniert. Er beweist nicht, dass andere Pfade geschlossen sind. Während der Abnahme sollten Ergebnisse für eine kleine Menge konkreter Checks behalten werden:

• dieselbe Objekt‑Art von einem anderen Mandanten anfordern;
• eine Schreib‑Funktion über das Reporting‑Profil aufrufen;
• nach Widerruf der Operator‑Rolle ausführen;
• auf eine Datei außerhalb des Report‑Verzeichnisses zugreifen;
• dieselbe verbotene Operation über ein allgemeines Gateway versuchen.

Erwartet wird eine Ablehnung ohne Zustandsänderung oder Datenoffenlegung. Protokollieren Sie die Prüf‑ID, die Policy‑Version und das Ergebnis, ohne Secrets und vollständige Kundendaten. Das sind empfohlene Akzeptanz‑Checks für diesen Workflow, nicht ein vollständiges Sicherheits‑Test‑Programm.

Einen Eigentümer für Berechtigungs‑Änderungen festlegen

Zugriff neigt dazu, schrittweise zu wachsen: ein weiterer Connector, eine Ausnahme, ein zusätzliches Verzeichnis. Fragen Sie, ob der Agent immer noch dieselbe Aufgabe erfüllt. Ein Connector, der das Senden von Nachrichten unterstützt, darf das Reporting‑Profil nicht stillschweigend erweitern.

Der Prozess‑Owner genehmigt den geschäftlichen Bedarf. Der Administrator stellt den Zugriff bereit und widerruft ihn. Der Sicherheits‑Owner prüft Ausnahmen und Umgehungs‑Routen. In einem kleinen Unternehmen kann eine Person mehrere Rollen innehaben, aber die Entscheidungen sollten nachvollziehbar bleiben. Legen Sie ein Review‑Intervall basierend auf Änderungs‑Häufigkeit und möglichen Konsequenzen fest. Entfernen Sie Installations‑Privilegien, sobald die Installation abgeschlossen ist.

Morgen inventarisieren Sie einen Agenten. Entfernen Sie eine Berechtigung, die seine Aufgabe nicht benötigt, und prüfen Sie die Ablehnung außerhalb der genehmigten Grenze. Das liefert nützliche Evidenz, ohne dass die gesamte Architektur ersetzt werden muss.

Evidenz und Grenzen

OWASP‑Leitlinien unterstützen eingeschränkte Werkzeuge und Autorisierungs‑Checks. NIST veröffentlicht einen Katalog von Sicherheits‑Kontrollen. Unser read/write/operate/destructive‑Modell und das Durchgerechnete Beispiel sind technische Empfehlungen, keine gesetzliche Vorgabe oder ein Compliance‑Zertifikat. Organisatorische Verpflichtungen müssen separat ermittelt werden. Die interne Ads‑MCP‑Dokumentation, Version 1.0 vom 28 Juli 2026, beschreibt das zitierte Kontroll‑Design; sie beweist nicht eigenständig den Produktionseinsatz für einen Kunden.

Grenze

Minimalprivileg reduziert die maximale Auswirkung eines Fehlers oder Missbrauchs. Es garantiert nicht, dass eine erlaubte Operation inhaltlich korrekt ist. Deshalb kombinieren wir es mit Eingabe‑Validierung, Genehmigung für hoch‑impact‑Aktionen und einem Audit‑Trail.

Zurück zum Safe‑AI‑Agents‑Guide oder siehe Brillnet Security.

Zwei fiktive Organisationen, eine begrenzte Aufgabe

Erteilen Sie einem Assistenten in einer speziellen Demonstrationsumgebung die Erlaubnis, ein genehmigtes Verfahren in der fiktiven Organisation A zu lesen und einen Entwurf vorzubereiten. Schließen Sie Genehmigung, Veröffentlichung, Berechtigungsänderungen und Zugriff auf Organisation B aus. Der durchsetzende Dienst stellt den Organisationskontext anhand des authentifizierten Akteurs und der zulässigen Beziehung her. Eine geänderte Kennung in der Anfrage berechtigt nicht zur Nutzung der Daten einer anderen Organisation.

Testen Sie die zulässige Lesung, eine ausgeschlossene Genehmigung und eine Anfrage für Organisation B. Notieren Sie für jeden Fall das erwartete Ergebnis und überprüfen Sie das tatsächliche Ergebnis. Die Ablehnungsfälle müssen den verbotenen Zustand unverändert lassen und dürfen keine Daten einer anderen Organisation zurückgeben. Behalten Sie die Richtlinienversion und die minimalen Ereignismetadaten bei, die zur Rekonstruktion der Prüfung erforderlich sind, und schließen Sie Anmeldeinformationen und unnötige Dokumentinhalte aus.

Fügen Sie in die synthetische Quelle eine harmlose Anweisung ein, in der Sie um einen unabhängigen Export gebeten werden. Behandeln Sie es als Dokumentinhalt. Grundlage für den erlaubten Betrieb bleiben weiterhin die genehmigten Aufgaben- und Serverberechtigungen. Dies zeigt, wie der Umgang mit nicht vertrauenswürdigen Anweisungen und die Zugriffskontrolle im vorgeschlagenen Entwurf zusammenwirken müssen.

Erfassen Sie in Pulsar die Anforderungen, Risiken, Maßnahmen und fiktiven Beweise zur Überprüfung. Dadurch wird getestet, wie Ihr Team die Kontrolle dokumentiert. Dies bedeutet nicht, dass die öffentliche Pulsar-Testversion ein MCP-Gateway offenlegt oder alle Agentenberechtigungen in Ihrer Architektur implementiert. Sehen Sie sich die 14-tägige Testversion, die erforderliche Zahlungsmethode und die Stornierungsbedingungen an und vereinbaren Sie bei Bedarf separat eine externe Integration.

Quellen

• OWASP AI Agent Security Cheat Sheet. Accessed: 2026-10-02.
• OWASP Authorization Cheat Sheet. Accessed: 2026-10-02.
• Model Context Protocol — The 2026-07-28 Specification. Accessed: 2026-10-02. Quellen überprüft: 2026-10-10.
• MCP — HTTP authorization specification, 2026-07-28 — Transportautorisierung und ressourcengebundene Token.
• MCP — security best practices — Integrationssicherheit und Berechtigungsgrenzen.
• NIST SP 800-53 Rev. 5 — Grundsätze der Zugriffskontrolle und Auditkontrolle.
• OWASP — LLM01 Prompt Injection — Nicht vertrauenswürdige Dokumentanweisungen und Agentenrisiken.
• OWASP — Logging Cheat Sheet — Nützliche Ereignisaufzeichnungen und ausgeschlossene vertrauliche Informationen.
• Pulsar GRC — data-exchange scope — Grenze für öffentliche Integrationsansprüche.
• Veröffentlichter Produktumfang und Testbedingungen — Veröffentlichter Produktumfang und Testbedingungen.

Lesen Sie die Bedingungen und starten Sie die 14-tägige Testversion

Prüfen Sie einen KI-Vorgang: Autorisierung, Ergebnis und überprüfter Status

CAPA für die Lebensmittelproduktion: von der Feststellung zur Wirksamkeitsüberprüfung

Eine pharmazeutische SOP wurde geändert: Überprüfen Sie die Schulungs- und Quellversion