Security by Design für KI-Agenten: sichere Agentenentwicklung von Anfang an

Kurzantwort: was Security by Design bei KI-Agenten bedeutet

Security by Design bei KI-Agenten bedeutet, Sicherheitsentscheidungen zusammen mit den Architekturentscheidungen des Agenten zu treffen — beim Entwurf, nicht nach der Inbetriebnahme. Die Frage „welche Werkzeuge bekommt dieser Agent“ und die Frage „was ist das Schlimmste, das er tut, wenn er getäuscht wird“ werden im selben Gespräch, vom selben Team, zum selben Zeitpunkt im Prozess beantwortet. Das ist keine Checkliste, die einem fertigen Produkt aufgesetzt wird, sondern eine Eigenschaft der Architektur selbst: Werkzeugumfang, Ausführungsumgebung, Vertrauensgrenzen gegenüber Daten und Freigabepunkte für den Menschen sind Teil des Agentenentwurfs — genauso wie sein System-Prompt oder die Wahl des Modells.

Der Unterschied zur „nachträglichen Prüfung“ ist praktisch, nicht ideologisch. Eine Prüfung untersucht ein fertiges System und findet, was bereits falsch gebaut wurde — und eine Architektur nachträglich zu korrigieren ist teuer, weil sie Fundamente betrifft, die sich ohne Umbau kaum verschieben lassen. Sichere Agentenentwicklung trifft dieselben Entscheidungen früher, wenn eine Änderung nur die Wahl eines anderen Entwurfsmusters auf dem Whiteboard kostet und keine Refaktorierung eines laufenden Produktivsystems. Es ist derselbe Weg, den die Softwarebranche schon einmal mit „Shift Left“ beim Testen und mit Privacy by Design im Datenschutz gegangen ist — die Sicherheit von KI-Agenten geht diesen Weg jetzt ebenfalls.

Dieser Artikel beschreibt keine einzelne Schutztechnik. Er ist ein Rahmen, der zeigt, an welcher Stelle im Entwicklungsprozess eines Agenten jede Entscheidung fällt, die einem konkreten Risiko aus den OWASP Top 10 für agentische Anwendungen entspricht — und verweist auf die Beiträge, die jede dieser Techniken im Detail behandeln. Wer Details zu einem einzelnen Schutzmechanismus sucht, findet im Text den passenden Verweis. Wer die Antwort auf die Frage „wann denke ich überhaupt daran“ sucht, ist hier richtig.

Warum eine nachträgliche Prüfung immer zu spät kommt

Das typische Szenario sieht so aus: Ein Team baut einen Agenten mit Fokus auf Funktion — er soll Dokumente zusammenfassen, Tickets bearbeiten, interne Systeme abfragen. Sicherheit taucht erst am Ende auf, als Punkt auf der Liste vor dem Livegang: „Machen wir noch eine Sicherheitsprüfung.“ Zu diesem Zeitpunkt hat der Agent bereits weitreichende Berechtigungen, weil niemand sie bewusst eingeschränkt hat — Werkzeuge wurden einfach hinzugefügt, sobald ein funktionaler Bedarf entstand. Er hat bereits Zugriff auf sensible Daten, weil das beim Bau bequem war. Er führt generierten Code auf derselben Maschine aus wie der Rest des Dienstes, weil das in der Prototypphase schneller ging.

Eine Sicherheitsprüfung an dieser Stelle findet Dutzende Probleme — und jedes davon verlangt den Umbau von etwas, das bereits funktioniert. Die Rechte eines Werkzeugs einzuschränken bedeutet, eine Integration neu zu schreiben. Die Codeausführung in eine isolierte Umgebung zu verlagern bedeutet, die Infrastruktur zu ändern. Eine menschliche Freigabe für irreversible Aktionen einzuführen bedeutet, einen Ablauf neu zu gestalten, an den sich Nutzer in der Testversion bereits gewöhnt haben. Nichts davon ist unmöglich — aber alles davon ist teurer, als wenn diese Entscheidungen drei Wochen früher gefallen wären, bevor jemand auch nur eine einzige Integration geschrieben hat.

Die schlechtere Variante dieses Szenarios überspringt die Sicherheitsprüfung ganz und landet direkt bei einem Vorfall. Analysen realer Sicherheitsvorfälle bei KI-Agenten zeigen dasselbe Muster mit auffallender Regelmäßigkeit: Ein Agent mit weiteren Rechten, als die Aufgabe erforderte, verarbeitete Inhalte, die er nicht als Anweisung hätte behandeln dürfen, und führte eine Aktion aus, die sich nicht zurücknehmen ließ. Keiner dieser Vorfälle entstand, weil jemand bewusst ein Risiko akzeptiert hätte. Sie entstanden, weil niemand rechtzeitig die Frage gestellt hat, die sichere Agentenentwicklung von Anfang an stellt: Was ist das Schlimmste, das dieser Agent tut, wenn er durch Inhalte getäuscht wird, die er liest?

Diese Frage ist in der Entwurfsphase billig zu stellen und im Nachhinein teuer. Der restliche Artikel ist ein einziger Gedanke, konsequent durchgespielt: Stellen Sie die Frage früh, bei jeder Architekturentscheidung — nicht einmal, am Ende, in Form einer Prüfung.

Was Agentenentwicklung ist und wo Sicherheit darin sitzt

Agentenentwicklung ist die Disziplin, KI-Agenten so zu entwerfen, zu bauen und zu betreiben, dass sie im Produktivbetrieb zuverlässig funktionieren — nicht ein einzelner Prompt oder eine einzelne Modellintegration, sondern der gesamte Lebenszyklus eines Systems, das ein Ziel eigenständig verfolgt: Werkzeuge aufruft, Kontext verarbeitet und weitere Schritte unternimmt, ohne dass ein Mensch jeden einzelnen davon freigibt. In der Praxis umfasst sie Ebenen, die sich beim Entwurf ständig überschneiden: Auswahl und Konstruktion von Werkzeugen, Kontext- und Gedächtnisverwaltung, die Ausführungsebene, die Aktionen tatsächlich anstößt, sowie Evaluierung und Beobachtbarkeit.

In diesem Gefüge ist Sicherheit keine separate Ebene neben den anderen. Sie ist ein Kriterium, das in jeder von ihnen steckt. Die Entscheidung, welche Werkzeuge ein Agent bekommt, ist gleichzeitig eine funktionale Entscheidung (was der Agent leisten kann) und eine Sicherheitsentscheidung (was er im schlimmsten Fall anrichtet, wenn er getäuscht wird). Die Entscheidung über die Gedächtnisarchitektur ist gleichzeitig eine Entscheidung darüber, wie gut sich der Agent an den Aufgabenkontext erinnert, und eine Entscheidung darüber, ob sich dieses Gedächtnis mit einem bösartigen Eintrag vergiften lässt, der spätere Entscheidungen beeinflusst. Diese beiden Fragen zu trennen — „das Produktteam entscheidet über die Funktion“, „das Sicherheitsteam macht am Ende eine Prüfung“ — ist genau die Ursache des oben beschriebenen Problems: Es behandelt als zwei getrennte Entscheidungen, was von Anfang an eine einzige war.

Eine Klarstellung an dieser Stelle: Sichere Agentenentwicklung ersetzt keine Sicherheitstests oder Prüfungen vor dem Livegang. Red-Teaming und systematische Evaluierung bleiben ein notwendiger Teil des Prozesses — nur ändert sich ihre Rolle. Statt Probleme zu finden, die jetzt teuer korrigiert werden müssen, überprüfen sie, ob früher getroffene Entscheidungen unter realen Bedingungen tatsächlich standhalten. Das ist der Unterschied zwischen einem Test, der einen Entwurfsfehler findet, und einem Test, der bestätigt, dass ein Entwurf hält.

Sechs Punkte im Prozess, an denen sich der Ausgang eines Angriffs entscheidet

Im Folgenden zerlege ich den Prozess der Agentenentwicklung in sechs Entscheidungspunkte, an denen die Architektur den Schadensradius eines künftigen Angriffs entweder eingrenzt oder erweitert — meist unbeabsichtigt, weil in dem Moment niemand daran gedacht hat. Jeder Punkt entspricht einer konkreten Risikoklasse aus den OWASP Top 10 für agentische Anwendungen (ASI01–ASI10) und verweist auf den Beitrag, der die passende Schutztechnik im Detail behandelt.

Punkt im Prozess	Die zu stellende Frage	Zugehöriges ASI-Risiko	Wo es vertieft wird
Definition von Ziel und Umfang	Was genau soll der Agent tun — und was ausdrücklich nicht?	ASI01 (Agent Goal Hijack)	weiter unten in diesem Artikel
Auswahl und Umfang der Werkzeuge	Welche Werkzeuge braucht diese Aufgabe wirklich, nicht „für alle Fälle“?	ASI02, ASI03	Agenten-Tools mit minimalen Rechten
Herkunft von Werkzeugen und Daten	Woher stammt jede Komponente, auf die sich der Agent verlässt — und hat das jemand geprüft?	ASI04 (Lieferkette)	Vertrauensgrenzen bei bösartigen MCP-Servern
Ausführungsumgebung	Wo läuft physisch das, was der Agent generiert oder abruft?	ASI05 (unerwartete Codeausführung)	Agenten-Tool-Sandboxing und Isolation
Ein-/Ausgabegrenze	Was wird gefiltert, bevor es das Modell erreicht, und was, bevor die Ausgabe des Modells ausgeführt wird?	ASI01, ASI06	Guardrails: Ein- und Ausgabefilterung
Freigabe- und Aufsichtspunkte	Welche Aktionen sind irreversibel — und wer gibt sie frei, bevor sie ausgeführt werden?	ASI08, ASI09, ASI10	Defense-in-Depth: das Gesamtmodell

Im Folgenden wird jeder dieser Punkte vertieft — nicht als separate Technik, die man am Ende anflanscht, sondern als Frage, die an einem bestimmten Moment des Prozesses gestellt werden sollte, bevor die nächste Zeile Code entsteht.

Ziel- und Umfangsdefinition: wo ASI01 beginnt

Die erste Entscheidung, die jedes Team beim Bau eines Agenten trifft, lautet: Was soll er tun? Eine zweite, ebenso wichtige Frage wird deutlich seltener gestellt: Was soll er ausdrücklich nicht tun, selbst wenn er es technisch könnte? Diese Frage wirkt offensichtlich, geht in der Praxis aber oft unter, weil Teams einen Agenten über das definieren, was er leisten kann, nicht über die Grenzen dessen, was er tun darf.

Diese Lücke hat in der Risikotaxonomie einen Namen: ASI01, Agent Goal Hijack. Ein Agent, dessen Aufgabenbereich beim Start nie klar abgegrenzt wurde, ist anfällig für eine Situation, in der ihm externer Inhalt — ein Dokument, eine E-Mail, ein Suchergebnis — ein neues „Ziel“ unterschiebt, ohne dass er über ein eingebautes Kriterium verfügt, dieses von der ursprünglichen Aufgabe zu unterscheiden. Wurde der Umfang nie präzise festgehalten, fehlt auch der Maßstab, an dem sich eine Abweichung überhaupt erkennen ließe.

Die praktische Konsequenz für den Entwurf: Bevor irgendeine Entscheidung über Werkzeuge oder Architektur fällt, sollten Sie den Aufgabenbereich des Agenten in einer Form festhalten, die sich im Code durchsetzen lässt, nicht nur in der Dokumentation beschreiben. „Dieser Agent fasst eingehende Dokumente zusammen und initiiert keinerlei ausgehende Kommunikation“ ist ein Aufgabenbereich, der sich in das Fehlen eines Werkzeugs zum Versenden von Nachrichten übersetzen lässt. „Dieser Agent unterstützt den Kundenservice“ tut das nicht — weil er nicht sagt, was dem Agenten nicht erlaubt ist.

Auswahl und Umfang der Werkzeuge: wo ASI02 und ASI03 entweder eine Chance bekommen oder nicht

Das ist die wichtigste Einzelentscheidung im gesamten Prozess, weil sie bestimmt, wie viel überhaupt zu verlieren ist, wenn die vorherige Ebene versagt. Die Regel ist einfach zu formulieren und schwer konsequent einzuhalten: Ein Agent erhält ausschließlich die Werkzeuge, die seine aktuelle Aufgabe erfordert, und nichts „für alle Fälle“. Jedes Werkzeug über diesen Umfang hinaus ist kostenlos übergebene Angriffsfläche — denn wenn ein Agent sich irgendwann täuschen lässt (und früher oder später wird er das), entscheidet genau der Werkzeugumfang darüber, wie schwerwiegend die Folgen sind.

Das ist keine Checkliste, die man am Ende durchgeht. Es ist eine Frage, die bei jedem neuen Werkzeug während des Entwurfs gestellt wird: Was ist das Schlimmste, das dieser Agent mit diesem Werkzeug anrichtet, wenn es unter dem Einfluss einer eingeschleusten Anweisung eingesetzt wird? Lautet die Antwort „nichts Ernstes“ — bleibt das Werkzeug. Lautet sie „es überweist Geld“ oder „es löscht Produktivdaten“ — braucht das Werkzeug eine zusätzliche Freigabe, bevor es überhaupt in den Werkzeugsatz aufgenommen wird.

Das vollständige Instrumentarium — Capability Scoping, Berechtigungs-Gating außerhalb des Modells, dynamische Werkzeugauswahl je nach Aufgabenschritt und Human-in-the-Loop für irreversible Aktionen — wird gesondert im Beitrag zu Agenten-Tools mit minimalen Rechten behandelt. Es ist der direkte Schutz gegen ASI02 (Werkzeugmissbrauch) und ASI03 (Missbrauch von Identität und Rechten) — und architektonisch eine Entscheidung, die von Anfang an günstiger ist als später, denn einen bereits produktiv laufenden Werkzeugsatz einzuschränken bedeutet, Integrationen umzuschreiben, die schon jemand nutzt.

Herkunft von Werkzeugen und Daten: wo ASI04 zu Hause ist

Ein Agent besteht selten ausschließlich aus eigenem Code. Er verlässt sich auf Bibliotheken, Plugins, Werkzeugregister und MCP-Server (Model Context Protocol), die ihm externe Fähigkeiten bereitstellen. Jede dieser Komponenten ist ein Bestandteil, dessen Integrität das entwickelnde Team nicht direkt kontrolliert — und die Entscheidung, sie überhaupt anzubinden, fällt meist in fünf Minuten, weil „dieser Server genau das tut, was wir brauchen“.

Genau in diesem Moment entscheidet sich ASI04 — Schwachstellen in der agentischen Lieferkette. Ein MCP-Server, der ohne Herkunftsprüfung angebunden wird, läuft mit den Rechten des Agenten und bestimmt dessen Werkzeugverhalten; eine untergeschobene oder kompromittierte Komponente beeinflusst den Agenten mit derselben Wirkung, als hätte jemand seinen Quellcode verändert — nur dass niemand diesen Code geprüft hat. Der Beitrag zu Vertrauensgrenzen bei bösartigen MCP-Servern beschreibt genau, wie sich untergeschobene Server einschleichen und wie man sie verifiziert, fixiert und isoliert.

Die Entwurfsentscheidung, die sich von Anfang an lohnt und nicht erst nach einem Vorfall: eine Positivliste vertrauenswürdiger Quellen für Werkzeuge und Komponenten, auf die der Agent zurückgreifen darf, plus die Regel, dass nichts außerhalb dieser Liste ohne bewusste Prüfung aufgenommen wird. Genau diesen Mechanismus zitiert OWASP beim dokumentierten Missbrauch der GitHub-Integration über MCP — das Vertrauen in einen fertigen Konnektor erwies sich als schwaches Glied, weil niemand zuvor gefragt hatte, welche Rechte dieser Konnektor tatsächlich erhält.

Ausführungsumgebung: wo sich ASI05 entscheidet

Wenn ein Agent Code generiert oder abruft und ausführt, ist die Frage „wo geschieht das physisch“ eine der folgenreichsten Architekturentscheidungen — und eine der am häufigsten aufgeschobenen, weil in der Prototypphase „läuft auf derselben Maschine“ schlicht schneller geht. Das Problem: Die Codeausführung nachträglich in eine isolierte Umgebung zu verlagern, erfordert eine Infrastrukturänderung, die deutlich günstiger von Anfang an eingeplant wird.

Hier entscheidet sich ASI05 — unerwartete Codeausführung. Die Ausführung von beliebigem, bösartigem oder schlicht fehlerhaftem Code umgeht jede höhere Sicherheitslogik: Ein Angreifer muss das Modell dann von nichts mehr überzeugen, weil bereits laufender Code einfach tut, was er tut. Der Leitfaden zu Agenten-Tool-Sandboxing und Isolation stellt die verfügbaren Isolationsprimitive gegenüber — vom Container mit geteiltem Kernel bis zur MicroVM — und zeigt, wann welches davon die richtige Wahl ist. Die zentrale Entwurfsentscheidung: nicht vertrauenswürdiger, vom Agenten generierter Code landet niemals auf derselben Maschine wie der Rest des Systems, egal wie viel schneller das die erste Version machen würde.

Die Ein-/Ausgabegrenze: wo ASI01 und ASI06 auf Filterung treffen

Jeder Inhalt, den ein Agent von außen bezieht — eine Seite, ein Dokument, das Ergebnis eines Werkzeugaufrufs —, und jede Antwort, die er vor ihrer Ausführung generiert, durchläuft einen Kontrollpunkt, oder eben nicht. Ob dieser Punkt überhaupt existiert, entscheidet sich beim Entwurf des Datenflusses durch den Agenten, nicht bei einer Sicherheitsprüfung.

Ein- und Ausgabefilterung ist die erste Verteidigungslinie gegen ASI01 (Goal Hijack) auf Inhaltsebene sowie gegen ASI06 (Gedächtnis- und Kontextvergiftung) — sofern Inhalte, die ins Langzeitgedächtnis gelangen, dieselbe Prüfung durchlaufen wie Inhalte, die in den aktuellen Kontext gelangen. Der Guardrails-Beitrag beschreibt die Mechanik: Kennzeichnung nicht vertrauenswürdiger Inhalte, Prüfung der Eingabe auf bekannte Muster und Kontrolle der Modellausgabe, bevor sie ausgeführt wird. Ein wichtiger architektonischer Vorbehalt: Das ist eine erste Siebschicht, keine letzte Verteidigungslinie — und ein System so zu entwerfen, als würden Guardrails allein genügen, ist ein Fehler, auf den ich im nächsten Abschnitt zurückkomme.

Freigabe- und Aufsichtspunkte: wo ASI08, ASI09 und ASI10 zu Hause sind

Der letzte Entscheidungspunkt betrifft das, was passiert, wenn alle vorherigen Ebenen gleichzeitig versagen. Welche Aktionen eines Agenten sind so schwerwiegend, dass sie eine ausdrückliche menschliche Freigabe brauchen, bevor sie ausgeführt werden? Welche Signale sollten die gesamte Pipeline stoppen, bevor sich ein Fehler weiter ausbreitet? Wer — und wie — kann einen Agenten abschalten, wenn er beginnt, sich außerhalb des erwarteten Musters zu verhalten?

Diese Fragen beantworten drei verwandte Risiken der ASI-Liste: kaskadierende Ausfälle (ASI08), Missbrauch des Vertrauens zwischen Mensch und Agent (ASI09) sowie außer Kontrolle geratene Agenten (ASI10). Der gemeinsame Nenner: Keine einzelne Schutzschicht hält für immer, daher braucht die Architektur einen Punkt, an dem ein Mensch oder ein Aufsichtsmechanismus die Kontrolle übernimmt, bevor die Folge irreversibel wird. Genau das entwickelt Defense-in-Depth für autonome KI-Agenten als zusammenhängendes Modell — fünf Verteidigungsschichten, so angeordnet, dass eine Lücke in einer davon nicht das gesamte System zu Fall bringt.

Was reale Vorfälle bestätigen: Ausfall eines konkreten Punkts, nicht der gesamten Architektur

Die sechs Punkte oben sind kein theoretisches Raster — jeder dokumentierte Vorfall bei KI-Agenten lässt sich einem konkreten Prozesspunkt zuordnen, an dem eine Entscheidung falsch fiel oder gar nicht getroffen wurde.

EchoLeak (CVE-2025-32711, von Forschern bei Aim Security verantwortungsvoll gemeldet und im Juni 2025 öffentlich detailliert beschrieben; Microsoft hatte die Lücke bereits im Mai 2025 serverseitig geschlossen, noch vor der öffentlichen Bekanntgabe) ist ein Ausfall genau des fünften Punkts: der Ein-/Ausgabegrenze. Der Inhalt einer vom Angreifer präparierten E-Mail landete im selben Kontext, in dem Copilot die sensiblen Daten des Nutzers verarbeitete, und der Ausgabemechanismus erlaubte ein automatisch geladenes Bild, dessen URL die ausgeleiteten Daten transportierte. Keine einzelne Kontrolle wurde versehentlich übersprungen — die Architektur besaß schlicht keinen Punkt, der nicht vertrauenswürdige Inhalte sauber von privilegiertem Kontext trennte und kontrollierte, wohin die Ausgabe des Modells gelangen konnte. Die vollständige Analyse dieses und zweier weiterer Vorfälle finden Sie separat im Beitrag zur Breach-Analyse realer KI-Agenten-Vorfälle.

Der von Invariant Labs im Mai 2025 dokumentierte GitHub-MCP-Vorfall ist dagegen ein Ausfall des dritten Punkts: der Herkunfts- und Umfangsprüfung von Komponenten. Der in den Agenten eingebundene Zugriffstoken umfasste weit mehr Repositories, als die Aufgabe erforderte — und ob dieser Umfang überhaupt nötig war, ist eine Frage, die beim Anbinden der Integration hätte gestellt werden müssen, nicht erst, nachdem jemand ihren Missbrauch nachgewiesen hatte.

Die TeamPCP-/LiteLLM-Kampagne vom März 2026, die ein weitverbreitetes KI-Gateway-Proxy kompromittierte und Zugangsdaten über viele Systeme hinweg abgriff, zeigt dasselbe Muster eine Ebene höher: Je stärker sich die verbindende Infrastruktur des Agenten-Stacks — Gateways, Werkzeugregister, MCP-Server — konsolidiert, desto mehr lohnt sich für einen Angreifer eine einzige Kompromittierung gegenüber vielen Opfern zugleich. Genau davor schützt die Positivliste vertrauenswürdiger Komponentenquellen aus dem dritten Punkt — nur reicht der Schadensradius hier über die gesamte verbundene Agentenlandschaft einer Organisation, nicht über einen einzelnen Agenten.

Der gemeinsame Nenner aller drei Fälle: Keiner erforderte ein „böses Modell“ oder einen raffinierten Exploit. Jeder erforderte eine übersprungene Entscheidung, früh im Prozess — eine Entscheidung, die zum Entwurfszeitpunkt eine einzige Frage in einer Architekturbesprechung gekostet hätte und nach dem Vorfall deutlich mehr kostete.

Wie mehrschichtige Verteidigung aussieht, wenn sie Teil des Prozesses ist, kein Zusatz

Die folgende Darstellung zeigt einen vereinfachten Querschnitt dieser Schichten in dem Moment, in dem ein realer Angriff versucht, von einem Eingabeinhalt bis zu einer privilegierten Aktion vorzudringen. Das ist keine Checkliste, die nach dem Livegang abgehakt wird — es ist die Form, die sich aus den Entscheidungen der vorherigen Abschnitte ergibt: Werkzeugumfang (Eingabefilter und Rechte), Ausführungsumgebung (Isolation) und Freigabepunkte (menschliche Freigabe).

Beachten Sie die Reihenfolge, in der diese Schichten im Entwicklungsprozess entstehen — sie ist nicht zufällig. Eingabefilter und Rechteumfang werden gemeinsam entschieden, bei der Werkzeugauswahl. Die Isolation entscheidet sich beim Entwurf der Ausführungsumgebung. Die menschliche Freigabe entscheidet sich bei der Kartierung irreversibler Aktionen. Keine dieser Entscheidungen wartet darauf, dass jemand das fertige System einem Penetrationstest unterzieht — bis dahin sind sie längst Teil der Architektur.

Warum die Reihenfolge der Entscheidungen zählt, nicht nur ihr Vorhandensein

Teams, die Sicherheit nachträglich in einen bereits gebauten Agenten einbauen wollen, greifen oft zuerst zu Guardrails — weil das die einfachste Schicht ist, die sich hinzufügen lässt, ohne die Architektur anzufassen: ein paar Regeln im System-Prompt, vielleicht ein Sicherheitsklassifikator. Ein verständlicher Reflex, aber die umgekehrte Reihenfolge dessen, was Schaden tatsächlich begrenzt.

Guardrails sind eine Kontrolle auf Sprachebene, die auf derselben Ebene wirkt wie der Inhalt, den sie filtern soll — eine Regel im System-Prompt ist Text im selben Kontext, in dem eine eingeschleuste Anweisung landet, und das Modell gewichtet beide auf seine eigene Weise. Ein hinreichend geschickt formulierter Angriff kann diese Regel überwinden. Die Einschränkung des Werkzeugsatzes funktioniert anders: Ein Werkzeug, das der Agent nicht besitzt, lässt sich durch keine Formulierung missbrauchen, weil die Entscheidung außerhalb der Reichweite des Modells getroffen wurde, im Code, auf den eingeschleuster Inhalt keinen Zugriff hat.

Daraus ergibt sich die praktische Prioritätenreihenfolge beim Entwurf (und bei der Nachbesserung) der Agentensicherheit: zuerst Werkzeug- und Rechteumfang, weil das bei geringstem Aufwand die größte Wirkung erzielt und den Schaden begrenzt, bevor überhaupt etwas schiefgeht. Danach die Ausführungsumgebung, sofern der Agent Code ausführt. Danach Freigabepunkte für irreversible Aktionen. Guardrails und Inhaltsfilterung stehen am Ende dieser Prioritätenliste — nicht, weil sie überflüssig wären, sondern weil sie als rauschfilternde Schicht erst dann sinnvoll sind, wenn darunter bereits ein solides Fundament steht: enge Rechte, Isolation und klar definierte Aufsichtspunkte. Dieselbe Reihenfolgenlogik zieht sich durch das vollständige Defense-in-Depth-Modell — hier zeige ich nur, dass sie sich unmittelbar daraus ergibt, wann im Entwicklungsprozess eines Agenten jede dieser Entscheidungen tatsächlich fällt.

Überprüfung als Teil des Prozesses, kein einmaliger Test

Sichere Agentenentwicklung endet nicht mit dem Architekturentwurf. Entscheidungen aus früheren Phasen müssen überprüft werden — nicht einmal, vor dem ersten Livegang, sondern wiederkehrend, denn der Werkzeugsatz eines Agenten wächst mit dem Produkt, und jedes neue Werkzeug ist neue Angriffsfläche, die jemand bewusst bewerten musste.

Hier fügt sich Red-Teaming und systematische Evaluierung als fester Bestandteil in den Entwicklungsprozess ein, nicht als einmalige Prüfung vor dem Livegang. Offensive Werkzeuge — darunter Garak, PyRIT oder Promptfoo — automatisieren die Überprüfung, ob Entscheidungen zu Rechteumfang und Isolation unter einem koordinierten Angriff tatsächlich standhalten, nicht nur auf dem Papier. Das praktische Muster: Jede Änderung am Werkzeugsatz eines Agenten oder an seinen Rechtegrenzen löst dieselbe Reihe offensiver Tests aus, die die ursprüngliche Version durchlaufen hat — genau wie eine Codeänderung Unit-Tests auslöst. Sicherheit hört auf, ein Punkt auf der Zeitachse zu sein, und wird zu einer Schranke in der Pipeline, die jede weitere Version passieren muss.

Eine Übersicht: wo jedes ASI-Risiko im Lebenszyklus des Agenten ansetzt

Zusammengefasst ergibt sich folgendes Bild — keine Liste von Techniken in beliebiger Reihenfolge, sondern eine Übersicht der Entscheidungspunkte im Entwicklungsprozess eines Agenten, von denen jeder für eine bestimmte Risikoklasse verantwortlich ist.

1. Ziel- und Umfangsdefinition — ein schriftlich festgehaltener, im Code durchsetzbarer Aufgabenbereich. Verhindert ASI01 an der Wurzel, bevor überhaupt ein Werkzeug existiert.
2. Werkzeugauswahl — Capability Scoping, Berechtigungs-Gating außerhalb des Modells, menschliche Freigabe für irreversible Aktionen. Direkter Schutz gegen ASI02 und ASI03.
3. Prüfung der Komponentenherkunft — eine Positivliste vertrauenswürdiger Quellen für Werkzeuge und MCP-Server, fixierte Versionen. Schutz gegen ASI04.
4. Entwurf der Ausführungsumgebung — Isolation für Code, den der Agent generiert oder abruft. Schutz gegen ASI05.
5. Ein-/Ausgabegrenze — Kennzeichnung nicht vertrauenswürdiger Inhalte, Filterung der Ausgabe vor der Ausführung. Schutz gegen ASI01 auf Inhaltsebene und gegen ASI06.
6. Freigabe- und Aufsichtspunkte — Sicherungen, Ratenbegrenzung, ein Notausschalter, menschliche Freigabe. Schutz gegen ASI08, ASI09 und ASI10.
7. Wiederkehrende Überprüfung — Red-Teaming fest in der Release-Pipeline verankert, ausgelöst durch jede Änderung am Werkzeugsatz, nicht einmalig pro Projekt.

Jeder dieser sieben Punkte entspricht einem Moment im Entwicklungsprozess, an dem eine konkrete Entwurfsfrage gestellt wird — keiner Checkliste, die jemand im Nachhinein abhakt. Genau das ist der gesamte Unterschied zwischen eingebauter Sicherheit und einer nachträglichen Prüfung.

Womit beginnen, wenn Sie einen Agenten von Grund auf bauen

Stehen Sie am Anfang des Prozesses, entspricht die Reihenfolge, in der sich die obigen Fragen zu stellen lohnt, genau der Reihenfolge, in der die Architekturentscheidungen tatsächlich fallen. Beginnen Sie damit, den Aufgabenbereich in einer Form festzuhalten, die sich in Beschränkungen im Code übersetzen lässt, nicht nur in einer Beschreibung im Entwurfsdokument. Stellen Sie bei jedem Werkzeug, bevor es in den Satz aufgenommen wird, die Frage nach dem schlimmsten möglichen Ergebnis seines Missbrauchs. Entscheiden Sie sich für die Ausführungsumgebung des Codes, bevor Sie die erste Integration schreiben, die diesen Code erzeugt. Kartieren Sie irreversible Aktionen und setzen Sie einen Freigabepunkt davor, bevor sich jemand auf einen Ablauf ohne einen solchen verlässt. Erst am Ende dieser Liste kommen Inhaltsfilterung und Guardrails hinzu — als rauschfilternde Schicht über einem bereits soliden Fundament.

Keiner dieser Schritte erfordert, auf die Vollständigkeit der übrigen zu warten — jeder für sich verringert bereits den Schadensradius eines möglichen Angriffs. Die Reihenfolge, in der Sie sie angehen, entscheidet jedoch darüber, ob Sie Sicherheit in die Architektur einbauen oder sie im Nachhinein anflanschen — teurer und mit schlechterem Ergebnis.

---

Dieser Artikel gehört zum Bereich „Verteidigung & Härtung“ bei secagentlabs und dient als verbindender Rahmen — er zeigt, an welcher Stelle des Entwicklungsprozesses jede Sicherheitsentscheidung fällt, und verweist auf die Beiträge, die jede Technik im Detail behandeln. Die Risikoklassifizierungen stammen aus den OWASP Top 10 für agentische Anwendungen (ASI01–ASI10), veröffentlicht am 9. Dezember 2025. Dies ist keine Konfigurationsanleitung für ein bestimmtes Produkt — jede Umsetzung muss an das eigene Bedrohungsmodell angepasst werden.