Was KI-Agenten dürfen (und nicht dürfen)

Nicht alle Aktionen sind sicher
Auf dieser Seite
  1. Was erlaubte Aktionen sind (Permissions)
  2. Berechtigungsstufen
  3. Warum ein Agent nicht Zugriff auf alles bekommen darf
  4. Wer die Grenzen festlegt
  5. Prinzip der minimalen Berechtigungen
  6. Im Code sieht das so aus
  7. 1) Wir haben Tools mit unterschiedlichen Risikostufen
  8. 2) Hier setzen wir Berechtigungen für diesen Agenten
  9. 3) Das Modell fordert eine Aktion an
  10. 4) Das System prüft Rechte vor der Ausführung
  11. 5) Wenn die Stufe erlaubt ist, führen wir die Aktion aus
  12. Analogie aus dem Alltag
  13. Kurz zusammengefasst
  14. FAQ
  15. Was als Nächstes

Ein KI-Agent kann mehr als nur auf Anfragen antworten.

Er kann:

  • Daten ändern
  • API-Anfragen senden
  • Dateien erstellen
  • Oder Prozesse starten

Das heißt: Er kann Aktionen in der realen Welt ausführen.


Genau hier entsteht ein neues Problem.

Denn nicht alle Aktionen sind sicher.

Ein Agent kann:

  • Daten löschen
  • Geld ausgeben
  • Oder eine Anfrage an ein externes System senden

Auch wenn du das nicht geplant hast.


Deshalb darf ein Agent nicht alles dürfen.

Er braucht Grenzen.

Was erlaubte Aktionen sind (Permissions)

KI-Agent: Wann ein Agent stoppen muss (und wer das entscheidet)

Ein Agent hat keinen direkten Zugriff auf Tools.

Er kann nicht selbst:

  • Eine Datei öffnen
  • Einen Datenbankeintrag ändern
  • Oder eine API-Anfrage senden

Um eine Aktion auszuführen, muss er ein Tool verwenden.

Und nur die Tools, die er aufrufen darf.


Diese Liste erlaubter Aktionen sind seine Permissions.

Sie definieren:

  • Was der Agent kann
  • Und was er nicht kann

Berechtigungsstufen

Nicht alle Aktionen sind gleich sicher.

Diagram

Deshalb werden Berechtigungen meist in Stufen aufgeteilt — je nachdem, wie stark der Agent das System beeinflussen kann.


Read
Der Agent kann Daten abrufen. Er kann sie aber nicht ändern.

Zum Beispiel: einen Datenbankeintrag lesen, eine Datei öffnen, Status prüfen.


Write
Der Agent kann Daten erstellen oder ändern.

Zum Beispiel: einen neuen Eintrag erstellen, eine Datei aktualisieren, ein Ergebnis speichern.


Execute
Der Agent kann Prozesse oder externe Services aufrufen.

Zum Beispiel: eine API-Anfrage senden, ein Skript starten, einen Webhook aufrufen.


Delete
Der Agent kann Daten oder Einträge löschen.

Das ist die gefährlichste Stufe.
Denn die Aktion ist nicht umkehrbar.


Je höher die Berechtigungsstufe, desto mehr kann der Agent in der Welt verändern.

Darum bekommt er nur den Zugriff, der für die Aufgabe nötig ist.

Warum ein Agent nicht Zugriff auf alles bekommen darf

Ein Agent versteht die Folgen seiner Aktionen nicht.

Er wählt das Tool, das in diesem Kontext am passendsten aussieht.

StufeWas erlaubt istRisiko
ReadDaten abrufenNiedrig
WriteErstellen oder ändernMittel
ExecuteProzesse oder API startenHoch
DeleteDaten löschenKritisch

Aber "passend" bedeutet nicht immer "sicher".

Ein Agent kann:

  • Falsche Daten speichern
  • Eine kostenpflichtige API aufrufen
  • Oder eine wichtige Datei löschen

Einfach weil das beim Lösen der Aufgabe hilft.


Wenn du ihm Zugriff auf alles gibst, kann er mehr tun, als du erwartet hast.

Wer die Grenzen festlegt

Ein Agent wählt seine Berechtigungen nicht selbst.

Er entscheidet nicht:

  • Auf welche Tools er Zugriff hat
  • Welche Aktionen er ausführen darf

Diese Grenzen legt ein Mensch fest.

Oder ein System, das definiert:

  • Welche Tools erlaubt sind
  • Welche Aktionen ausgeführt werden dürfen
  • Und auf welcher Zugriffsstufe

Der Agent arbeitet nur innerhalb dieser Regeln.

Prinzip der minimalen Berechtigungen

Es gibt eine einfache Regel:

Ein Agent bekommt nur den Zugriff, der für eine konkrete Aufgabe notwendig ist.

Nicht mehr.


Das nennt man das Prinzip der minimalen Berechtigungen (Least Privilege).


Wenn ein Agent nur Lesezugriff braucht, darf er keinen Schreibzugriff bekommen.

Wenn er eine Datei erstellen soll, darf er sie nicht löschen können.


Weniger Berechtigungen bedeuten weniger Risiken.

Im Code sieht das so aus

Unten ist dasselbe Prinzip in einem einfachen Format:
wir definieren explizit, was der Agent darf, und zwingen das System, das vor jeder Aktion zu prüfen.

1) Wir haben Tools mit unterschiedlichen Risikostufen

PYTHON
def read_user(user_id: int):
    return {"id": user_id, "status": "active"}


def update_user(user_id: int, status: str):
    return {"id": user_id, "status": status}


def send_webhook(event: str):
    return {"sent": event}


def delete_user(user_id: int):
    return {"deleted": user_id}


TOOLS = {
    "read_user": {"level": "read", "handler": read_user},
    "update_user": {"level": "write", "handler": update_user},
    "send_webhook": {"level": "execute", "handler": send_webhook},
    "delete_user": {"level": "delete", "handler": delete_user},
}

2) Hier setzen wir Berechtigungen für diesen Agenten

PYTHON
AGENT_PERMISSIONS = {"read", "write"}  # execute und delete sind verboten

3) Das Modell fordert eine Aktion an

PYTHON
model_output = {
    "action": "update_user",
    "parameters": {"user_id": 42, "status": "paused"},
}

4) Das System prüft Rechte vor der Ausführung

PYTHON
def run_action(call: dict):
    action = call["action"]
    params = call["parameters"]

    tool = TOOLS.get(action)
    if tool is None:
        return {"error": "Tool nicht gefunden"}

    if tool["level"] not in AGENT_PERMISSIONS:
        return {"error": "Aktion nicht erlaubt"}

    return tool["handler"](**params)

5) Wenn die Stufe erlaubt ist, führen wir die Aktion aus

PYTHON
result = run_action(model_output)
# {"id": 42, "status": "paused"}

Wenn das Modell delete_user anfordert, gibt das System zurück:

JSON
{
  "error": "Aktion nicht erlaubt"
}

Vollständiges Implementierungsbeispiel mit angebundener LLM

PYPython
TSTypeScript · bald

Analogie aus dem Alltag

Stell dir vor, du gibst jemandem Schlüssel zu deiner Wohnung.

Wenn nur die Blumen gegossen werden müssen, gibst du den Haustürschlüssel.


Aber du gibst nicht:

  • Den Schlüssel zum Safe
  • Zugriff auf die Banking-App
  • Oder die PIN deiner Karte

Denn je mehr Zugriff, desto mehr kann verändert werden.

Sogar aus Versehen.


Darum gibt man nur die Schlüssel, die für die konkrete Aufgabe nötig sind.

Kurz zusammengefasst

Kurzfazit

Ein Agent kann Aktionen über Tools ausführen.

Er darf aber:

  • Nur bestimmte Tools nutzen
  • Nur bestimmte Aktionstypen ausführen
  • Und nur auf einer bestimmten Zugriffsstufe

Üblicherweise nutzt man das Prinzip der minimalen Berechtigungen:

Der Agent bekommt nur den Zugriff, der für die Aufgabe nötig ist.

FAQ

Q: Kann ein Agent über Tools beliebige Aktionen ausführen?
A: Nein. Er kann nur die Tools und Aktionen verwenden, die ihm erlaubt sind.

Q: Wer legt fest, was ein Agent tun darf?
A: Ein Mensch oder ein System, das die Liste verfügbarer Tools und ihre Zugriffsstufe festlegt.

Q: Was ist das Prinzip der minimalen Berechtigungen?
A: Das ist eine Regel, nach der der Agent nur den Zugriff bekommt, der für eine konkrete Aufgabe nötig ist.

Was als Nächstes

Jetzt weißt du, was ein Agent tun darf.

Aber selbst mit Einschränkungen kann er:

  • In einer Schleife hängen bleiben
  • Dieselben Aktionen wiederholen
  • Oder Ressourcen verbrauchen

Darum muss ein Agent manchmal selbst stoppen.

Oder vom System gestoppt werden.

⏱️ 6 Min. LesezeitAktualisiert 21. Februar 2026Schwierigkeit: ★★☆
Praktische Fortsetzung

Beispiele zur Musterimplementierung

Setze das Thema direkt mit Beispielprojekten um.

Integriert: Production ControlOnceOnly
Guardrails für Tool-Calling-Agents
Shippe dieses Pattern mit Governance:
  • Budgets (Steps / Spend Caps)
  • Tool-Permissions (Allowlist / Blocklist)
  • Kill switch & Incident Stop
  • Idempotenz & Dedupe
  • Audit logs & Nachvollziehbarkeit
Integrierter Hinweis: OnceOnly ist eine Control-Layer für Production-Agent-Systeme.

Autor

Nick — Engineer, der Infrastruktur für KI-Agenten in Produktion aufbaut.

Fokus: Agent-Patterns, Failure-Modes, Runtime-Steuerung und Systemzuverlässigkeit.

🔗 GitHub: https://github.com/mykolademyanov


Redaktioneller Hinweis

Diese Dokumentation ist KI-gestützt, mit menschlicher redaktioneller Verantwortung für Genauigkeit, Klarheit und Produktionsrelevanz.

Der Inhalt basiert auf realen Ausfällen, Post-Mortems und operativen Vorfällen in produktiv eingesetzten KI-Agenten-Systemen.