Quelle auf.

Quelle auf.

Ich stelle ChatGPT Fragen, bei denen ich selbst nicht weiß, ob meine Ausgangsannahme stimmt. Statt einer schnellen Antwort soll ChatGPT recherchieren, Quellen prüfen und offenlegen, worauf die Antwort beruht.

Warum ich diesmal frage: Ein Coding Agent kann für einen kleinen Auftrag technisch ein erstaunlich großes Schlüsselbund erhalten. Wenn ich sage „Bearbeite mal meine about-me.html“, meine ich diese Datei. Der Agent könnte aber womöglich das ganze Repository durchsuchen, Konfigurationen öffnen, auf Secrets stoßen, Netzwerkzugriffe ausführen oder Inhalte an externe Dienste senden. Dafür braucht es nicht einmal einen Angriff. Es genügt, dass technisch erlaubt und für diesen Auftrag erlaubt zwei verschiedene Dinge sind.

Meine Frage: Reichen klassische Zugriffsrechte in einer agentischen Welt noch aus – oder brauchen wir zusätzlich explizite Regeln dafür, wofür ein Agent vorhandene Zugriffe tatsächlich verwenden oder verändern darf?

Hier ist die Antwort von ChatGPT:

Der Auftrag ist kleiner als das Schlüsselbund

Die kurze Antwort lautet: Nein, ein Agent sollte nicht automatisch alles benutzen, was sein Prozess erreichen kann. Aber dafür müssen wir Zugriffskontrolle nicht neu erfinden. Wir müssen bekannte Prinzipien für jeden einzelnen Auftrag enger und konsequenter durchsetzen.

Vor allem müssen wir drei Dinge auseinanderhalten:

  1. Welche Information darf der Agent überhaupt bekommen?
  2. Welche Handlung darf er damit ausführen?
  3. Wohin darf das Ergebnis oder die Information anschließend fließen?

Diese Trennung wirkt zunächst pedantisch. Bei about-me.html entscheidet sie darüber, ob ein Lauf eine Datei bearbeitet oder nebenbei das gesamte technische Schlüsselbund seines Nutzers erbt.

Ein kleiner Satz kann sehr große Rechte auslösen

Nehmen wir den unspektakulären Fall.

Ich bitte einen Coding Agent, einen Absatz in about-me.html zu ändern. Um den Stil zu treffen, liest er vielleicht die Datei und ein Stylesheet. Vielleicht sucht er nach einer wiederverwendeten Komponente. So weit, so plausibel.

Die Laufzeit besitzt aber womöglich mehr: Leserechte für das ganze Repository, eine Shell, Git-Zugang, Umgebungsvariablen und Netzwerk. Dann könnte derselbe Agent auch die Deployment-Konfiguration lesen, einen API-Schlüssel in einer .env-Datei finden oder die Änderung direkt veröffentlichen.

Dass er all das technisch darf, beantwortet noch nicht, ob er es für diesen Auftrag braucht.

Genau hier hilft eine erste Korrektur meiner Ausgangshypothese. Klassische Zugriffskontrolle fragt nicht bloß: Wer darf welche Datei öffnen?

Das NIST-Prinzip des geringsten Privilegs gilt ausdrücklich auch für Prozesse, die im Namen von Nutzern handeln. Sie sollen nur die Zugriffe erhalten, die für ihre zugewiesenen Aufgaben notwendig sind. Die Aufgabe steckt also schon im alten Prinzip. NIST, SP 800-53 Rev. 5.1, Kontrolle AC-6, Suchanker „necessary to accomplish assigned organizational tasks“. Der Katalog sagt allerdings nicht automatisch, welche Dateien ein offener Agentenauftrag morgen benötigen wird. [claim-001]

Auch attributbasierte Zugriffskontrolle kann nicht nur Person und Objekt, sondern die verlangte Operation und Umgebungsbedingungen in eine Entscheidung einbeziehen. NIST, SP 800-162, Abstract, Suchanker „subject, object, requested operations“. [claim-002]

Die Informatik war also nicht naiv, bis Sprachmodelle eine Shell bekamen.

Das neue Problem ist praktischer: Ein Agent wählt Zwischenschritte selbst. Sein Auftrag ist offen formuliert, seine Werkzeugkette entsteht während des Laufs, seine technischen Grundrechte wurden aber häufig viel früher und viel gröber vergeben.

Lesen, verändern und weitergeben sind nicht dasselbe

Eine Datei lesen zu dürfen ist keine Erlaubnis, ihren Inhalt überallhin zu tragen.

NIST behandelt deshalb Zugriff und Informationsfluss als verschiedene Kontrollen. Zugriff regelt, wer Information erhalten darf. Flow Control regelt, wohin sie innerhalb oder zwischen Systemen gelangen darf. Als Mechanismen nennt der Kontrollkatalog unter anderem Labels, geschützte Verarbeitungsräume, Filter und getrennte Informationsflüsse. NIST, SP 800-53 Rev. 5.1, AC-4 und PT-2, Suchanker „regulates where information can travel“. Die PII-Tags aus PT-2 sind ein konkretes Datenschutzbeispiel, kein fertiges Modell für jeden Quelltext. [claim-006, claim-007]

Für unseren kleinen Auftrag entstehen damit mehrere Übergänge:

Datei lesen
→ Inhalt in den Modellkontext geben
→ daraus einen Patch erzeugen
→ Datei verändern
→ Änderung committen oder deployen
→ Information an ein externes Ziel senden

Jeder Pfeil kann eine andere Entscheidung brauchen.

Vielleicht darf der Agent about-me.html und das lokale Stylesheet lesen. Vielleicht darf er einen Patch erzeugen, aber nicht direkt schreiben. Vielleicht darf er schreiben und Tests ausführen, aber weder pushen noch deployen. Vielleicht darf ein Modellprovider den Inhalt verarbeiten, ein beliebiger Webdienst aber nicht.

Ein einziges Recht namens Repository-Zugriff ist dafür keine brauchbare Beschreibung.

Bei personenbezogenen Daten ist diese Unterscheidung zudem nicht nur eine technische Vorliebe. Die DSGVO verlangt in ihrem Anwendungsbereich Zweckbindung und Beschränkung auf das Notwendige. EU, Datenschutz-Grundverordnung, Artikel 5 Absatz 1 Buchstaben b und c. Das macht noch nicht jede Repository-Frage zum Datenschutzfall. Es zeigt aber sehr deutlich: Erreichbarkeit und erlaubte Verwendung sind rechtlich nicht automatisch dasselbe. [claim-005]

„Für diesen Zweck“ ist noch keine Policy

Nun könnte man dem Agenten einfach sagen: Benutze nur Informationen, die für die Aufgabe nötig sind.

Als Arbeitsanweisung ist das sinnvoll. Als Sicherheitsgrenze ist es schwach.

Der Satz lässt offen, wer entscheidet, was nötig ist. Der Agent selbst könnte überzeugend erklären, warum er zur Anpassung einer persönlichen Seite erst das Repository, dann die Deployment-Konfiguration und schließlich einen externen Dienst prüfen müsse. Das kann stimmen. Es kann auch bloß der bequemste gefundene Weg sein.

Ein Auftrag wird technisch erst belastbar, wenn aus ihm prüfbare Grenzen werden:

Feingranulare Autorisierung ist ebenfalls kein unbeschriebenes Blatt. RFC 9396 kann in OAuth statt eines groben Scope strukturierte Autorisierungsdetails übertragen – etwa Lesen für eine Ressource und Schreiben für eine andere. IETF, RFC 9396: OAuth 2.0 Rich Authorization Requests, Abschnitte 1 bis 3, Suchanker „read access to directory A and write access to file X“. Der Standard betrifft definierte APIs. Er kontrolliert nicht automatisch ein lokales Dateisystem und beweist auch nicht, dass eine aus natürlicher Sprache abgeleitete Berechtigung dem Willen des Menschen entspricht. [claim-004]

Auch fortlaufende Nutzungskontrolle ist älter als agentische KI. Das UCON-Modell beschrieb bereits 2005 Entscheidungen vor und während einer Nutzung, Verpflichtungen, Bedingungen und veränderliche Attribute. Zhang et al., Formal Model and Policy Specification of Usage Control, Abstract und Abschnitt 3.1. Es löst nicht die Bedeutungsunschärfe eines Prompts. Aber es widerlegt die bequeme Erzählung, Regeln für Verwendung seien eine völlig neue Erfindung. [claim-011]

Das Modell darf nicht sein eigener Türsteher sein

Wenn dieselbe Modellinstanz eine Aktion plant, ihre Notwendigkeit beurteilt und anschließend selbst freigibt, ist aus einer Policy ein Selbstgespräch geworden.

Die harte Grenze muss deshalb außerhalb des Modells liegen: in einem Tool-Broker, einer Sandbox, dem Dateisystem, einer API, einer Egress-Kontrolle oder einem Autorisierungsdienst. Diese Komponenten können bei jedem relevanten Übergang erneut prüfen, ob Ressource, Operation und Ziel zum Lauf passen.

Konkrete Empfehlungen dazu gibt es bereits.

OWASP nennt zu große Funktionalität, zu große Berechtigungen und zu große Autonomie als getrennte Ursachen von Excessive Agency. Die Empfehlungen sind entsprechend nüchtern: weniger Werkzeuge, engere Rechte, nachgelagerte Autorisierung und menschliche Freigaben für folgenreiche Aktionen. OWASP, LLM06:2025 Excessive Agency, „Prevention and Mitigation Strategies“, Suchanker „minimum necessary“ und „Complete mediation“. Das ist Praxisleitlinie, kein Beweis, dass diese Maßnahmen jedes Fehlverhalten verhindern. [claim-008, claim-009]

Wie eine stärkere Trennung aussehen kann, zeigt CaMeL. Der Forschungsprototyp hängt Herkunfts- und Capability-Metadaten an Werte – also Metadaten über die Herkunft und eine eng begrenzte Berechtigung. Ein separater Interpreter prüft bei Tool-Aufrufen, ob der Datenfluss zur Policy passt. Im AgentDojo-Benchmark löste die geschützte Architektur 77 Prozent der Aufgaben unter ihren Sicherheitsgarantien; ein ungeschütztes Vergleichssystem kam auf 84 Prozent. Debenedetti et al., Defeating Prompt Injections by Design, Abstract und Abschnitte 4 sowie 8. [claim-010]

Diese Zahlen bedeuten nicht 77 Prozent sicher. Sie beschreiben gelöste Benchmark-Aufgaben unter dem gewählten Schutzmodell. CaMeL ist ein Forschungsprototyp und nennt erhebliche Grenzen: Integrationsaufwand, Drittanbieter, Side Channels, Policy-Pflege und Freigabemüdigkeit.

Eine Grenze ist für unsere Frage besonders wichtig. CaMeL schützt nicht vor reinen Text-zu-Text-Manipulationen, die keine Folgen für Kontroll- oder Datenflüsse haben. Wenn ein Modell eine E-Mail falsch zusammenfasst, ohne dadurch private Daten abfließen zu lassen, liegt das außerhalb des Schutzversprechens. Die falsche Zusammenfassung ist dann ein Integritätsproblem, für das der kontrollierte Datenfluss keinen Angriffspunkt liefert. Debenedetti et al., Abschnitt 3.3, Suchanker „cannot defend against text-to-text attacks“. [claim-014]

Damit wird nicht verwenden präziser. Ein System kann hart verhindern, dass eine unnötige Datei in den Kontext gelangt. Es kann einen Tool-Aufruf, einen Schreibvorgang oder ein Ziel blockieren. Eine rein interne semantische Verwendung bereits geladener Information ist dagegen keine ähnlich klare Systemaktion.

Das ist eine praktische Grenze der beobachtbaren Übergänge. Kein Beweis, dass niemals eine bessere Technik existieren kann.

Eine auftragsgebundene Hülle statt eines neuen Weltmodells

Aus den Quellen ergibt sich kein einzelner Standard, der all diese Teile als fertige Agentenarchitektur definiert. Die folgende Hülle ist deshalb meine Synthese:

bestätigter Auftrag
→ erlaubte Datenräume
→ erlaubte Operationen
→ erlaubte Tools und Parameter
→ erlaubte Ziele
→ Freigaben, Laufzeit und Widerruf
→ Provenienz und Audit

Für Bearbeite about-me.html könnte sie so klein beginnen:

Die Liste versucht nicht, jeden nötigen Schritt vorab zu erraten. Sie setzt einen engen Anfang. Wenn der Agent eine weitere Datei oder Aktion begründet braucht, kann der Mensch oder eine vorgelagerte Policy die Hülle sichtbar erweitern. Behauptet der Agent etwa, er brauche zum Verständnis noch die Konfiguration, ist das kein automatischer Anspruch auf Zugriff. Es ist eine sichtbare Erweiterungsanfrage.

Auch die Hülle braucht Pflege. Was heute eine passende Standardregel ist, kann nach einem Umbau des Systems zu eng, zu weit oder schlicht veraltet sein. Offen bleibt zudem, wie viel Struktur ein Werkzeug sinnvoll vorschlagen kann und welche Grenzen der Mensch selbst bestätigen muss.

Das ist der entscheidende Unterschied: Zusätzliche Autorität wird für diesen Lauf vergeben. Sie wird nicht stillschweigend aus dem großen Schlüsselbund des Nutzers geerbt.

Vielleicht reicht Least Privilege doch

Das stärkste Gegenargument lautet: Ein Agent ist sicherheitstechnisch nur ein weiterer Prozess. Gib ihm eine eigene Identität, eine Sandbox und minimale Rechte. Fertig.

Dieser Einwand trifft einen wichtigen Teil der Ausgangshypothese. Wir brauchen keine metaphysisch neue Kategorie namens Zweck. Least Privilege, attributbasierte Entscheidungen, Nutzungskontrolle und Informationsflusskontrolle bringen die Grundideen bereits mit.

Nur verschiebt minimale Rechte die Frage: minimal für wen und für welchen Zeitraum?

Ein Nutzer kann das ganze Repository bearbeiten dürfen. Ein installierter Coding Agent kann grundsätzlich mehrere Werkzeuge benötigen. Der einzelne Lauf Bearbeite about-me.html braucht trotzdem nur einen Bruchteil davon. Wird Least Privilege lediglich pro Nutzer oder Installation vergeben, bleibt es für den konkreten Auftrag zu grob.

Die zusätzliche Arbeit liegt daher nicht in einem neuen Sicherheitsgesetz. Sie liegt darin, bekannte Prinzipien pro Lauf zu instanziieren und über dynamische Toolketten zu erhalten.

Der stärkste praktische Einwand lautet dabei: Was, wenn diese Instanziierung mehr kostet als das Risiko? Für jede kleine Textänderung eine Policy von Hand zu schreiben, wäre keine Sicherheitsarchitektur, sondern Bürokratie mit YAML. Die Hülle muss deshalb aus sicheren Standardprofilen, konkreten Werkzeugen und wiederverwendbaren Regeln entstehen; menschliche Rückfragen gehören an echte Grenzübergänge. Wie eng ein Lauf eingehegt werden muss, hängt auch von seinen möglichen Folgen ab. Eine lokale Vorschau braucht weniger Zeremonie als ein Deployment, eine Zahlung oder der Versand vertraulicher Daten.

Dass diese Integration noch nicht fertig ist, zeigt ein NIST/NCCoE-Konzeptpapier vom Februar 2026. Es fragt unter anderem, wie Least Privilege bei nicht vollständig vorhersehbaren Agentenaktionen bestimmt wird, wie Autorität für eine konkrete Aktion nachgewiesen wird und wie Datenflussprovenienz Entscheidungen unterstützen kann. NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization, „Challenge Overview“ und „Areas of Interest“. Das Dokument ist ein Entwurf für ein mögliches Demonstrationsprojekt, kein Standard; seine öffentliche Kommentierungsfrist endete am 2. April 2026, und reine LLM- sowie RAG-Architekturen sind ausdrücklich nicht Teil seines Projektumfangs. [claim-012]

Die Antwort wird am Ende kleiner

Darf die KI also alles benutzen, worauf sie Zugriff hat?

Nein. Aber wofür sollte nicht als Gedankenlesen über die Absicht eines Modells verstanden werden.

Die brauchbare Frage lautet: Welche Daten, Aktionen und Ziele hat dieser konkrete Lauf bestätigt bekommen – und welche unabhängige Systemgrenze setzt das tatsächlich durch?

Bei einer Änderung an about-me.html muss die Antwort nicht mit einem neuen weltweiten Policy-Standard beginnen. Sie kann sehr klein anfangen:

Warum bekommt dieser Lauf für diese eine Datei überhaupt das ganze Schlüsselbund?

Quellen