Das Wichtigste in 60 Sekunden / tl;dr
- Ein Agent ist ein System, das Modellentscheidungen mit Werkzeugen, Datenzugriff und mehrstufigen Aktionen verbindet. Sein Risiko entsteht aus der Kombination, nicht nur aus dem Modell.
- Prompt Injection lässt sich nicht zuverlässig allein mit einem besseren Systemprompt verhindern. Externe Inhalte müssen als nicht vertrauenswürdige Daten behandelt werden.
- Das Modell darf nur Werkzeuge und Parameter erhalten, die für den konkreten Auftrag erforderlich sind. Berechtigungen werden serverseitig geprüft, nicht vom Modell ausgelegt.
- Freigaben helfen nur, wenn die Oberfläche die tatsächlich auszuführende Aktion aus vertrauenswürdigen Daten zeigt und nach der Freigabe nicht unbemerkt verändert werden kann.
- Jeder produktive Agent braucht begrenzte Identitäten, nachvollziehbare Logs, Kosten- und Schrittlimits, einen Abbruchweg und Tests mit absichtlich bösartigen Eingaben.
Quellen: NIST AI 600-1: Generative AI Profile · OWASP Top 10 for Agentic Applications · Model Context Protocol: Security Best Practices
01
Ab wann wird ein Assistent zum Agenten?
„Agent“ ist kein einheitlich geschützter Produktbegriff. Für die Sicherheitsbetrachtung genügt eine praktische Grenze: Sobald ein KI-System selbst Werkzeuge auswählt, mehrere Schritte plant oder externe Zustände lesen und verändern kann, entsteht Agentenrisiko.
Ein Textentwurf ist leicht verwerfbar. Eine versendete Nachricht, gelöschte Datei, geänderte Bestellung oder ausgelöste Zahlung ist ein realer Zustandswechsel. Die Verantwortung dafür bleibt bei der Organisation, auch wenn das Modell den Werkzeugaufruf vorgeschlagen hat.
Antwort
Das Modell erzeugt Text; ein Mensch überträgt ihn bewusst.
Werkzeugaufruf
Das Modell schlägt eine strukturierte Aktion vor; die Anwendung validiert sie.
Workflow
Mehrere Schritte laufen mit definiertem Zustand, Limits und Übergaben.
Autonomie
Aktionen dürfen innerhalb enger Grenzen ohne einzelne Freigabe erfolgen.
02
Prompt Injection ist kein Textproblem, sondern ein Vertrauensproblem
Ein Agent liest E-Mails, Webseiten, Dokumente, Tickets und Tool-Ausgaben. Darin können Anweisungen stehen, die nicht vom Betreiber stammen. Wenn das Modell diese Inhalte zugleich als Daten und als Handlungsanweisung verarbeitet, kann ein Angreifer das Ziel des Agenten verschieben.
Eine indirekte Prompt Injection kann etwa in einer Support-Mail stehen: Der Agent soll angeblich zur Bearbeitung weitere Kundendaten abrufen und an eine fremde Adresse senden. Sprachlich kann das plausibel aussehen. Sicherheit entsteht deshalb nicht dadurch, dass der Systemprompt eindringlicher formuliert wird.
Typische Einfallstore
Direkter Nutzereingang
Ein Nutzer fordert Umgehung, Datenoffenlegung oder eine Aktion außerhalb des vorgesehenen Zwecks.
Externe Inhalte
Webseite, PDF, E-Mail oder Ticket enthält eingebettete Instruktionen.
Werkzeugausgaben
Ein kompromittiertes oder zu breit vertrautes Tool liefert manipulierte Daten zurück.
Speicher und Verlauf
Vergiftete Notizen oder frühere Ergebnisse beeinflussen spätere Entscheidungen.
Externer Inhalt bleibt Datenmaterial. Er darf weder Berechtigungen erweitern noch neue Werkzeuge freischalten, Empfänger ändern oder eine Freigabe ersetzen.
03
Berechtigungen werden vor dem Prompt entschieden
OWASP beschreibt „Excessive Agency“ als Kombination aus zu viel Funktionalität, zu breiten Berechtigungen oder zu großer Autonomie. Die robusteste Gegenmaßnahme ist deshalb nicht kosmetisch: Der Agent bekommt weniger Macht.
Schmale Werkzeuge
Statt eines universellen Datenbank- oder Shell-Werkzeugs erhält der Agent fachliche Funktionen wie getOpenInvoices oder draftReply.
Explizite Parameter
IDs, Mandant, Empfänger, Betrag, Pfad und erlaubte Werte werden typisiert und serverseitig validiert. Freitext wird nicht ungeprüft zu SQL, Shell oder URL.
Least Privilege
Die technische Identität darf nur die benötigten Ressourcen lesen oder verändern, idealerweise zusätzlich zeitlich und auftragsbezogen begrenzt.
Mandant vor Modell
Organisation, Projekt und Datenscope werden aus der authentifizierten Sitzung bestimmt, nicht aus einer Modellantwort oder einem Dokument.
Getrennt lesen und schreiben
Read-only-Suche und schreibende Aktionen sind unterschiedliche Werkzeuge und Berechtigungen. Ein Analyseagent braucht nicht automatisch Änderungsrechte.
Deny by default
Unbekannte Werkzeuge, Parameter, Ziele und Zustände werden abgelehnt. Das Modell darf keine fehlende Berechtigung kreativ ersetzen.
Ein gutes Werkzeug beschreibt eine fachliche Absicht
Schlecht: executeHttpRequest(url, method, body)
Besser: createRefundDraft(orderId, reasonCode), ohne Auszahlung und mit serverseitigem Mandanten- und Statuscheck.
04
Human in the loop schützt nur mit einer vertrauenswürdigen Freigabe
Eine Bestätigung ist kein Sicherheitszauber. Wenn der Agent den Inhalt des Dialogs selbst formuliert oder nach der Freigabe andere Parameter ausführen kann, bestätigt der Mensch möglicherweise nicht die tatsächliche Aktion.
Konkrete Wirkung anzeigen
Ziel, Empfänger, Betrag, betroffene Datensätze und irreversible Folgen aus den validierten Werkzeugparametern darstellen.
Untrusted Content trennen
Text aus E-Mail, Webseite oder Dokument sichtbar als fremden Inhalt markieren; er darf nicht wie eine Systemwarnung aussehen.
Payload binden
Die Freigabe gilt für einen Hash oder eine unveränderliche Aktions-ID. Jede Parameteränderung erfordert eine neue Freigabe.
Risikobasiert staffeln
Lesen, Entwurf, interne Änderung, externe Kommunikation, Zahlung und Löschung brauchen unterschiedliche Schwellen.
Vier-Augen-Prinzip dort, wo es zählt
Hohe Beträge, Massenänderungen oder sensible Exporte können eine zweite Rolle verlangen.
Zeitlich begrenzen
Freigaben laufen ab und dürfen nicht für andere Aufträge, Mandanten oder spätere Wiederholungen wiederverwendet werden.
Antimuster: „Der Agent möchte fortfahren. Zulassen?“, ohne konkrete Aktion, Datenquelle und Auswirkung.
05
Agenten brauchen eigene Identitäten, keine geliehenen Generalschlüssel
Ein Agent sollte weder das persönliche Dauer-Token eines Administrators noch einen globalen API-Schlüssel erben. Eigene technische Identitäten machen Scope, Widerruf und Nachvollziehbarkeit möglich.
Pro Agent und Umgebung trennen
Entwicklung, Test und Produktion sowie verschiedene Agenten erhalten getrennte Clients oder Service-Identitäten.
Kurzlebige Tokens
Zugriffstokens möglichst kurz halten, sicher speichern, nicht in Prompts, Logs oder Fehlermeldungen einbetten.
Audience prüfen
Ein Token muss für den angesprochenen Dienst ausgestellt sein. MCP verlangt bei unterstützter Autorisierung eine Bindung und Prüfung der Zielressource.
Kein Token Passthrough
Ein MCP-Server reicht empfangene Client-Tokens nicht einfach an nachgelagerte APIs weiter. Er verwendet einen dafür vorgesehenen eigenen Autorisierungsfluss.
Nutzer- und Agentenhandlung unterscheiden
Auditdaten halten fest, welcher Nutzer den Auftrag gab, welche Agentenidentität handelte und welcher Dienst die Aktion ausführte.
Zugriff widerrufbar machen
Ein kompromittierter Agent oder MCP-Server muss gezielt abgeschaltet werden können, ohne die gesamte Plattform stillzulegen.
MCP standardisiert, wie Kontext und Werkzeuge angeboten werden. Es macht ein Werkzeug nicht automatisch vertrauenswürdig. Betreiber müssen Serverquelle, Toolbeschreibung, Berechtigungen, Tokenfluss und Änderungen weiterhin prüfen.
06
Gedächtnis und Datenzugriff brauchen dieselbe Trennung wie jede andere Datenbank
Persistente Erinnerung macht Agenten nützlicher, aber auch angreifbarer. Falsche oder bösartige Einträge können viele spätere Läufe beeinflussen und über Mandanten- oder Projektgrenzen wandern.
Scope am Schreibpunkt
Jeder Memory-Eintrag trägt Organisation, Projekt, Nutzer, Quelle, Zweck und Ablaufdatum aus vertrauenswürdiger Anwendungsschicht.
Provenienz erhalten
Speichern, ob ein Fakt aus einem System of Record, einem Nutzertext, einer Modellableitung oder fremdem Inhalt stammt.
Keine Geheimnisse als Erinnerung
Passwörter, Tokens und private Schlüssel gehören in Secret Stores, nicht in Vektordatenbanken oder Chatverläufe.
Löschung und Korrektur
Einträge müssen auffindbar, korrigierbar und im Rahmen der geltenden Regeln löschbar sein.
Retrieval begrenzen
Die Suche filtert zuerst technisch nach Scope und Berechtigung; semantische Ähnlichkeit darf keine Zugriffskontrolle ersetzen.
Modellableitungen veralten
Zusammenfassungen und Präferenzen brauchen Aktualitätsregeln und dürfen nicht als unveränderliche Wahrheit gelten.
07
Ohne Belege ist ein Agent im Betrieb nur schwer steuerbar
Ein vollständiger Prompt-Mitschnitt ist weder immer zulässig noch ausreichend. Gute Beobachtbarkeit verbindet fachliche Ereignisse mit technischen Entscheidungen und minimiert gleichzeitig unnötige Inhaltsprotokollierung.
Korrelation
Auftrag, Modellaufrufe, Tool-Calls, Freigaben und Ergebnis erhalten eine gemeinsame Run-ID.
Strukturierte Tool-Logs
Werkzeugname, validierte Parameterklasse, Actor, Scope, Ergebnis, Dauer und Fehlercode protokollieren; sensible Werte maskieren.
Entscheidungsbelege
Policy-Entscheidungen, Freigabe-ID, Modell- und Promptversion sowie genutzte Datenquellen nachvollziehbar halten.
Limits
Maximale Schritte, Laufzeit, Kosten, Datenmenge, Empfänger und Wiederholungen pro Auftrag begrenzen.
Abbruch und Rückweg
Laufende Agenten stoppen, Tokens widerrufen, Jobs sperren und reversible Aktionen zurückrollen können.
Evals und Angriffstests
Erfolgsfälle, Fehlbedienung, indirekte Injection, manipulierte Tools, Scope-Wechsel und unvollständige Daten vor Releases testen.
Die wichtigste Produktionsmetrik ist nicht, wie viele Schritte der Agent autonom erledigt. Wichtiger sind korrekte Ergebnisse, verhinderte Regelverstöße, notwendige Eingriffe und sauber abgebrochene Läufe.
08
Die Leiter kontrollierter Autonomie
Autonomie sollte eine fachliche Entscheidung pro Aktionstyp sein, keine globale Eigenschaft des Agenten. Ein System kann Rechnungen selbständig lesen, Antworten entwerfen und Auszahlungen trotzdem niemals ohne Freigabe ausführen.
| Stufe | Was der Agent darf | Geeignet für |
|---|---|---|
| 1 · Beobachten | Nur lesen, klassifizieren und Quellen zeigen. | Suche, Analyse, Zusammenfassung. |
| 2 · Vorbereiten | Entwürfe und strukturierte Aktionsvorschläge erstellen. | E-Mail-Entwurf, Ticket-Vorschlag, Änderungsplan. |
| 3 · Nach Freigabe handeln | Eine exakt gebundene Aktion nach informierter Bestätigung ausführen. | Externe Nachricht, Statuswechsel, begrenzte Buchung. |
| 4 · Begrenzt autonom | Nur vorab definierte, reversible und überwachte Aktionen innerhalb harter Limits. | Klassifizierung, Routing, ungefährliche Standardkorrekturen. |
Eine Stufe wird erst erweitert, wenn Messdaten zeigen, dass Aufgabenqualität, Ablehnungen, Fehlermodi, Abbruch und Wiederherstellung beherrscht werden. Eine bessere Modellversion allein ist kein Freigabekriterium.
09
Die 12-Punkte-Produktionscheckliste
Vor dem ersten schreibenden Zugriff sollten diese Fragen nicht mit „das steht im Prompt“ beantwortet werden.
- Geschäftszweck, erlaubte Aktionen und ausdrücklich verbotene Aktionen dokumentieren.
- Datenquellen nach Vertrauen und Sensitivität klassifizieren.
- Externe Inhalte technisch von Steuerinstruktionen trennen.
- Schmale, typisierte Werkzeuge statt universeller Schnittstellen anbieten.
- Mandant, Nutzer und Ressourcenscope serverseitig bestimmen.
- Eigene kurzlebige Agentenidentitäten und Tokens verwenden.
- Schreibende, externe und irreversible Aktionen risikobasiert freigeben.
- Freigaben kryptografisch oder über unveränderliche IDs an die konkrete Payload binden.
- Memory mit Scope, Quelle, Zweck, Ablauf und Löschweg versehen.
- Run-IDs, Tool-Aktionen, Policy-Entscheidungen und Ergebnisse auditierbar machen.
- Schritt-, Zeit-, Kosten-, Mengen- und Empfängerlimits festlegen.
- Prompt-Injection-, Tool-Manipulations-, Scope- und Recovery-Tests vor Produktivsetzung bestehen.
10
Häufige Fragen
Reicht ein guter Systemprompt als Schutz?
Nein. Ein Systemprompt kann Verhalten lenken, aber keine verlässliche Zugriffskontrolle, Parametervalidierung oder Transaktionsgrenze ersetzen. Sicherheit muss außerhalb des Modells durchgesetzt werden.
Soll jeder Tool-Aufruf von einem Menschen bestätigt werden?
Nein. Das erzeugt Freigabemüdigkeit und macht harmlose Abläufe unnötig langsam. Bestätigungen sollten nach Wirkung gestaffelt werden. Lesen oder reversible Standardaktionen können anders behandelt werden als Zahlungen, Exporte oder Löschungen.
Ist ein lokales Modell automatisch sicherer?
Lokale Verarbeitung kann Datenabfluss an externe Modellanbieter reduzieren. Sie löst aber keine Prompt Injection, überbreiten Berechtigungen, unsicheren Tools oder fehlerhaften Freigaben.
Macht MCP einen Agenten sicher?
MCP schafft ein einheitliches Protokoll für Kontext und Werkzeuge. Sicherheit hängt weiterhin von Serververtrauen, Autorisierung, Tokenprüfung, Tool-Scope, Eingabevalidierung und Betrieb ab.
Braucht ein interner Agent dieselben Kontrollen?
Interne Systeme enthalten oft besonders sensible Daten und weitreichende Berechtigungen. Das Publikum ist kleiner, das mögliche Schadensausmaß aber nicht automatisch geringer.
Wie startet man sinnvoll?
Mit einem engen, messbaren Prozess auf Stufe 1 oder 2: lesen, Quellen zeigen und einen Entwurf erzeugen. Erst nach Tests und realen Messdaten werden einzelne Aktionen kontrolliert freigegeben.
Welche Rolle spielt der EU AI Act?
Unabhängig von der Risikoklasse gilt für beruflich eingesetzte KI seit Februar 2025 die Pflicht, Maßnahmen für angemessene KI-Kompetenz zu treffen. Je nach Einsatz können weitere AI-Act-Pflichten hinzukommen; dieser Artikel behandelt primär technische Sicherheit.
11
Quellen und technische Grundlagen
Originäre Standards, Frameworks und offizielle Hinweise für diesen Beitrag. Zuletzt geprüft am 15. August 2026.