Ein Agent ist kein Benutzer mit geliehenem Passwort

Der Agent als eigener Principal

Sobald ein Agent handelt statt nur zu antworten, wird er zu einem Akteur im System. Alles, was für menschliche Konten gilt, gilt dann auch für ihn: eindeutige Identität, minimale Rechte, befristete Credentials, nachvollziehbare Spur. Nur die Kontrollen unterscheiden sich — ein Agent kann keine MFA-Abfrage beantworten, dafür lässt sich seine Rechteliste maschinell erzwingen.

Agent Identity

Eigenständige, maschinenlesbare Identität eines KI-Agenten mit eigener Kennung, eigenem Rechteumfang und eigener Spur im Audit-Log — getrennt von der Identität des Menschen, der den Lauf ausgelöst hat.

Resource Indicator

Angabe des Zielsystems bei der Ausstellung eines Tokens (RFC 8707). Das ausgestellte Token gilt nur für genau diese Zielgruppe und ist bei einem anderen Dienst wertlos — auch wenn es dort abgefangen wird.

Blast Radius

Der maximale Schaden, den ein kompromittierter oder fehlgeleiteter Agent anrichten kann. Er ergibt sich aus Scopes, Betragsgrenzen, Egress-Regeln und Laufzeit der Credentials — nicht aus der Formulierung des Prompts.

Die Policy Engine entscheidet, nicht der Prompt

Eine Regel im Prompt ist eine Bitte. Eine Regel in der Policy Engine ist eine Bedingung. Der Unterschied wird sichtbar, sobald ein manipuliertes Dokument dem Modell eine andere Anweisung gibt — die Bitte kann es ignorieren, die Bedingung nicht.

# Standardentscheidung ist deny. Jede Erlaubnis ist explizit.
default decision = "deny"

# Lesende Abfragen: erlaubt, solange der Agent den Scope hat
# und das Ergebnis eine sinnvolle Groesse nicht ueberschreitet.
allow {
  input.tool == "postgres.query"
  input.agent.scopes[_] == "read:orders"
  input.params.max_rows <= 500
}

# Geld bewegen: nur unterhalb der Grenze, nur in EUR, nur wenn
# der Vorgang zum aktuellen Lauf gehoert. Der Idempotenz-Key
# verhindert, dass derselbe Refund zweimal genehmigt wird.
allow {
  input.tool == "stripe.refund"
  input.agent.scopes[_] == "write:refund"
  input.params.amount <= 250
  input.params.currency == "EUR"
  input.params.order_id == input.run.context.order_id
}

# Darueber entscheidet ein Mensch. Kein Selbstfreigabe-Pfad.
require_approval {
  input.tool == "stripe.refund"
  input.params.amount > 250
}

# Sub-Agenten duerfen nie mehr Rechte anfordern als der Eltern-Lauf.
deny {
  input.agent.parent
  not subset(input.agent.scopes, input.agent.parent.scopes)
}

Sandboxing, Egress und Prompt Injection

Sicherheitsstandards adressieren inzwischen ausdrücklich die Protokollebene: Isolation der Ausführungsumgebung von MCP-Servern, Authentifizierung des Aufrufers über Modell-API, MCP und A2A hinweg, Protokollierung mit Werkzeug-Metadaten. Praktisch heißt das bei uns:

• Isolierte Ausführung. Jeder nicht selbst gebaute MCP-Server läuft in einem eigenen Container ohne Zugriff auf das Dateisystem des Hosts, ohne Zugangsdaten anderer Werkzeuge, mit begrenztem Speicher und begrenzter Laufzeit.
• Egress-Allowlist. Ausgehende Verbindungen sind grundsätzlich blockiert. Erlaubt sind nur namentlich gelistete Ziele mit Port. Datenabfluss über einen kompromittierten Konnektor wird damit zur Konfigurationsänderung, nicht zum stillen Vorfall.
• Daten sind keine Anweisungen. Rückgaben von Werkzeugen werden als untrusted markiert und in einen separaten Kontextbereich gelegt. Was dort steht, kann Verhalten nicht umdefinieren — die Grenzen kommen aus Policy und Scopes, nicht aus dem Prompt.
• Gepinnte Versionen. Externe MCP-Server werden auf eine geprüfte Version festgelegt. Ein Update ist eine bewusste Entscheidung mit erneuter Prüfung, kein automatischer Vorgang.

Was das nicht löst