Ein Agent ist kein Benutzer mit geliehenem Passwort
Der häufigste Konstruktionsfehler in Agenten-Projekten: Der Agent handelt unter dem Konto eines Administrators. Damit entspricht sein Schadensradius dessen Rechten — dauerhaft, unbegrenzt und im Log nicht unterscheidbar. Ein Agent braucht eine eigene Identität.
Geeignet fürUnternehmen, die KI-Agenten mit Aktionsrechten produktiv einsetzen wollen
Agent Identity · RFC 8707 · deny by default — kein Agent mit geliehenem Passwort
Das Wichtigste auf einen Blick
- Geeignet für
- Unternehmen, die KI-Agenten mit Aktionsrechten produktiv einsetzen wollen — nicht nur als Chatfenster
- Ausgangssituation
- Der Agent läuft unter einem Administratorkonto; sein Schadensradius ist unbegrenzt und im Log nicht unterscheidbar
- Wir übernehmen
- Eigene Identität je Agent, zielsystemgebundene Token nach RFC 8707, Policy Engine mit Standardentscheidung deny, Container-Isolation und Egress-Allowlist
- Bei Ihnen bleibt
- Ihre Daten und die Entscheidung, welche davon ein Modell sehen darf. Eigentum und Hoheit wechseln nicht.
- Vorhandene Systeme
- Welche Hardware und welche Schnittstellen sich weiterverwenden lassen, klären wir vor dem Angebot. Das Ergebnis steht schriftlich fest, bevor Sie beauftragen.
- Ihr Ergebnis
- Ein begrenzter Blast Radius. Und ein Audit-Log, in dem die erste Spalte etwas aussagt
- Preisrahmen
- Nach Aufwand — abhängig von Zahl der Agenten und angebundenen Werkzeuge, Rahmen im Erstgespräch
- Reaktionszeit
- Antwort auf Ihre Anfrage in der Regel innerhalb eines Werktags; im Betrieb nach vereinbarter Serviceklasse
- Dauer
- Security-Review vor dem ersten Produktivlauf — sechs Bedrohungen, je Scope, Limit und Freigabeschwelle
- Erster Schritt
- Gespräch über die geplanten Agenten, ihre Werkzeuge und die nötigen Freigabeschwellen
Der Agent als eigener Principal
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
# 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
| Bedrohung | Maßnahme | Restrisiko |
|---|---|---|
| Prompt Injection über Tool-Rückgabe | Getrennter Kontextbereich, Ausgabe-Schema-Validierung, Grenzen in der Policy statt im Prompt | Fachlich falsche, aber formal erlaubte Aktionen bleiben möglich |
| Kompromittierter MCP-Server | Container-Isolation, Egress-Allowlist, gepinnte Version, keine geteilten Zugangsdaten | Daten, die das Werkzeug legitim sieht, sieht auch der Angreifer |
| Gestohlenes Agenten-Token | Lebensdauer 10 Minuten, Bindung an Zielsystem, Bindung an Lauf-ID | Kurzes Zeitfenster für Missbrauch innerhalb desselben Scopes |
| Rechteausweitung über Sub-Agenten | Scopes sind Teilmenge des Eltern-Laufs, Prüfung in der Policy Engine | Fehlerhafte Modellierung des Eltern-Laufs wirkt nach unten durch |
| Gefälschte Agent Card (A2A) | Signaturprüfung verpflichtend, Registry-Eintrag mit Betreiberzuordnung | Signatur belegt Identität, nicht Qualität oder Absicht |
| Kostenexplosion durch Schleife | Budget-Cap je Lauf, Rate-Limit je Werkzeug, Versuchszähler | Bis zum Cap entstehen reale Kosten |
- 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
Ehrliche Grenzen
Prompt Injection ist nicht gelöst — weder bei uns noch anderswo. Wir können den Schaden begrenzen, indem wir Rechte klein halten, Beträge deckeln und irreversible Schritte an Menschen binden. Wir können nicht garantieren, dass ein Modell einen manipulierten Text nie befolgt. Wer diese Garantie braucht, darf dem Agenten an dieser Stelle keine Aktionsrechte geben — das ist eine Architekturentscheidung, keine Konfiguration.
Security im Detail
/01Warum reicht ein Service-Account nicht aus?+
Ein Service-Account ist statisch: dauerhaftes Geheimnis, fester Rechteumfang, keine Bindung an einen konkreten Vorgang. Ein Agenten-Credential wird je Lauf ausgestellt, ist an Zielsystem und Lauf-ID gebunden und verfällt nach Minuten. Der Unterschied zeigt sich im Schadensfall.
/02Wie greift das in unser bestehendes Identity-Management?+
/03Wer sieht, was ein Agent getan hat?+
Jede Aktion steht mit Agenten-Identität, Werkzeug, sanitisierten Parametern und Policy-Entscheidung im Audit-Log. Die Auswertung erfolgt in Ihrem eigenen Stack oder in unserem — auf Wunsch mit Weiterleitung an ein SIEM wie Wazuh. Details unter Observability.
/04Was passiert, wenn ein Agent auffällig wird?+
Agenten lassen sich einzeln stilllegen — Credential widerrufen, laufende Runs anhalten, Werkzeugfreigaben entziehen. Weil jede Identität einzeln existiert, trifft das nur den betroffenen Agenten und nicht den gesamten Betrieb.
/05Sind Agenten mit Aktionsrechten mit der DSGVO vereinbar?+
Ja, unter Bedingungen: dokumentierte Zweckbindung, Verarbeitung auf Grundlage eines AVV, nachvollziehbare Protokollierung und keine automatisierte Einzelentscheidung mit rechtlicher Wirkung ohne menschliche Beteiligung. Genau dafür gibt es die Freigabeschwellen. Einordnung auf der Trust-Seite.
/06Prüfen Sie fremde MCP-Server auf Schwachstellen?+
Wir prüfen Herkunft, Signatur, Schema-Qualität und Egress-Verhalten und pinnen die Version. Ein vollständiges Code-Audit fremder Server leisten wir nicht — wo das nötig ist, bauen wir den Konnektor selbst. Siehe Agentic Supply Chain.
Weiter in der Plattform
Security-Review vor dem ersten Produktivlauf
Rechte eines Agenten festlegen.
Ein Agent braucht eigene Identität und eigene Grenzen, nicht das Passwort eines Mitarbeiters. Wir legen mit Ihnen fest, was er darf und was nicht. Ausführlich beschrieben ist das unter Agentic AI.
Betrieb in deutschen Rechenzentren