Hinweis: Dieses Video und der Podcast wurde mithilfe von KI erstellt auf Grundlage der ursprünglichen Inhalten sowie den technischen Erkenntnissen des Autors des Blogartikels.

Die digitalen Schafe sind die Softwareartefakte, die wir entwickeln und ausliefern. Nun erhalten KI-Agenten Tools, mit denen sie Dateien lesen, Befehle ausführen und auf unsere Infrastruktur zugreifen können. Doch sind die Freiheiten, die wir ihnen damit einräumen, ausreichend abgesichert? Der Artikel zeigt, welche Sicherheitsrisiken solche Tool-Zugriffe im Softwareentwicklungslebenszyklus schaffen und wie Sie ihnen mit begrenzten Berechtigungen, Isolation, Validierung und Monitoring begegnen. Das Model Context Protocol (MCP) spielt dabei als nützlicher Standard mit eigener Angriffsfläche eine Rolle.

von Brett Smith

Lust auf Crossplatform IoT Web and Cloud?

Entdecke Workshops vom 23. - 25. November in Düsseldorf

Mehr Infos

Lassen Sie uns hier präzise sein, denn der Begriff „Agent“ wird inzwischen für alles verwendet: vom Chatbot mit einem System-Prompt bis zum vollständig autonomen Pipeline-Orchestrator.

In der Praxis ist ein Agent ein Programm, das mit Hilfe eines Sprachmodells Entscheidungen trifft, Tools aufruft, um diese Entscheidungen umzusetzen, die Ergebnisse beobachtet und diesen Ablauf wiederholt, bis die Aufgabe erledigt ist oder etwas schiefgeht. Die Standardbeschreibung lautet: „Autonome KI, die mehrstufige Aufgaben ausführt.“ Tatsächlich handelt es sich um ein Programm mit einer while-Schleife, einem Modell in der Mitte und Zugriff auf Dinge, die bei Missbrauch Schaden anrichten können.

Das LLM ist nicht der Agent, sondern dessen Gehirn: die Schicht für Schlussfolgerungen und Planung, die entscheidet, was als Nächstes zu tun ist. Der Harness umfasst alles andere: die Ausführungsumgebung, das Gedächtnis, den Tool-Zugriff und die Sicherheitsschicht, die verhindert, dass das Ganze etwas Katastrophales anrichtet. Im Zentrum steht die Tool-Registry, die jeden Tool-Aufruf durch einen einzigen Kontrollpunkt leitet, bevor irgendetwas ausgeführt wird. Genau dieser Kontrollpunkt ist in den meisten Harness-Implementierungen völlig unzureichend ausgebaut.

Das Herzstück des Harness ist die Ausführungsschleife. Der Harness bündelt Gesprächsverlauf, System-Prompt und verfügbare Tools, sendet dieses Paket an das Modell und wartet auf dessen Antwort: Text, einen Tool-Aufruf oder beides. Tool-Aufrufe werden abgefangen, validiert und ausgeführt; ihre Ergebnisse fließen anschließend als Beobachtungen in den Gesprächsverlauf ein, bevor die Schleife erneut beginnt. Die Zustandsmaschine folgt dabei strikt den Zuständen untätig, denkend, ausführend, abgeschlossen und fehlgeschlagen. Sowohl die Anzahl der Iterationen als auch der Umfang des Kontexts müssen begrenzt werden. Fehlen feste Obergrenzen für beides, kann ein Agent unbegrenzt weiterlaufen oder unkontrolliert abstürzen, wenn das Token-Budget erschöpft ist. Das sind Anforderungen, keine Optimierungen.

Tool-Aufrufe: lokal und über MCP

Beim ersten Kontakt mit MCP sorgt häufig eines für Verwirrung: Tool-Aufrufe in einem Agent-Harness und Tool-Aufrufe über einen MCP-Server beruhen auf demselben Konzept, nur auf unterschiedlichen Abstraktionsebenen.

In einem lokalen Harness fordert das Modell einen Tool-Aufruf an. Ihr Code ruft daraufhin eine lokale Funktion auf und übermittelt deren Rückgabewert als Tool-Ergebnis an das Modell. Das Tool ist Code, den Sie selbst geschrieben haben und der im selben Prozess oder höchstens in einem von Ihnen kontrollierten Unterprozess läuft. Sie können diesen Code lesen, prüfen und verändern.

MCP erweitert dieses Muster nach außen: Statt eine lokale Funktion aufzurufen, sendet der Agent eine JSON-RPC-2.0-Anfrage an einen MCP-Server, der lokal, auf einem anderen Rechner oder als Remote-Service laufen kann. Für das Modell macht das keinen Unterschied: Aus seiner Sicht hat es ein Tool angefordert und ein Ergebnis erhalten. Die Protokollabstraktion bleibt für die Schlussfolgerungsschicht vollständig unsichtbar – und genau das ist das Problem.

Das macht MCP so leistungsfähig und zugleich so gefährlich: Das Vertrauen des Modells in das Tool verändert sich beim Wechsel von der lokalen Ausführung zu einem Remote-Server nicht, wohl aber Ihre Kontrolle darüber, was dieses Tool tatsächlich tut – und zwar erheblich. Ein lokaler Funktionsaufruf gehört zu Ihrer Codebase und wird überprüft. Ein entfernter MCP-Server ist dagegen ein Netzwerkendpunkt mit eigenem Code, eigener Angriffsfläche und eigenen Vertrauensannahmen.

Prompt Injection, kompromittierte Tools und übermäßige Rechte

Wenn Sie von der lokalen Tool-Ausführung zu MCP wechseln, übernehmen Sie das gesamte Bedrohungsmodell eines Netzwerkdienstes. Das Modell bekommt von diesem Wechsel nichts mit und vertraut den Tool-Ergebnissen weiterhin genauso wie zuvor Ihren lokalen Funktionen. Genau diese Kluft zwischen dem Vertrauen des Modells und dem tatsächlichen Sicherheitsniveau führt zu Problemen.

Der gefährlichste Angriffsvektor ist hier Prompt Injection über Tool-Ergebnisse. Das Modell ruft ein Tool auf, etwa einen Suchserver oder ein Tool zum Lesen von Dateien, und erhält ein Ergebnis, in dessen Inhalt bösartige Anweisungen eingebettet sind. Da das Modell nicht zwischen „Daten, die ich abgerufen habe“ und „Anweisungen, denen ich folgen sollte“ unterscheiden kann, verarbeitet es den eingeschleusten Inhalt als Teil seines Schlussfolgerungskontexts. Das ist kein hypothetisches Szenario, sondern wurde wiederholt an Produktivsystemen demonstriert: Wer beeinflussen kann, was ein Tool zurückgibt, kann auch beeinflussen, was der Agent als Nächstes tut.

Supply-Chain-Angriffe auf MCP-Server folgen demselben Muster, das wir überall sonst beobachten. Hinzu kommt, dass ein kompromittierter Tool-Server Kontext exfiltrieren, Anweisungen einschleusen und sich Zugriff auf die Infrastruktur verschaffen kann – alles über den normalen Ablauf von Tool-Aufrufen, auf dessen Vertrauenswürdigkeit Ihr Harness ausgelegt ist.

Übermäßige Handlungsfreiheit entsteht, wenn wir einem Agenten Autonomie einräumen, ohne ihre Risiken zu berücksichtigen. Dann verfügt er über ein run_command-Tool, doch keine Richtlinie begrenzt die zulässigen Befehle; er hat Datenbankzugangsdaten, doch niemand erzwingt einen ausschließlich lesenden Zugriff. Das sind keine KI-Probleme, sondern Autorisierungsprobleme. Wir haben schlicht vergessen, dieselben Kontrollen anzuwenden, die wir bei jedem anderen automatisierten System anwenden würden.

Trotzdem bauen wir irgendwann alle etwas, das beliebige Befehle in unseren Pipelines ausführt. Passwortloses SSH gefällig? Ansible, Sie sind gemeint. Fügen Sie nun nichtdeterministisches Schlussfolgern und uneingeschränkten Zugriff auf Ihre Infrastruktur hinzu. Sind die digitalen Schafe sicher?

Lerne die Speaker kennen

Die Konferenz zu Delphi & mehr vom 23. - 25. November in Düsseldorf

Mehr erfahren

Agenten, MCP und die tödliche Dreierkombination

Die „tödliche Dreierkombination“ besteht aus drei Fähigkeiten:

• Zugriff auf private Daten → Tools, die Secrets, Repositorys und Dateien lesen können
• Kontakt mit nicht vertrauenswürdigen Inhalten → von Angreifenden kontrollierte Eingaben (Issues, Pull Requests (PRs), Webinhalte)
• externe Kommunikation → jeder Kanal, über den Daten exfiltriert werden können (PRs, WebHooks, E-Mail)

Kommen alle drei zusammen, können Angreifende das System dazu verleiten, private Daten zu lesen und nach außen zu senden. Diese Konstellation ist als „the lethal trifecta for AI agents“ bekannt. Meiner Ansicht nach gilt das für alle unsere Tools, einschließlich MCP-Servern. Die Gefahr entsteht durch die Kombination: Jede Fähigkeit für sich ist beherrschbar, doch zusammen ermöglichen sie es, Daten ohne großen Aufwand zu exfiltrieren. Ein solcher Angriff wurde kürzlich anhand des GitHub-MCP-Exploits demonstriert: Ein Angreifer kann sensible Daten aus einem GitHub-Repository exfiltrieren, indem er einen Prompt in einen KI-Agenten einschleust, der auf das Repository zugreifen kann.

Verankern Sie vorbeugende Maßnahmen wie Isolation und Richtlinien bereits im Systementwurf und sorgen Sie dafür, dass Angriffe auch im laufenden Betrieb erkannt werden. Warnmeldungen und Rate-Limits ergänzen diese Absicherung. Die Gegenmaßnahmen im Überblick:

• Setzen Sie das Prinzip der geringsten Rechte durch: Trennen Sie Tools, die private Daten lesen, von Tools, die Inhalte nach außen veröffentlichen können.
• Behandeln Sie nicht vertrauenswürdige Eingaben als feindlich: Validieren, bereinigen und isolieren Sie sie, bevor Sie sie Agenten zugänglich machen.
• Blockieren Sie ausgehende Kommunikationskanäle von Tools, die auf sensible Daten zugreifen, oder kontrollieren Sie diese Kanäle streng.
• Achten Sie auf verdächtige Muster: Unerwartete Lesezugriffe in Verbindung mit ausgehenden Aktionen müssen Warnmeldungen auslösen.

Den Agenten unter Kontrolle halten

Ein autonomer Agent bietet faktisch die Ausführung von Code aus der Ferne als Funktion – also Remote Code Execution. Wenn Ihnen diese Sichtweise Unbehagen bereitet, dann zu Recht. Ohne robuste Sicherheitsschicht kann ein LLM Dateien löschen, Daten exfiltrieren, interne Dienste ausforschen oder das Hostsystem zum Absturz bringen und Ihnen dabei hilfsbereit erklären, dass es versucht, Ihre Aufgabe zu erledigen. Ein Harness für den Produktiveinsatz braucht wirksame Sicherheitskontrollen, die direkt in den Ausführungspfad eingebaut sind.

Befehlsvalidierung

Jeder Befehl muss vor der Ausführung geprüft werden, und zwar im Harness, nicht nach dem Ermessen des Modells. Dazu gehören eine Denylist für grundsätzlich verbotene Operationen wie rekursives Löschen, das Formatieren von Datenträgern oder das Herunterfahren des Systems sowie eine Allowlist für Befehle, die für die konkrete Aufgabe als sicher gelten. Hinzu kommt ein Musterabgleich mit regulären Ausdrücken, um gefährliche Flags zu erkennen, denn die offensichtlichen Fälle sind offensichtlich, die weniger offensichtlichen eben nicht. Bei Befehlen, deren Zulässigkeit unklar ist, sollte vor der Ausführung eine ausdrückliche menschliche Freigabe erforderlich sein. Ein Mensch braucht Sekunden, um einen Befehl abzulehnen. Löscht ein Befehl dagegen das falsche Verzeichnis, dauert die Wiederherstellung Stunden – sofern sie überhaupt möglich ist.

Pfadvalidierung und Sandbox

Der Dateisystemzugriff muss auf ein festgelegtes Arbeitsverzeichnis beschränkt sein. Jeder Pfad, auf den der Agent zugreifen will, muss zunächst in seine kanonische absolute Form aufgelöst werden; anschließend ist zu prüfen, ob er innerhalb des Wurzelverzeichnisses der Sandbox liegt. Das verhindert Directory-Traversal-Angriffe, bei denen ein Modell versucht, auf etwas zuzugreifen, das zwei oder drei Verzeichnisebenen über dem vorgesehenen Suchbereich liegt – sei es, weil es verwirrt ist, manipuliert wurde oder mit seinem Versuch zu helfen schlicht in die falsche Richtung geht.

Die Kanonisierung muss vor der Prüfung erfolgen, nicht danach. Ein harmlos wirkender relativer Pfad kann nach der Auflösung symbolischer Links auf etwas Gefährliches zeigen: Ein symbolischer Link innerhalb der Sandbox kann auf ein Ziel außerhalb verweisen, ohne dass eine naive Präfixprüfung des noch nicht aufgelösten Pfads das erkennt. Deshalb gilt bei jedem Zugriff: zuerst auflösen, dann den aufgelösten Pfad prüfen – beide Schritte, in genau dieser Reihenfolge.

Human-in-the-Loop

Bei sensiblen Operationen sollte der Harness pausieren und eine ausdrückliche menschliche Freigabe verlangen. Im interaktiven Modus fragt er bei jedem Tool-Aufruf nach: maximale Transparenz, maximale Reibung. Im autonomen Modus werden Lesezugriffe automatisch freigegeben, während Schreibzugriffe und die Ausführung von Befehlen bestätigt werden müssen – die richtige Standardeinstellung für die meisten Workloads im Produktivbetrieb. Der vollautomatische Modus gibt alles ohne menschliche Beteiligung frei. Dafür gibt es berechtigte Einsatzfälle, doch die meisten Produktivsysteme, in denen es zu schweren Vorfällen kam, liefen ohne Monitoring in diesem Modus. Das ist ungefähr so, als würden Sie jemandem die Schlüssel zu Ihrer Infrastruktur überlassen und sich ins Wochenende verabschieden.

Netzwerksicherheit

Wenn der Agent über ein Fetch-Tool verfügt, muss dieses gegen Server-Side Request Forgery geschützt sein. Der Harness muss localhost und Loopback-Adressen blockieren, Anfragen an Ziele ablehnen, deren Namen in private IP-Adressen aufgelöst werden, und die zulässigen Protokolle auf HTTP und HTTPS beschränken. Die Validierung der IP-Adressen muss nach der Domain-Name-System-Auflösung (DNS) erfolgen. Beim DNS-Rebinding wird bei der ersten Abfrage eine öffentliche und bei späteren Abfragen eine private IP-Adresse zurückgegeben – eine Prüfung, die sich nur auf den Hostnamen bezieht, übersieht das jedes Mal.

Ressourcenlimits

Iterationslimits begrenzen die Denkschleifen, während Kontextlimits eine Kürzung nach dem First-in-first-out-Prinzip (FIFO) auslösen, sobald sich der Gesprächsverlauf dem Token-Budget nähert. Ausgabelimits kürzen Tool-Ergebnisse, damit eine riesige Logdatei den Kontext nicht überflutet und die Systemanweisungen verdrängt, denen der Agent folgen soll; ein gekürztes Log ist fast immer nützlicher als ein abgestürzter Agent. Ausführungs-Time-outs beenden Shellbefehle, die deutlich länger laufen, als es die Aufgabe rechtfertigt. Alle vier Mechanismen gehören in die Ausführungs-Engine, nicht in einzelne Tool-Implementierungen. Wird ihre Einhaltung den Tools überlassen, wird irgendwann jemand eines schreiben, das die Begrenzungen nicht durchsetzt.

MCP: nützlicher Standard, neue Angriffsfläche

MCP ist die richtige Idee: Es standardisiert, wie Agenten externe Tools finden und aufrufen. Das Protokoll – JSON-RPC 2.0 über HTTP oder stdio – ist einfach genug, dass seine Implementierung nicht zwangsläufig gefährlich ist. Allerdings zeigt sich auch hier ein vertrautes Problem neuer Integrationsmuster: Entwickler übernehmen das Muster schneller als das dazugehörige Sicherheitsmodell.

In dieser Architektur steht ein MCP-Server zwischen dem KI-Client und Ihren Tools und Daten. Der Client ermittelt, welche Tools verfügbar sind, ruft sie über ihren Namen auf und verarbeitet die Ergebnisse. Dieser Ansatz ist sauber, und seine Komponenten lassen sich gut miteinander kombinieren. Behandeln Sie einen MCP-Server wie jeden anderen Server in Ihrer Pipeline: mit derselben Sicherheitsprüfung, derselben Analyse der Zugriffskontrollen und demselben Monitoring. Auch ein Server mit dem Etikett „KI“ braucht grundlegende Härtung.

Die einzelnen Bedrohungsvektoren sind konkret genug, um sie näher zu beschreiben:

• Beim Tool-Poisoning werden bösartige Anweisungen in Tool-Beschreibungen eingebettet. Das Modell liest diese Beschreibungen, um zu verstehen, was das jeweilige Tool tut. Wer einen Tool-Server kontrolliert, kann dort Anweisungen unterbringen, die vor, während oder nach der vorgesehenen Operation ausgeführt werden. Das Modell kann legitime Dokumentation nicht von bösartigen Anweisungen unterscheiden. Die Spezifikation vom 25.11.2025 legt ausdrücklich fest, dass Tool-Beschreibungen als nicht vertrauenswürdig behandelt werden sollten, sofern sie nicht von einem verifizierten Server stammen – damit wird nun auch formal anerkannt, was Angreifende seit Monaten ausnutzen.
• Das Confused-Deputy-Problem entsteht, wenn ein MCP-Server als Proxy für ein API eines Drittanbieters fungiert. Der Angriff funktioniert, wenn eine statische Client-ID mit dynamischer Client-Registrierung kombiniert wird: Angreifende erstellen eine Anfrage mit einem bösartigen Redirect-URI. Da im Browser bereits ein Zustimmungs-Cookie aus einer früheren legitimen Autorisierung vorliegt, landet der Autorisierungscode auf dem Server der Angreifenden statt auf dem legitimen Server. Die Spezifikation verlangt nun für jeden Client eine gesonderte Zustimmung, die serverseitig gespeichert und vor Beginn jedes Autorisierungsablaufs bei einem Drittanbieter geprüft wird. OAuth-State-Parameter müssen sicher erzeugt, erst nach erteilter Zustimmung gespeichert und als nur einmal verwendbare Werte mit kurzer Gültigkeitsdauer behandelt werden. Wer den Zustimmungs-Cookie schon vor der eigentlichen Zustimmung setzt – eine verbreitete Abkürzung –, macht den Schutz vollständig zunichte.
• Token Passthrough war ein verbreitetes Antipattern: Der MCP-Server akzeptiert Client-Tokens ohne Validierung und reicht sie an nachgelagerte APIs weiter. Die Spezifikation verbietet das nun ausdrücklich mit der Formulierung „MUST NOT“: Server dürfen keine Tokens akzeptieren, die nicht ausdrücklich für sie ausgestellt wurden. Passthrough umgeht das Rate-Limiting, das auf korrekter Tokenvalidierung beruht, macht Audit-Trails unzuverlässig, weil der Server nicht zwischen Aufrufenden unterscheiden kann, und führt dazu, dass ein einziges kompromittiertes Token bei jedem Dienst in der Kette funktioniert.
• Session Hijacking tritt in zwei Formen auf. Bei der Prompt-Injection-Variante senden Angreifende mit Hilfe einer gestohlenen Session-ID ein bösartiges Ereignis an einen zweiten Server. Dieser stellt die Payload in eine Warteschlange, woraufhin der erste Server sie an den legitimen Client ausliefert, der die Anweisungen der Angreifenden ausführt. Bei der zweiten Variante täuschen Angreifende mit der gestohlenen Session-ID eine fremde Identität vor und führen damit direkte Aufrufe aus. Die Spezifikation verlangt, dass Session-IDs kryptografisch sicher und nichtdeterministisch sind und an nutzerspezifische Informationen gebunden werden. Eine Session-ID zur Authentifizierung statt zur Zustandsverwaltung zu verwenden, ist ausdrücklich verboten.
• Die Kompromittierung lokaler Server ist die jüngste Ergänzung des Bedrohungskatalogs. Lokale MCP-Server laufen auf dem Rechner der Nutzer und haben direkten Systemzugriff, was sie zu einem attraktiven Ziel macht. Angreifende betten bösartige Startbefehle in Serverkonfigurationen ein, verteilen Payloads in scheinbar legitimen Paketen oder greifen per DNS-Rebinding auf unsichere localhost-Server zu. Nutzer haben in der Regel keinen Einblick darin, welche Befehle ausgeführt werden, und durch Verschleierung wirken bösartige Befehle unauffällig. Die Spezifikation verlangt nun für die Ein-Klick-Konfiguration Zustimmungsdialoge, die vor der Ausführung den genauen Befehl vollständig und ungekürzt anzeigen.
• Eine unzureichende Scope-Minimierung liegt vor, wenn MCP-Server von Anfang an weitreichende Berechtigungen oder Wildcard-Berechtigungen bereitstellen. Ein einziges gestohlenes Token mit dem Scope files:* oder admin:* ermöglicht Zugriffe weit über die ursprüngliche Operation hinaus. Einzelne Berechtigungen lassen sich dann nicht widerrufen, ohne zugleich alles andere zu beeinträchtigen; außerdem entsteht in den Auditlogs so viel Rauschen, dass kaum noch erkennbar ist, was Nutzer tatsächlich tun wollten. Die Spezifikation verlangt nun eine schrittweise Scope-Erweiterung: mit minimalen Basis-Scopes beginnen und Berechtigungen erst dann erweitern, wenn konkrete privilegierte Operationen erforderlich sind. Das begrenzt das Schadensausmaß, wenn Tokens kompromittiert werden, und macht die Absicht der Nutzer in den Auditlogs nachvollziehbar.

Orchestratoren und Subagenten

In agentischen Systemen im Produktivbetrieb zeichnet sich ein Orchestrator-Modell ab: Ein Agent plant und verteilt die Arbeit, während mehrere spezialisierte Subagenten bestimmte Arten von Aufgaben ausführen – jeweils mit eigenem Tool-Zugriff und eigenem Berechtigungsumfang.

Der Orchestrator kennt das Ziel und weiß, welcher Subagent welchen Teil übernehmen sollte. Er hat keinen direkten Zugriff auf Produktivsysteme, sondern kommuniziert mit Subagenten, die diesen Zugriff haben: Ein Coding-Subagent kann auf Repositorys und Test-Runner zugreifen, ein Such-Subagent auf die Retrieval-Infrastruktur, und ein Infrastruktur-Subagent verfügt über Deployment-Zugangsdaten mit begrenztem Berechtigungsumfang. Der Orchestrator selbst hat auf nichts davon direkten Zugriff.

Dieses Muster überträgt die Trennung von Zuständigkeiten, die wir überall sonst in der Softwarearchitektur anwenden, auf Agentensysteme. Es begrenzt das Schadensausmaß, wenn etwas schiefgeht – und in autonomen Systemen mit externem Tool-Zugriff wird irgendwann etwas schiefgehen. Jeder Subagent erhält nur die wenigen Tools, die er für seine Rolle benötigt. Wo immer möglich, sind die Grenzen strukturell verankert und nicht allein durch Richtlinien festgelegt: Richtlinien lassen sich umgehen, strukturelle Grenzen dagegen nur durch gezieltes Aushebeln.

Tool-Aufrufe überwachen und Auffälligkeiten erkennen

Ein agentisches System zu überwachen bedeutet, seine Tool-Aufrufe zu überwachen, denn sie sind die entscheidenden Handlungsschritte. Protokollieren Sie jeden Tool-Aufruf mit dem Tool-Namen, den Eingaben, einer Zusammenfassung des Ergebnisses und der vorausgegangenen Modellantwort. So erhalten Sie einen vollständigen Audit-Trail, der nachvollziehbar macht, wozu sich der Agent entschieden hat und was bei der Ausführung passiert ist.

Achten Sie auf Muster von Tool-Aufrufen, die nicht zur vorgesehenen Aufgabe passen. Ein Agent, der mitten in einer Codereview plötzlich Dateisystem-Tools aufruft, ist entweder verwirrt oder kompromittiert. Rate-Limiting für Tool-Aufrufe dient nicht nur der Kostenkontrolle, sondern auch der Anomalieerkennung: Steigt die Zahl der Tool-Aufrufe plötzlich stark an, sollten Sie dem nachgehen.

Auch Änderungen an Tool-Definitionen sollten Warnmeldungen auslösen. Gibt ein MCP-Server andere Tool-Beschreibungen zurück als am Vortag, ist das eine Veränderung, die Sie überprüfen sollten. Auf diese Weise lässt sich Tool-Poisoning erkennen – vorausgesetzt, Sie achten darauf.

Versuche zur Scope-Erweiterung – also Versuche des Agenten, auf Ressourcen außerhalb seines zulässigen Berechtigungsumfangs zuzugreifen – sollten Warnmeldungen auslösen, statt lediglich mit einer Zugriffsverweigerung zu enden. Der verweigerte Zugriff zeigt, dass die Sicherheitskontrolle funktioniert; die Warnmeldung macht Sie darauf aufmerksam, dass jemand Ihre Grenzen austestet, das Modell verwirrt ist oder sich in einem vorgelagerten Teil des Systems etwas verändert hat.

Fazit

Agentische KI im SDLC ist längst Gegenwart. Entwicklungsteams bauen und betreiben schon heute Agent-Harnesses, binden MCP-Server ein und verbinden die Harnesses mit Produktivsystemen. Die Sicherheitsanalyse für diese Systeme folgt den vertrauten Prinzipien, die wir schon immer auf automatisierte Systeme mit externem Zugriff angewandt haben. Neu sind die Angriffsfläche, die durch das Vertrauen des Modells in Tool-Ergebnisse entsteht, und die Neigung von Entwicklern, zuerst auszuliefern und erst danach über Autorisierung nachzudenken.

Verstehen Sie die Ausführungsschleife, bevor Sie das System ausliefern, und statten Sie jeden Agenten mit den Tools aus, die er für seine konkrete Rolle tatsächlich benötigt. Validieren Sie Tool-Ergebnisse, bevor Sie auf ihrer Grundlage handeln, und bauen Sie die Sicherheitskontrollen so in die Ausführungs-Engine ein, dass sie nicht umgangen werden können. Behandeln Sie MCP-Server wie die Netzwerkdienste, die sie sind, und konzentrieren Sie sich beim Monitoring auf Tool-Aufrufe: Sie sind die maßgeblichen Handlungsschritte, die sich protokollieren und nachvollziehen lassen.

Die digitalen Schafe sind nur so sicher wie die Hirten, die über sie wachen – und die Hirten müssen wissen, welche Tools sie den Gremlins in die Hand gegeben haben, bevor diese in die Infrastruktur gelangen.