Safeguards in der KI-unterstützten Softwareentwicklung

Abstract — Der Einsatz KI‑gestützter Werkzeuge in der Softwareentwicklung führt zu einer zunehmenden Automatisierung von Entwicklungsprozessen und steigert Effizienz und Produktivität. Gleichzeitig entstehen neue sicherheitsrelevante Risiken, insbesondere durch autonome KI‑Agenten, die eigenständig Entscheidungen treffen und externe Werkzeuge nutzen. Diese Arbeit untersucht Safeguards, die zur Absicherung KI‑unterstützter Softwareentwicklung geeignet sind.
Zunächst werden klassische Safeguards wie Code‑Reviews, automatisierte Tests sowie statische und dynamische Code‑Analyseverfahren betrachtet. Darauf aufbauend werden KI‑spezifische Risiken anhand der OWASP Top 10 for Agentic Applications analysiert. Anschließend werden ausgewählte KI‑spezifische Safeguards vorgestellt, darunter KI‑gestützte Code‑Reviews, Sandbox‑Technologien sowie Werkzeuge zur Durchsetzung von Architektur‑ und Prozessvorgaben.
Die Ergebnisse zeigen, dass ein mehrschichtiges Safeguard‑Konzept erforderlich ist, um die Risiken KI‑gestützter Softwareentwicklung wirksam zu begrenzen und sichere, wartbare Softwaresysteme zu gewährleisten.

Index Terms — Artificial Intelligence, Safeguards, Software Engineering, Software Engineering Process.

Einleitung

In den letzten Jahren hat sich die Softwareentwicklung in großen Schritten weiterentwickelt. Immer mehr Gegenstände werden mit Software erweitert, wie Smart-Home-Geräte, Autos oder auch Fitness-Tracker u. Ä. Auch in der Industrie gibt es immer mehr Tools, z. B. zur Analyse der Stimmung der Mitarbeiter und zur Vorsortierung von Bewerbern und vieles mehr [1]. Immer mehr Daten werden digitalisiert, und mit dieser Verbreitung an Software vertrauen wir Menschen dieser Software immer mehr persönliche Daten an, oft auch unbewusst. Dieser Trend hat jedoch auch eine dunkle Seite: Mit der zunehmenden Abhängigkeit von Software steigt auch das Risiko von Angriffen auf diese Systeme. Hacker und Cyberkriminelle nutzen immer raffiniertere Methoden, um in diese Systeme einzudringen und sensible Daten zu stehlen oder zu manipulieren. Im Jahresbericht des BSI (Juli 24 – Juni 25) wird erwähnt, dass in diesem Zeitraum täglich durchschnittlich 119 neue Schwachstellen in IT-Systemen bekannt geworden sind [2]. Die Zahl der Ransomware-Angriffe beläuft sich auf 950, was ähnlich zum vorherigen Jahr ist. Die Anzahl der Exploitationen ist um 38% gestiegen. Etwa jeder Fünfte gab an, in dem Jahr von Cyberkriminalität betroffen gewesen zu sein. In fast allen Sektoren gab es mehr gemeldete Störungen als im vorherigen Berichtszeitraum. Es wurden 461 Datenleaks bekannt, bei denen zu 92% Geburtsdaten, 72% E-Mail-Adressen und 63% Gesundheits- und Finanzdaten betroffen waren. Dieser Bericht betont einmal mehr, wie wichtig Sicherheit in der Softwareentwicklung ist. Um uns vor Angriffen dieser Art besser schützen zu können, gibt es in der Softwareentwicklung sogenannte Safeguards.

Safeguards sind Maßnahmen, die dazu dienen, Risiken zu verhindern, zu minimieren oder zu kontrollieren. Sie können technischer, organisatorischer oder menschlicher Natur sein und umfassen eine Vielzahl von Ansätzen, von Sicherheitstools über Prozesse bis hin zu Schulungen und Awareness-Programmen.

Wie sich die Softwareentwicklung mit der Zeit weiterentwickelt, müssen auch die Safeguards anpassen und evolvieren, um die neuen Herausforderungen und Risiken zu adressieren. In den letzten Jahren haben KI-gesteuerte Tools wie ChatGPT, Copilot und andere eine wichtige Rolle in der Softwareentwicklung gespielt. Diese Tools ermöglichen es Entwicklern, Code schneller und effizienter zu generieren und einen Mehrwert zu schaffen. Darüber hinaus haben KI-gesteuerte Testtools das Testen von Software vereinfacht und beschleunigt. In einem Bericht von GitHub über das Jahr 2025 heißt es, dass 1,1 Millionen Projekte auf dieser Plattform ein LLM-SDK benutzen und über 4,3 Millionen Projekte einen KI-Bezug haben [3]. Das betont die extreme Verbreitung von KI-gestützten Tools in den letzten Jahren. Weiter heißt es in dem Bericht, dass allein in dem Jahr 36 Millionen Entwickler neu zu dieser Plattform dazugekommen sind. Viele KI-Tools erleichtern die Barriere zwischen gesprochener Sprache und Programmiersprachen, sodass es immer leichter wird, ein eigenes Projekt aufzusetzen, auch für Nicht-Entwickler. Dass diese Zahlen zusammenhängen, bestätigt der Bericht, denn er sagt, dass 80% der neuen Entwickler den Copilot innerhalb der ersten Woche nach Beitritt benutzen.

Die Maschinengenerierung von Code und Tests ermöglicht es, große Mengen an Code und Testfällen schnell und effizient zu erzeugen. Dies kann jedoch auch negative Konsequenzen haben, da generierter Code oft fehleranfällig, unvollständig oder unsicher ist. KI-gesteuerte Tools können Sicherheitslücken und Schwachstellen übersehen oder erzeugen, die schwer zu entdecken und zu beheben sind. In diesem Kontext ist es entscheidend, Safeguards zu entwickeln und anzuwenden, die speziell auf die Herausforderungen und Risiken von KI-gesteuerten Tools abgestimmt sind. Dieses Paper untersucht, welche Safeguards bei der Nutzung von KI-Tools besonders hilfreich sind, um Sicherheitslücken und Schwachstellen zu vermeiden und zu beheben. In dieser Arbeit werden die neuen Herausforderungen und Risiken analysiert, die durch KI-gesteuerte Tools entstehen, und die wichtigsten Safeguards identifiziert, die Entwickler und Organisationen anwenden sollten, um sichere und zuverlässige Software zu entwickeln.

Im folgenden Kapitel 2 werden zunächst die neuen Sicherheitsrisiken analysiert, die durch den Einsatz von KI-Agenten in der Softwareentwicklung entstehen. Dabei dient die OWASP Top 10 for Agentic Applications als Grundlage. Anschließend werden in Kapitel 3 bewährte klassische Safeguards vorgestellt, bevor in Kapitel 4 KI-spezifische Safeguards wie KI-basierte Code-Reviews, Sandbox-Technologien sowie Werkzeuge zur Architektur- und Prozesseinhaltung behandelt werden. Die Arbeit schließt mit einem Fazit und Ausblick.

Sicherheitsrisiken durch KI-Agenten in der SWE

Mit dem stetig wachsenden Einsatz von KI-Agenten in der Softwareentwicklung, wachsen auch die sicherheitsrelevanten Risiken, welche auch über die klassischen Schwachstellen hinausgehen [4]. KI-Agenten unterscheiden sich dabei von herkömmlichen KI-Systemen, wie ChatGPT oder ähnlichen LLMs, indem sie nicht nur Vorschläge liefern. Vielmehr können KI-Agenten eigenständig Aktionen ausführen, Entscheidungen treffen, externe Systeme ansprechen und über längere Zeiträume hinweg mit persistentem Kontext agieren [5]. Mittels dieses autonomen Arbeitens des KI-Agenten erhöht sich die Effizienz in dem Software-Entwicklungsprozess, vergrößert jedoch gleichzeitig die Angriffsfläche maßgeblich [4].

Die Open Web Application Security Project (OWASP) Initiative hat aus diesem Grund eine Liste mit diesen Risiken veröffentlicht. Diese OWASP Top 10 for Agentic Applications 2026 beschreibt dabei explizite Bedrohungen, die durch die Kombination von Autonomie, Kontextpersistenz, Tool-Nutzung und unzureichender Kontrolle von KI-Agenten entstanden sind [6]. Dabei umfassen die OWASP Top 10 for Agentic Applications 2026 die folgenden Risiken:

• ASI01: Agent Goal Hijack
• ASI02: Tool Misuse and Exploitation
• ASI03: Identity and Privilege Abuse
• ASI04: Agentic Supply Chain Vulnerabilities
• ASI05: Unexpected Code Execution (RCE)
• ASI06: Memory & Context Poisoning
• ASI07: Insecure Inter-Agent Communication
• ASI08: Cascading Failures
• ASI09: Human-Agent Trust Exploitation
• ASI10: Rogue Agents

Die aufgeführten Risiken verdeutlichen, dass sicherheitsrelevante Schwachstellen bei agentischen KI-Systemen nicht isoliert betrachtet werden können, sondern häufig aus dem Zusammenspiel mehrerer Eigenschaften wie Autonomie, Tool-Nutzung und Kontextpersistenz entstehen. In den folgenden Abschnitten werden die ersten drei Risiken der Liste genauer betrachtet. Diese sind nach der Rangliste der OWASP-Initiative die wichtigsten und adressieren die grundlegenden Schwachstellen agentischer KI-Systeme. Die weiteren Risiken ASI04 bis ASI10, darunter Supply-Chain-Schwachstellen, unerwartete Codeausführung oder Cascading Failures, bauen häufig auf diesen Grundrisiken auf oder manifestieren sich als deren Folgeerscheinungen.

Agent Goal Hijack

Basierend auf der OWASP-Top-10-Liste ist eine der zentralen Sicherheitsbedrohungen agentischer KI-Systeme, die ASI01 (Agent Goal Hijack). Diese Schwachstelle entsteht laut der OWASP Top 10 dadurch, dass autonome KI-Agenten ihre Ziele, Planungen und Handlungsentscheidungen basierend auf natürlicher Sprache ableiten. Dabei können die KI-Agenten aber nicht zuverlässig zwischen legitimen Instruktionen und schadhaften oder manipulierten externen Inhalten unterscheiden. Hierdurch besitzen Angreifer die Möglichkeit, das Ziel eines KI-Agenten unbemerkt so zu beeinflussen, dass beispielsweise sensible Informationen offengelegt werden. Dabei werden beispielsweise Aktionen ausgeführt, die zwar technisch korrekt aussehen, allerdings nicht dem ursprünglichen Ziel des Nutzers entsprechen [6].

Bei der herkömmlichen Prompt-Injection wird einzig und allein eine einzelne Antwort des KI-Systems manipuliert und verfälscht. Bei dem Agent Goal Hijack hingegen wird das mehrstufige Entscheidungsverhalten beeinflusst. Dies geschieht unbemerkt, da der KI-Agent weiterhin funktional wirkt und sich innerhalb erlaubter Richtlinien bewegt. Währenddessen werden allerdings Pläne verändert, Aufgaben neu priorisiert und Tools aufgerufen, jedoch mit einem abweichenden Ziel, welches eingeschleust wurde [6].

Ein reales Beispiel für das Agent Goal Hijack stellt der Angriff EchoLeak dar. Dieser wurde im Jahr 2025 in einem produktiven Unternehmenssystem namens Microsoft 365 Copilot nachgewiesen. Dabei nutzten die Angreifer eine indirekte Zero-Click-Prompt-Injection, bei der der KI-Agent schadhafte Instruktionen aus externen Inhalten verarbeitet, ohne dass eine zusätzliche Nutzerinteraktion benötigt wird. Im Fall von EchoLeak wurden manipulierte Instruktionen in einer externen E-Mail eingebettet. Der KI-Agent, welcher seiner regulären Arbeitsweise folgte, verarbeitete beim Zusammenfassen oder Analysieren der Mails diese schadhafte Instruktion. Dieser Agent übernahm diese Instruktion und veränderte in der Folge seine Zielsetzung ohne eine weitere Nutzerinteraktion. Anstelle der vorgesehenen Aktionen, begann der KI-Agent aktiv, sensible Daten zu sammeln und nach außen zu übertragen [7].

Dieses reale Beispiel verdeutlicht, welche Gefahr durch KI-Agenten resultiert. Der KI-Agent handelte dabei nicht fehlerhaft, sondern verfolgte sein reguläres Vorgehen. Er identifizierte relevante Inhalte und integrierte diese in seine Antwort und nutzte dabei legitime Ausgabemechanismen, um die sensiblen Daten zu exfiltrieren. Somit handelte der KI-Agent logisch und regelkonform, während er aus sicherheitstechnischer Sicht eindeutig das ursprüngliche Ziel missachtet hat. Genau diese diskrete Zielveränderung macht den Agent Goal Hijack zu einer schwer erkennbaren Bedrohung [7].

Tool Misuse and Exploitation

KI-Agenten besitzen sogenannte Tools, welche es ihnen ermöglichen, auf externe Systeme zuzugreifen. Beispielsweise ermöglichen Tools KI-Agenten, auf Dateien im Dateisystem zuzugreifen, Code auszuführen oder Nachrichten zu versenden. Ausschließlich durch diese Tools sind KI-Agenten in der Lage, autonom Aufgaben zu erfüllen. Jedoch verbirgt sich hier ein weiteres zentrales Risiko ASI02 (Tool Misuse and Exploitation). Hierbei werden die Tools durch Prompt-Injection, fehlerhafte Planung oder unzureichende Kontrolle über die Tools auf eine unsichere oder nicht beabsichtigte Art und Weise verwendet [6].

Welche Tools aufgerufen oder kombiniert werden, wird anhand natürlicher Sprache und des Kontexts des KI-Agenten entschieden. Dies ermöglicht es Angreifern, die Tools mit einer unbeabsichtigten und schädlichen Absicht auszuführen. Die häufigsten Folgen laut OWASP Top 10, welche durch dieses Risiko resultieren, sind überprivilegierte APIs, ungeprüfte Weitergabe von Modell-Ausgaben an Shell oder Datenbank-Tools sowie unsicheres Web-Browsing [6].

In der Arbeit “Progent: Programmable Privilege Control for LLM Agents” wird ein reales Beispiel für die ASI02 beschrieben. Dabei handelt es sich um einen Coding-Agenten, welcher mit verschiedenen GitHub-Tools ausgestattet ist. Dieser wurde darauf ausgelegt, lediglich öffentliche Issues eines GitHub-Repositories zu bearbeiten. Jedoch befindet sich in einer öffentlichen GitHub-Issue-Beschreibung eine Anweisung an den KI-Agenten, welche diesen dazu verleitet, zusätzliche Tools zu nutzen, welche er zuvor nicht nutzen sollte. So benutzt er beispielsweise ein Tool, um private Repositories aufzulisten, als auch das Auslesen sensibler Daten. Die daraus gewonnenen Informationen wurden daraufhin mittels legitimer Ausgabekanäle in ein öffentliches Repository exfiltriert, wobei der Angriff unauffällig blieb, da weder ungewöhnliche Systemaufrufe noch formale Richtlinienverstöße auftraten [8].

Aufgrund der Autonomie, dynamischer Tool-Auswahl sowie fehlender feingranularer Privilegskontrolle verdeutlicht dieses Beispiel das ASI02-Risiko. Als eine Gegenmaßnahme empfiehlt OWASP, das Prinzip der minimalen Rechte für Tools einzuhalten, Toolaufrufe zu überprüfen, die Ausführung von KI-Agenten in isolierten Sandboxen sowie ein umfangreiches Logging und Monitoring der KI-Agenten. Ohne diese Safeguards können sonst harmlose Tools zu effektiven Angriffsvektoren verwandelt werden [6].

Identity and Privilege Abuse

Mit ASI03 (Identity and Privilege Abuse) beschreibt OWASP eine weitere zentrale Schwachstelle von KI-Agenten. Bei dieser Schwachstelle werden Identitäten und Berechtigungen von KI‑Agenten missbräuchlich verwendet. Zentral verantwortlich hierfür sind die fehlende klare Trennung zwischen Nutzer-, Agenten- und Systemidentitäten sowie die dynamische Delegation von Aufgaben. Häufig arbeiten dabei KI-Agenten im Namen der Benutzer und nehmen die Identität dieser automatisch an sich, wodurch sie automatisch dieselben Berechtigungen erlangen, ohne dass diese eingeschränkt oder zeitlich begrenzt wurden. Wird nun eine Aktion ausgeführt, kann nicht mehr eindeutig nachvollzogen werden, welche Identität die Aktion ausgeführt oder autorisiert hat [6].

Die unkontrollierte Weitergabe von privilegierten Zugangsdaten ist dabei laut OWASP ein typisches Angriffsszenario. Wird eine Aufgabe von einem hochprivilegierten KI-Agenten an einen untergeordneten KI-Agenten delegiert, so kann dieser möglicherweise unbeabsichtigt Rechte erhalten, die weit über seinen Aufgabenbereich hinausgehen. Angreifer machen sich dieses Verfahren zunutze, indem sie mittels Prompt-Injection oder manipuliertem Kontext privilegierte Aktionen ausführen, auf die sie sonst keine Berechtigung hätten. Besonders kritisch sind dabei Mehragentensysteme, bei denen Agenten internen Anfragen automatisch vertrauen, auch als Confused Deputy betitelt [9].

Aus dem Artikel von AIMultiple geht hervor, dass KI-Agenten in der Praxis häufig mit persistenten Identitäten wie API-Schlüsseln, OAuth-Tokens oder Service‑Accounts arbeiten. Diese Identitäten sind über mehrere Aufgaben hinweg für den KI-Agenten zugänglich und werden entsprechend genutzt. Zudem kommt, dass die verfügbaren Identitäten von KI-Agenten oftmals zu weitreichend konfiguriert sind, wodurch dieser Berechtigungen besitzt, die er nicht benötigt. Wird ein solcher KI-Agent manipuliert, kann er nun diese Berechtigungen nutzen, um Schaden anzurichten [9].

Als Gegenmaßnahme werden klar getrennte Agenten-Identitäten, zeitlich begrenzte und aufgabenbezogen begrenzte Berechtigungen sowie eine erneute Autorisierung bei einer privilegierten Aktion empfohlen. Dies verhindert, dass KI-Agenten über eine längere Zeit unbeaufsichtigt oder mit übermäßigen Rechten agieren [6].

Bewährte Safeguards

Bereits lange vor dem Einsatz KI‑gestützter Entwicklungswerkzeuge haben sich in der Softwareentwicklung zahlreiche Safeguards etabliert, die darauf abzielen, Fehler, Sicherheitslücken und Qualitätsprobleme frühzeitig zu erkennen und zu vermeiden. Diese klassischen Maßnahmen bilden bis heute das Fundament sicherer Softwareentwicklung und behalten auch im Kontext moderner, KI‑unterstützter Entwicklungsprozesse ihre Relevanz. Ihr zentrales Ziel besteht darin, sicherheitsrelevante Aspekte systematisch in den Entwicklungsprozess zu integrieren und Risiken möglichst frühzeitig zu adressieren.

Eine der bekanntesten und zugleich wirkungsvollsten klassischen Safeguards ist das manuelle Code‑Review [10]. Dabei wird neu geschriebener oder veränderter Code vor der Integration in den Hauptentwicklungszweig von mindestens einer weiteren Person überprüft. Ziel dieser Reviews ist es, logische Fehler, Sicherheitslücken sowie Verstöße gegen Coding‑ und Architekturstandards frühzeitig zu identifizieren. Code‑Reviews ermöglichen es zudem, implizites Wissen über das System zu teilen, und tragen zur Vereinheitlichung von Entwicklungspraktiken innerhalb eines Teams bei. Aus sicherheitstechnischer Sicht stellen sie einen besonders wertvollen Safeguard dar, da menschliche Prüfer kontextabhängige Probleme erkennen können, die automatisierte Werkzeuge häufig übersehen.

Ergänzend zu manuellen Reviews kommen automatisierte Analyse‑ und Testverfahren zum Einsatz, die eine skalierbare und reproduzierbare Überprüfung des Codes ermöglichen [10] – [12]. Automatisierte Tests, insbesondere Unit‑ und Integrationstests, stellen sicher, dass einzelne Komponenten sowie deren Zusammenspiel korrekt funktionieren und dass Änderungen keine unbeabsichtigten Nebenwirkungen verursachen. Diese Tests tragen wesentlich zur Stabilität und Wartbarkeit von Softwaresystemen bei und sind ein fester Bestandteil moderner Entwicklungsprozesse.

Eine besondere Rolle innerhalb der klassischen Safeguards nehmen automatisierte Sicherheitsanalysen ein, die den Quellcode oder das Laufzeitverhalten von Anwendungen systematisch auf Schwachstellen untersuchen. Zu diesen Verfahren zählen insbesondere Static Application Security Testing (SAST) und Dynamic Application Security Testing (DAST), die im Folgenden näher betrachtet werden.

Code Analyse Tools

SAST bezeichnet die statische Analyse von Quellcode oder kompilierten Artefakten, ohne dass die Anwendung ausgeführt wird [13]. Ziel von SAST‑Analysen ist es, potenzielle Sicherheitslücken möglichst früh im Entwicklungsprozess zu identifiziere

Typische Schwachstellen, die durch SAST‑Werkzeuge erkannt werden können, sind unter anderem SQL‑Injection‑Risiken, unsichere Fehlerbehandlung, hardcodierte Credentials oder Verstöße gegen Secure‑Coding‑Richtlinien. Aufgrund ihrer frühen Einsetzbarkeit lassen sich SAST‑Analysen gut in Continuous‑Integration‑Pipelines integrieren und sie liefern zeitnahe Rückmeldungen an Entwickler.
Zu den verbreiteten SAST‑Werkzeugen zählen unter anderem SonarQube [14] und Checkmarx [15]. Diese Tools analysieren den Quellcode automatisiert anhand vordefinierter Regelwerke und erzeugen strukturierte Berichte über erkannte Schwachstellen. Ein wesentlicher Vorteil von SAST liegt in der hohen Skalierbarkeit und der Möglichkeit, große Codebasen kontinuierlich zu überprüfen. Gleichzeitig ist zu beachten, dass SAST‑Analysen kontextabhängige Laufzeitprobleme nicht erkennen können und häufig eine gewisse Anzahl an Falsch‑Positiven erzeugen.

DAST verfolgt einen komplementären Ansatz und untersucht das Sicherheitsverhalten einer Anwendung während ihrer Ausführung [16]. DAST‑Werkzeuge interagieren mit der laufenden Anwendung und simulieren reale Angriffsszenarien, indem sie gezielt manipulierte Eingaben verwenden oder bekannte Angriffsmuster anwenden. Auf diese Weise lassen sich insbesondere Laufzeitschwachstellen wie Cross‑Site-Scripting, fehlerhafte Authentifizierungsmechanismen oder unsichere Konfigurationen identifizieren.

Bekannte DAST‑Werkzeuge sind beispielsweise OWASP ZAP [17] oder Burp Suite [18]. Diese Werkzeuge ermöglichen sowohl automatisierte Scans als auch manuelle Analysen und werden häufig in späteren Entwicklungsphasen oder in dedizierten Test‑ und Staging‑Umgebungen eingesetzt. Der Vorteil von DAST liegt in der realitätsnahen Bewertung der Anwendungssicherheit, während die eingeschränkte Codeabdeckung als zentrale Limitation gilt.

Die Kombination von SAST und DAST stellt einen bewährten klassischen Safeguard dar, da beide Ansätze unterschiedliche Perspektiven auf die Sicherheit eines Softwaresystems einnehmen. Während SAST frühzeitig strukturelle Schwachstellen im Code identifiziert, ermöglicht DAST die Überprüfung des tatsächlichen Laufzeitverhaltens. In Kombination mit manuellen Code‑Reviews bilden diese Verfahren eine solide Grundlage klassischer Secure‑Development‑Praktiken.

Ein weiterer wesentlicher Bestandteil klassischer Code‑Analyse‑Werkzeuge ist die Software Composition Analysis (SCA), die sich auf die Analyse externer Abhängigkeiten und Bibliotheken konzentriert [19]. Moderne Softwaresysteme bestehen zu einem erheblichen Teil aus wiederverwendeten Open‑Source‑Komponenten, deren Sicherheit und Aktualität einen maßgeblichen Einfluss auf das Gesamtrisiko eines Systems haben. Ziel von SCA ist es, eingesetzte Abhängigkeiten automatisiert zu identifizieren und mit bekannten Schwachstellen, etwa aus öffentlich zugänglichen Datenbanken wie der National Vulnerability Database (NVD), abzugleichen.

Im Kontext der KI‑gestützten Softwareentwicklung gewinnt SCA zusätzlich an Bedeutung, da KI‑basierte Entwicklungswerkzeuge häufig externe Bibliotheken vorschlagen oder in generierten Code integrieren, ohne deren Sicherheitsstatus oder Wartungszustand zu berücksichtigen. Dadurch steigt das Risiko, veraltete oder verwundbare Komponenten unbewusst in ein System zu übernehmen. SCA‑Werkzeuge ermöglichen es, diese Risiken frühzeitig zu erkennen und gezielt zu adressieren, beispielsweise durch das Identifizieren bekannter Sicherheitslücken oder lizenzrechtlicher Probleme.
Zu den verbreiteten SCA‑Werkzeugen zählen unter anderem OWASP Dependency‑Check [20] und Dependabot [21]. Diese Tools lassen sich in Build‑ und CI/CD‑Prozesse integrieren und liefern kontinuierliche Rückmeldungen über den Sicherheitszustand verwendeter Abhängigkeiten.

In der Praxis werden klassische Analyseverfahren wie SAST, DAST und SCA zunehmend in integrierten Sicherheitsplattformen zusammengeführt. Werkzeuge wie Veracode [22], AccuKnox [23], SOOS [24] oder Aikido [25] bündeln unterschiedliche Analyseansätze und ermöglichen eine zentrale, automatisierte Bewertung des Sicherheitszustands von Anwendungen. Diese Plattformen bauen auf etablierten, klassischen Safeguards auf und erweitern sie um eine verbesserte Integration in CI/CD‑Pipelines sowie eine konsolidierte Ergebnisdarstellung.
Gerade im Kontext der KI‑gestützten Softwareentwicklung bieten solche integrierten Werkzeuge einen besonderen Mehrwert, da sie große Mengen an manuell oder automatisiert erzeugtem Code kontinuierlich analysieren können. Durch die Kombination von Code‑, Laufzeit‑ und Abhängigkeitsanalysen tragen sie dazu bei, Sicherheitsrisiken frühzeitig zu identifizieren und die Auswirkungen von KI‑basierter Codegenerierung kontrollierbar zu machen.

Weitere klassische Safeguards

Neben technischen Analysewerkzeugen existieren zahlreiche klassische Safeguards organisatorischer und prozessualer Natur, die einen wesentlichen Beitrag zur Sicherheit von Softwaresystemen leisten. Diese Maßnahmen zielen darauf ab, sicherheitsrelevante Fehler bereits auf Ebene von Prozessen, Verantwortlichkeiten und Entwicklungspraktiken zu vermeiden.

Ein zentraler Bestandteil solcher Safeguards sind Secure‑Coding‑Richtlinien, die festlegen, wie sicherheitskritische Funktionen implementiert werden sollen und welche Programmiermuster zu vermeiden sind [11], [12]. Diese Richtlinien schaffen ein gemeinsames Verständnis von Sicherheit innerhalb von Entwicklungsteams und tragen zur konsistenten Umsetzung sicherer Programmierpraktiken bei. Ergänzend dazu stellt das Vier‑Augen‑Prinzip, etwa in Form verpflichtender Code‑Reviews oder Freigabeprozesse, einen wichtigen organisatorischen Safeguard dar.

Darüber hinaus spielen Zugriffs‑ und Berechtigungskonzepte eine entscheidende Rolle [12]. Durch das Prinzip der minimalen Rechtevergabe wird sichergestellt, dass Entwickler, Werkzeuge und Systeme nur über jene Zugriffsrechte verfügen, die für ihre jeweilige Aufgabe notwendig sind. Dies reduziert das Risiko unbeabsichtigter oder missbräuchlicher Änderungen erheblich. Sicherheitsaspekte werden zudem häufig im Rahmen eines Secure Software Development Lifecycle systematisch in alle Phasen der Softwareentwicklung integriert, von der Anforderungsanalyse über die Implementierung bis hin zum Betrieb.

Abgerundet werden diese klassischen Safeguards durch Schulungen und Sensibilisierungsmaßnahmen, die das Sicherheitsbewusstsein von Entwicklern stärken [10], [12]. Gerade im Kontext zunehmend automatisierter und KI‑gestützter Entwicklungsprozesse bleiben solche Maßnahmen unverzichtbar, da sie sicherstellen, dass Sicherheitsverantwortung nicht ausschließlich an technische Werkzeuge delegiert wird.

Obwohl diese klassischen Safeguards eine solide Grundlage bilden, stoßen sie im Kontext KI‑gestützter Softwareentwicklung an ihre Grenzen. Die in Kapitel 2 beschriebenen Risiken wie Agent Goal Hijack oder Tool Misuse erfordern zusätzliche Schutzmaßnahmen, die über traditionelle Ansätze hinausgehen. Insbesondere die Autonomie von KI‑Agenten, die hohe Geschwindigkeit der Codegenerierung sowie die dynamische Tool‑Nutzung schaffen neue Angriffsvektoren, die klassische Verfahren allein nicht adäquat adressieren können. Das folgende Kapitel stellt daher Safeguards vor, die speziell auf diese KI‑spezifischen Herausforderungen ausgerichtet sind.

KI-spezifische Safeguards

Die folgende Sektion befasst sich mit einer Auswahl an Safeguards, die sich durch die aktuelle Entwicklung im KI‑Umfeld angepasst haben oder neu aufgekommen sind. Dabei wird sowohl die Integration von LLMs in bewährte Praktiken wie bspw. dem Code-Review oder Test-Driven Development (TDD) beleuchtet, als auch Safeguards gegen in Kapitel 2 benannte Risiken vorgestellt. Insbesondere adressieren Sandboxing-Technologien die Risiken ASI02 (Tool Misuse) und ASI05 (Unexpected Code Execution), während Hook-basierte Prozesskontrollen ASI03 (Identity and Privilege Abuse) entgegenwirken, indem sie destruktive Aktionen blockieren. KI-gestützte Code-Reviews können indirekt ASI01 (Agent Goal Hijack) abschwächen, indem sie manipulierten oder fehlerhaften Code vor der Integration erkennen. In den jeweiligen Sektionen wird herausgearbeitet, inwiefern die Methodik einen Safeguard darstellt.

KI-basiertes Code-Review

Eine der ersten praxisnahen Implementierungen von KI-gestütztem Code-Review findet sich in der Integration mit GitHub Actions. Oliveira et al. entwickelten einen Ansatz, bei dem ein speziell konzipierter Prompt mit GitHub-Actions verknüpft wird [26]. Sobald ein Pull-Request genehmigt wird, löst das System automatisch einen Code-Review über die OpenAI GPT-API aus. Entwickler müssen dabei weder ihren bestehenden Workflow ändern noch neue Tools erlernen [26]. Sun et al. führten eine umfangreiche empirische Studie zu 16 beliebten KI-basierten Code-Review-Aktionen auf GitHub durch und analysierten mehr als 22.000 Review-Kommentare in 178 Repositories [27]. Ihre Ergebnisse zeigen, dass die Effektivität dieser Tools stark variiert: Kommentare, die prägnant sind, Code-Snippets enthalten und manuell ausgelöst werden, führen mit höherer Wahrscheinlichkeit zu Codeänderungen [27].

Generell sind Code-Reviews eine etablierte Praxis in der Softwareentwicklung, die mit Codequalität sowie interpersonellen Vorteilen verbunden ist [28]. Entwickler verbringen zwischen 10% und 20% ihrer Arbeitszeit mit Code-Reviews, was bei geschätzten 28 Millionen Softwareentwicklern täglich 22 bis 44 Millionen Stunden entspricht [28]. Die Motivation für Code-Review umfasst laut Bacchelli und Bird nicht nur die Fehlerfindung und Codeverbesserung, sondern auch Wissenstransfer, Team-Awareness und geteilte Code-Ownership [28]. Mindestens die Hälfte dieser Motivationen betrifft nicht direkt die Codequalität, sondern interpersonelle Vorteile.

Mit der zunehmenden Verfügbarkeit leistungsfähiger KI-Modelle wächst das Interesse an automatisierten Code-Reviews. Verschiedene Ansätze wurden entwickelt, darunter LLaMA-Reviewer zur Automatisierung von Code-Review-Aufgaben und CodeAgent, bei dem mehrere Agenten zusammenarbeiten, um Codequalitätsprobleme zu finden [28]. Obwohl diese Ansätze möglicherweise die Codequalität sicherstellen können, besteht das Risiko, dass die interpersonellen Vorteile des Code-Reviews verloren gehen [28]. Heander et al. schlagen daher eine Vision vor, bei der KI zur Unterstützung des Code-Reviews eingesetzt wird, anstatt die Aktivität vollständig zu automatisieren [28].

Rasheed et al. präsentieren ein LLM-basiertes Multi-Agenten-System für Code-Reviews [29]. Im Gegensatz zu traditionellen statischen Code-Analyse-Tools können ihre LLM-basierten Agenten potenzielle zukünftige Risiken im Code antizipieren [29]. Das System unterteilt den Review-Prozess in spezialisierte Aufgaben: Ein Agent analysiert den Quellcode auf Bugs und Abweichungen von Codierungsstandards, ein weiterer identifiziert Code Smells und schlägt Refactoring-Strategien vor, und ein dritter optimiert Effizienz und Lesbarkeit des Codes [29]. Die vorläufige Evaluation zeigt, dass dieses System Probleme erkennen kann, die traditionelle statische Analysetools übersehen oder nur mit begrenzter Erklärung melden [29]. LLM-basiertes Reasoning kann bestehende regelbasierte Ansätze ergänzen, indem es kontextbewusste Einblicke liefert.

Allerdings zeigen sich auch Grenzen: Während KI-gestützte Reviews mehr Probleme bei Dokumentation und formalen Checks identifizieren können, sind menschliche Reviewer überlegen bei der Erkennung struktureller und logischer Probleme [26]. Dies liegt daran, dass menschliche Reviewer ein tieferes Verständnis des Projektkontexts haben. Das Feedback von KI-Systemen kann zu generisch ausfallen, wenn das System nicht den gesamten Projektquellcode erhält [26]. Die empirische Analyse von Sun et al. bestätigt diese Einschränkungen: Während 60% der menschlichen Review-Kommentare zu Codeänderungen führten, lag die Rate bei KI-generierten Kommentaren je nach Tool nur zwischen 0,9% und 19,2% [27]. Eine KI-unterstützte Code-Review-Plattform sollte daher alle positiven Effekte des Code-Reviews verstärken, wobei die Entscheidung über Annahme oder Ablehnung des Codes beim Menschen bleiben sollte [28].

Ein besonderer Anwendungsfall für KI-gestütztes Code-Review findet sich in der Hochschulbildung. Studierende fühlen sich oft unwohl dabei, ihre Arbeit zu teilen oder Feedback an Kommilitonen zu geben, aufgrund von Bedenken bezüglich Programmiererfahrung, Validität und Fairness [26]. Durch die Delegation von Review-Aufgaben an KI-Tools können Studierende ihre Coding-Praktiken überprüfen und reflektieren, ohne sich exponiert zu fühlen. In einer Studie mit 80 Informatikstudenten steigerte der KI-gestützte Review-Prozess das Engagement deutlich: 70% aller Reviews erfolgten mit genAI, und die automatisierten Reviews identifizierten durchschnittlich 26,7 Probleme, verglichen mit 9,5 bei manuellen Peer-Reviews (p-Wert=0,01) [26]. Einige Teams führten sogar freiwillig mehrere KI-Reviews durch. Das KI-Feedback fördert eine dynamische Lernumgebung, die Studierende ermutigt, identifizierte Probleme zu verstehen, zu diskutieren und gemeinsam Lösungen zu erarbeiten [26].

Sandboxing im KI-Kontext

Eine Sandbox ist eine kontrollierte, isolierte Umgebung, in der Softwareprogramme sicher analysiert und getestet werden können [30]. Ziel einer Sandbox ist es, potenziell schädlichen oder fehlerhaften Code auszuführen, ohne dabei das Host-System zu gefährden. Dazu wird der Zugriff auf das zugrunde liegende Dateisystem, die Registry, Netzwerkressourcen und Hardwarekomponenten oder andere kritische Systemvariablen stark eingeschränkt, überwacht oder vollständig virtualisiert.

Die Sandbox wirkt auf das Programm wie ein vollständiges, unbeeinträchtigtes Betriebssystem. Diese realitätsnahe Simulation ist essenziell beim Testen von potenzieller Malware, da Schadprogramme häufig ihr Verhalten verstellen oder vollständig einstellen können, wenn sie eine Analyseumgebung erkennen. Eine transparente Ausführungsumgebung ermöglicht es daher, das natürliche Verhalten der Software zu überprüfen.

Der Einsatz von Sandboxes ist in der Informationstechnologie (IT) weit verbreitet. In der Softwareentwicklung werden Sandboxes häufig eingesetzt, um neuen oder veränderten Code zu testen, bevor dieser in das Produktivsystem hinzugefügt wird. Dadurch lassen sich funktionale Fehler und Inkompatibilitäten frühzeitig entdecken, ohne das Produktivsystem zu gefährden.

In der Cyber-Security kann Code innerhalb einer Sandbox intensiv auf Schwachstellen oder sicherheitsrelevante Eigenschaften untersucht werden. Verdächtiger oder unbekannter Code kann so kontrolliert ausgeführt werden, um mögliche Angriffsvektoren zu erkennen.

Im Bereich der IT-Forensik werden Sandboxes vor allem zur Analyse von Schadcode eingesetzt. Bekannte Malware wird in einer gesicherten Umgebung ausgeführt, um deren Verhalten zu analysieren. Dabei wird vor allem auf mögliche Verbreitungsmechanismen, Schwachstellennutzung, Kommunikationsmuster sowie Hinweise auf eine mögliche Herkunft geachtet.

In der KI-unterstützten Softwareentwicklung gibt es mehrere Anwendungsbereiche für Sandbox-Technologien. Wie bereits beschrieben eignen sich Sandboxes besonders zum isolierten Testen von neuem oder geändertem Code. Daher eignen sich diese besonders beim Einsatz von Code-Generierungsassistenten. Der generierte Code kann so zunächst in einer isolierten Umgebung ausgeführt und geprüft werden, bevor dieser in die Produktivumgebung integriert wird. So lassen sich funktionale Fehler sowie potenzielle Schwachstellen frühzeitig erkennen. Darüber hinaus ermöglichen Sandboxes das Integrieren automatischer Tests sowie den Einsatz von statischen und dynamischen Analysetools zur Überprüfung von sicherheitsrelevanten Eigenschaften. Das trägt zur Reduzierung des Risikos von Sicherheitslücken durch fehlerhaften oder unzureichend geprüften Code bei.

Weiter können Sandboxes dazu dienen, den Zugriff von KI-Applikationen auf interne Systemressourcen gezielt einzuschränken. KI-Systeme, insbesondere generative Modelle und autonome Agenten, arbeiten häufig mit vollem Zugriff auf Systemressourcen, externen Schnittstellen oder sensiblen Daten, wenn diese nicht entsprechend geschützt werden, um ihre Funktionalität zu erfüllen. Dieser Zugriff kann jedoch schnell zu unerwünschten Nebeneffekten führen, etwa der Preisgabe sensibler Daten (Data Leakage) oder zur unbeabsichtigten Manipulation interner Systeme. Mit Sandboxes lässt sich das Prinzip der geringsten Privilegien konsequent umsetzen. Zugriffsrechte lassen sich in einer Sandbox sehr spezifisch definieren, wodurch sichergestellt werden kann, dass KI-Applikationen nur auf die Ressourcen Zugriff haben, die für den Anwendungsbereich zwingend notwendig sind. Besonders im Kontext von KI-Applikationen, die eigenständig Aktionen durchführen oder Entscheidungen treffen dürfen, ist diese Form der Isolation essenziell.

Darüber hinaus sind Sandboxes ein wirksamer Sicherheitsmechanismus gegen KI-spezifische Angriffe wie Prompt-Injektion oder unerwünschte Kontextmanipulation. Im Kontext der in Kapitel 2 beschriebenen OWASP-Risiken adressieren Sandboxes insbesondere ASI02 (Tool Misuse and Exploitation), indem sie den Zugriff von KI-Agenten auf kritische Systemressourcen einschränken, sowie ASI05 (Unexpected Code Execution), indem sie die Auswirkungen von unautorisiert ausgeführtem Code isolieren. Enthält eine Anwendung beispielsweise einen KI-Chatbot, kann dieser innerhalb einer Sandbox ausgeführt werden, die den Zugriff auf interne Logik und sensible Schnittstellen strikt begrenzt. So hat auch ein erfolgreicher Angriff eine stark begrenzte Auswirkung innerhalb der eingegrenzten Ausführungsumgebung.

Der Einsatz von Sandboxes hat eine niedrige Einstiegsschwelle und erfordert in den meisten Fällen keine spezielle Sicherheitsinfrastruktur. Moderne Entwicklungsumgebungen und Cloud-Plattformen stellen bereits integrierte Mechanismen zur Verfügung, mit denen eine isolierte Ausführungsumgebung realisiert werden kann. So liefert beispielsweise das Windows-Betriebssystem ab Windows 10 direkt eine integrierte Sandbox mit [31]. Diese simuliert entsprechend ein funktionsfähiges Windows-Betriebssystem und kann von jedem Nutzer eingesetzt werden. In Cloud-Umgebungen kann man überwiegend selbst vorgeben, was für ein Betriebssystem simuliert werden soll, was natürlich auch das Testen für verschiedene Systeme leicht ermöglicht. Daneben bieten auch viele Container-Technologien wie Docker standardmäßig die Trennung von Systemressourcen an. Auch viele CI/CD-Pipelines bieten eine native Isolierung der Testumgebung an, sodass Sandbox-Konzepte ohne signifikanten Mehraufwand in den Entwicklungsprozess integriert werden können.

Die Wirksamkeit von Sandboxes gilt als bewährtes und effektives Mittel zur Begrenzung potenzieller Schäden durch fehlerhaften Code. Durch die Isolation wird die Angriffsfläche stark reduziert, da selbst im Falle eines erfolgreichen Angriffs die Auswirkung auf das System stark begrenzt bleibt. Insbesondere mit ergänzenden Sicherheitsmaßnahmen wie Monitoring, Logging und Zugriffskontrollen bieten Sandboxes einen hohen Schutzgrad.
Gleichzeitig ist festzuhalten, dass Sandboxes keine vollständige Sicherheitsgarantie bieten.
Die Idee der Sandboxes ist keine neue Erfindung und existiert schon seit den 1970ern. Somit hatten auch Cyberkriminelle genug Gelegenheit, sich mit dieser Technologie auseinanderzusetzen, sodass es auch Schadcode geben kann, der eine solche isolierte Umgebung erkennen und umgehen kann [31]. Zudem adressieren Sandboxes primär die Ausführungsumgebung, nicht jedoch die logische Korrektheit oder ethische Unbedenklichkeit von KI-generierten Entscheidungen. Aus diesem Grund sollten Sandbox-Technologien nicht als alleinige Sicherheitsmaßnahme verstanden werden, sondern als Bestandteil eines mehrschichtigen Sicherheitskonzepts (Defense in Depth).

Zusammenfassend ermöglichen Sandbox-Technologien eine strikte Trennung zwischen KI-Komponenten und kritischen Systemressourcen. Sie reduzieren die potenzielle Schadwirkung von fehlerhaftem oder manipuliertem KI-Verhalten und stellen damit einen wesentlichen Teil moderner Safeguards in der KI-unterstützten Softwareentwicklung dar.

Prozessbezogene Safeguards für KI-gestützte Entwicklung

Die Studie von Włodarski et al. zeigt, dass die konsequente Einhaltung eines strukturierten Softwareentwicklungsprozesses signifikant bessere Projektergebnisse liefert als eine Ad-hoc-Vorgehensweise ohne definierten Prozess [32]. Teams mit etablierten Prozessen erreichten höhere Qualitätsstandards und bessere Sicherheitsmerkmale. Gleichzeitig betont das Agile Manifest, dass “Reagieren auf Veränderung” wichtiger ist als “das Befolgen eines Plans” [33], weshalb der gewählte Prozess flexibel an projektspezifische Anforderungen anpassbar sein muss, anstatt starr befolgt zu werden.

Architektureinhaltung

Eine gute Softwarearchitektur bildet die strukturelle Grundlage eines Softwaresystems und ist entscheidend für dessen Wartbarkeit, Erweiterbarkeit und Sicherheit [34], [35]. Architekturentscheidungen legen fest, welche Komponenten wie miteinander interagieren, wie Verantwortlichkeiten verteilt sind und welche Abhängigkeiten zulässig sind. Das ermöglicht, die Komplexität großer Softwaresysteme in den Griff zu bekommen und Änderungen kontrolliert umzusetzen.

Der vermehrte Einsatz von KI-gestützten Entwicklertools hat einen relevanten Einfluss auf die Einhaltung von softwarearchitektonischen Entscheidungen. Während KI-generierter Code die Entwicklung beschleunigen kann, so besteht doch die Gefahr für sich einschleichende Architekturfehler, besonders bei großen Codemengen [36].
KI-generierter Code basiert meist auf lokalen Kontexten und statischen Mustern. Daher ist Code in der Regel syntaktisch korrekt und funktional plausibel, jedoch wird dabei selten die übergeordnete Architektur mitbeachtet.
Im klassischen Entwicklungsprozess wird die Einhaltung von Architekturentscheidungen größtenteils mit Dokumentation und Code-Reviews sichergestellt. Mit zunehmendem KI-Einsatz stoßen solche Maßnahmen allerdings an ihre Grenzen, da die Menge an generiertem Code nicht mehr zu bewältigen ist und Architekturverletzungen nicht immer offensichtlich sind. Daher vermehrt sich der Einsatz von technischen Werkzeugen zur automatisierten und kontinuierlichen Prüfung der Einhaltung von Architekturentscheidungen. Einen wesentlichen Bestandteil bilden dabei die statischen Analysewerkzeuge. Diese Werkzeuge überprüfen den Code unabhängig von dessen Entstehung und ermöglichen es, die strukturellen Eigenschaften des Systems zu überprüfen. Statische Architekturprüfungen können beispielsweise unerlaubte Abhängigkeiten zwischen Modulen oder Architekturschichten erkennen, zyklische Abhängigkeiten erkennen oder Verstöße gegen definierte Architekturregeln aufdecken. Da diese Analysen automatisch durchgeführt werden, lassen sich diese auch auf große Codebasen anwenden.

Ein weit verbreitetes Werkzeug dieser Art ist ArchUnit [37]. Dies ist eine Java-basierte Bibliothek, mit deren Hilfe Architekturentscheidungen als automatische Tests definiert werden können. Die Regeln beschreiben dabei strukturelle Eigenschaften des Systems wie z. B. Abhängigkeiten zwischen Pakten, die Systemarchitektur oder die Trennung von fachlicher Logik und technischer Infrastruktur. Da ArchUnit-Tests Teil der regulären Test-Suite sind, werden die Tests mit jedem Build-Prozess ausgeführt und werden so regelmäßig angewendet. Mit diesem Tool werden Architekturentscheidungen nicht nur dokumentiert, sondern technisch verbindlich gemacht.

Ein weiteres beliebtes Werkzeug zur architektonischen Überprüfung ist SonarQube [14]. Im Gegensatz zu ArchUnit verfolgt SonarQube allerdings keinen testbasierten, sondern einen analyse- und regelbasierten Ansatz. Das Werkzeug überprüft den Code mit statischen Analysen auf eine Vielzahl von Qualitäts- und Sicherheitsaspekten, darunter auch architektonische Code-Smells wie zyklische Abhängigkeiten, unerlaubte Kopplungen oder Verstöße gegen Modularisierungsprinzipien. Da diese Analysen technologieübergreifend erfolgen, lassen sie sich in jeden Entwicklungsprozess integrieren.

Im Gegensatz zu ArchUnit, mit dem die Überprüfung aufgrund explizit definierter, projektspezifischer Architekturregeln erfolgt, verfolgt SonarQube hingegen einen generischen, heuristikbasierten Ansatz, bei dem der Code auf allgemein anerkannte Qualitäts- und Architekturprinzipien analysiert wird. Dieser Ansatz ermöglicht das Auffinden von strukturellen Problemen und Auffälligkeiten, die bei der Definition von Architekturregeln möglicherweise übersehen wurden.

Während ArchUnit also der Einhaltung der intendierten Architektur dient, dient SonarQube als ergänzendes Frühwarnsystem, das potenzielle Architekturprobleme unabhängig von der ursprünglichen Architekturdefinition entdeckt.

Die Integration dieser und ähnlicher Werkzeuge ermöglicht eine frühzeitige Entdeckung architektonischer Verstöße. Auf diese Weise kann die Einhaltung schon während der Entwicklung automatisch sichergestellt werden. Das reduziert nicht nur das Einschleichen langfristiger Architekturdrifts, sondern ermöglicht auch eine bessere Wartbarkeit und Weiterentwicklung des Softwaresystems.

Prozesseinhaltung am Beispiel

Moderne KI-Coding-Assistenten wie Claude Code bieten ein Hook-System, das die mechanische Durchsetzung von Entwicklungsprozessen ermöglicht. Hooks sind Shell-Befehle, die zu bestimmten Ereignissen automatisch ausgeführt werden, beispielsweise vor der Ausführung eines Tools, bei Eingabe eines Nutzerprompts oder beim Starten einer Session. Diese Hooks können Aktionen blockieren und dem Agenten eine Begründung zurückgeben, wodurch prozessuale Vorgaben technisch erzwungen werden, anstatt sich auf Anweisungen in Textdateien zu verlassen [38].

Ein konkretes Beispiel für einen solchen Safeguard ist der Git Safety Guard [39]. Dieser Hook wurde nach einem realen Vorfall entwickelt, bei dem ein KI-Agent den Befehl git checkout — auf Dateien mit stundenlanger, nicht committeter Arbeit ausführte. Der Guard analysiert jeden Bash-Befehl vor der Ausführung mittels Regex-Pattern-Matching und blockiert destruktive Operationen wie git reset –hard, git clean -f, rm -rf oder git push –force. Gleichzeitig erlaubt er sichere Varianten wie git checkout -b (Branch erstellen) oder git clean -n (Dry-Run). Der blockierte Agent erhält eine Erklärung und muss den Nutzer um manuelle Ausführung bitten.

Ein weiteres Beispiel ist TDD Guard, ein Hook zur automatisierten Durchsetzung von Test-Driven Development (TDD) [40]. TDD ist eine seit über zwei Jahrzehnten etablierte Entwicklungsmethodik, die durch den Red-Green-Refactor-Zyklus charakterisiert ist: Erst wird ein fehlschlagender Test geschrieben, dann die minimale Implementierung zur Erfüllung des Tests, und schließlich wird der Code refaktoriert [41]. Wenn der KI-Agent versucht, Implementierungscode ohne fehlschlagende Tests zu schreiben oder über die aktuellen Testanforderungen hinaus zu implementieren, blockiert TDD Guard die Aktion und erklärt, welcher Schritt im TDD-Zyklus als nächstes erforderlich ist. Das Tool unterstützt verschiedene Programmiersprachen und Test-Frameworks und integriert sich nahtlos in den bestehenden Entwicklungsworkflow. Der besondere Vorteil dieses Ansatzes liegt darin, dass Entwickler keine völlig neue Methodik erlernen müssen. Stattdessen wird ein bewährter Prozess nun auch auf die Zusammenarbeit mit KI-Agenten übertragen, was die Einstiegshürde für sicheres KI-gestütztes Entwickeln deutlich senkt.

Diese Beispiele verdeutlichen, wie Hook-basierte Safeguards prozessuale Vorgaben von optionalen Richtlinien zu technisch durchgesetzten Regeln umwandeln. Dies ist besonders relevant, da KI-Agenten Anweisungen in Dokumenten wie AGENTS.md zwar lesen, aber nicht zuverlässig befolgen. Dieser Ansatz bietet hingegen eine deterministische Barriere.

Fazit und Ausblick

Die rasante Verbreitung KI-gestützter Werkzeuge in der Softwareentwicklung verändert sowohl Entwicklungsprozesse als auch die Art der entstehenden Risiken grundlegend. Wie in dieser Arbeit gezeigt wurde, führt insbesondere der Einsatz autonomer KI-Agenten zu neuen sicherheitsrelevanten Bedrohungen, die über klassische Schwachstellen hinausgehen. Die von OWASP identifizierten Risiken für agentische Anwendungen verdeutlichen, dass Autonomie, persistenter Kontext, Tool-Nutzung und unzureichende Kontrolle in Kombination eine deutlich vergrößerte Angriffsfläche schaffen. Angriffe wie Agent Goal Hijack, Tool Misuse oder Identity and Privilege Abuse zeigen exemplarisch, dass KI-Agenten nicht zwangsläufig „fehlerhaft“ handeln müssen, um sicherheitskritische Auswirkungen zu verursachen, sondern regelkonform agieren können, während sie dennoch gegen die ursprüngliche Intention des Nutzers verstoßen.

Vor diesem Hintergrund wurde in der Arbeit herausgearbeitet, dass klassische Safeguards der Softwareentwicklung weiterhin eine unverzichtbare Grundlage darstellen. Maßnahmen wie manuelle Code-Reviews, automatisierte Tests, statische und dynamische Code-Analyse sowie Software-Composition-Analysis bilden auch im KI-Kontext das Fundament sicherer Softwareentwicklung. Gleichzeitig zeigt sich jedoch, dass diese etablierten Verfahren allein nicht ausreichen, um die spezifischen Risiken KI-gestützter Entwicklung adäquat zu adressieren. Insbesondere die hohe Geschwindigkeit und Menge KI-generierten Codes sowie die zunehmende Autonomie von KI-Agenten erfordern zusätzliche, gezielt angepasste Safeguards.

Die Analyse KI-spezifischer Safeguards hat gezeigt, dass sich bestehende Praktiken sinnvoll erweitern lassen. KI-gestützte Code-Reviews können klassische Reviews ergänzen, indem sie Entwickler entlasten und zusätzliche Perspektiven auf Codequalität und potenzielle Risiken liefern. Gleichzeitig bleibt die menschliche Kontrolle unverzichtbar, da zentrale Aspekte wie Systemverständnis, Architekturintention und Kontextbewertung weiterhin menschliche Stärken darstellen. Der Einsatz von Sandboxing wurde als besonders wirkungsvoller Safeguard identifiziert, um sowohl KI-generierten Code als auch KI-Agenten in isolierten Umgebungen auszuführen. Sandboxes ermöglichen es, funktionale Fehler, Sicherheitslücken und missbräuchliche Tool-Nutzung frühzeitig zu erkennen und die Auswirkungen erfolgreicher Angriffe stark zu begrenzen.

Ein weiterer wesentlicher Schwerpunkt der Arbeit lag auf Safeguards im Softwareentwicklungsprozess selbst. Die Durchsetzung von Architekturentscheidungen mithilfe statischer Analysewerkzeuge wie ArchUnit und SonarQube wurde als zentrale Maßnahme zur Vermeidung von Architekturdrift identifiziert, insbesondere bei wachsendem KI-Einsatz. Während ArchUnit die explizite und projektspezifische Durchsetzung intendierter Architekturregeln ermöglicht, fungiert SonarQube als ergänzendes Frühwarnsystem zur Identifikation generischer architektonischer Auffälligkeiten. Darüber hinaus zeigen Hook-basierte Mechanismen zur Prozesseinhaltung, wie etwa Git Safety Guard oder TDD Guard, dass sich auch methodische Vorgaben technisch erzwingen lassen. Solche Ansätze sind besonders relevant, da KI-Agenten textuelle Richtlinien nicht zuverlässig befolgen, technische Barrieren hingegen deterministisch wirken.

Zusammenfassend verdeutlicht diese Arbeit, dass der sichere Einsatz von KI in der Softwareentwicklung nicht durch einzelne Werkzeuge oder Maßnahmen gewährleistet werden kann. Vielmehr ist ein mehrschichtiges Safeguard-Konzept erforderlich, das klassische Sicherheitsmechanismen, KI-spezifische Schutzmaßnahmen sowie architektur- und prozessbezogene Kontrollen miteinander kombiniert. Safeguards müssen dabei nicht nur reaktiv auf neue Bedrohungen reagieren, sondern proaktiv in Entwicklungsprozesse integriert werden.

Der Ausblick zeigt, dass die Bedeutung von Safeguards in der KI-unterstützten Softwareentwicklung weiter zunehmen wird. Mit der fortschreitenden Entwicklung autonomer Agentensysteme und komplexer Mehragentenarchitekturen entstehen neue Herausforderungen, insbesondere im Bereich der Nachvollziehbarkeit, Verantwortlichkeit und Kontrolle. Zukünftige Forschungsarbeiten könnten sich verstärkt mit der automatisierten Ableitung technischer Prüfregeln aus Architekturentscheidungen oder der formalen Verifikation agentischer Verhaltensweisen befassen. Auch regulatorische Rahmenwerke wie der EU AI Act oder das NIST AI Risk Management Framework werden die Gestaltung sicherer KI-gestützter Entwicklungsprozesse maßgeblich beeinflussen.

Abschließend lässt sich festhalten, dass KI-gestützte Softwareentwicklung ein erhebliches Innovationspotenzial bietet, dessen sichere Nutzung jedoch nur durch konsequent eingesetzte und weiterentwickelte Safeguards möglich ist. Die in dieser Arbeit vorgestellten Konzepte und Werkzeuge zeigen, dass Sicherheit auch in hochautomatisierten Entwicklungsumgebungen erreichbar ist, sofern technische, organisatorische und menschliche Maßnahmen sinnvoll miteinander verzahnt werden.

Referenzen

[1] Handelsblatt,Das ewige Update: Immer neue Software und KI überfordern Betriebsräte, 2023 [Online]. Available: https://www.handelsblatt.com/technik/forschunginnovation/insight-innovation-das-ewige-update-immer-neue-softwareund-ki-ueberfordern-betriebsraete-/29367584.html [Accessed: Jan. 15, 2026]
[2] Bundesamt für Sicherheit in der Informationstechnik (BSI),Die Lage der IT-Sicherheit in Deutschland 2025, 2025 [Online]. Available: https://medien.bsi.bund.de/lagebericht/de/index.html [Accessed: Jan. 15, 2026]
[3] GitHub Blog,Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1, 2025 [Online]. Available: https://github.blog/news-insights/octoverse/octoverse-a-new-developerjoins-github-every-second-as-ai-leads-typescript-to-1/#h-generative-aiand-agentic-workflows-become-ordinary-engineering [Accessed: Jan. 21, 2026]
[4] C. Du, Q. Huang, T. Tang, Z. Wang, A. Nadkarni, and Y. Xiao, “Measuring the Security of Mobile LLM Agents under Adversarial Prompts from Untrusted Third-Party Channels” arXiv:2510.27140, 2025.
[5] D. Koch, A. Kohne, and N. Brechbühler, Prompt Engineering im Unternehmen – eine Einführung. Springer, 2025.
[6] OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications 2026” Ver. 2026, Dec. 2025. [Online]. Available: https://genai.owasp.org . [Accessed: Jan. 30, 2026].
[7] P. Reddy and A. S. Gujral, “EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System” in Proc. AAAI Symposium Series, vol. 7, no. 1, 2025, pp. 303–311.
[8] T. Shi, J. He, Z. Wang, H. Li, L. Wu, W. Guo, and D. Song, “Progent: Programmable privilege control for LLM agents” arXiv:2504.11703, 2025.
[9] AIMultiple Research, “Agentic AI for Cybersecurity: RealLife Use Cases & Examples” 2026. [Online]. Available: https://research.aimultiple.com/agentic-ai-cybersecurity/ . [Accessed: Jan. 28, 2026].
[10] paloalto, “Was ist der Secure Software Development Lifecycle (Secure SDLC)?”[Online] Available: https://www.paloaltonetworks.de/cyberpedia/what-is-secure-softwaredevelopment-lifecycle [Accessed: Feb. 10, 2026]
[11] Technische Hochschule Augsburg, SSichere Softwareentwicklung”[Online] Available: https://www.tha.de/Informatik/THAinnos/Sichere-Softwareentwicklung.html [Accessed: Feb. 10, 2026]
[12] Eunetic, SSichere Softwareentwicklung: Best Practices für eine sicherere digitale Welt”[Online] Available: https://www.eunetic.com/de/blog/sichere-softwareentwicklung-bestpractices-fur-eine-sicherere-digitale-welt [Accessed: Feb. 10, 2026]
[13] it-schulungen.com, “Was bedeutet Static Application Security Testing (SAST)?”[Online] Available: https://www.it-schulungen.com/wirueber-uns/wissensblog/was-bedeutet-static-application-security-testingsast.html [Accessed: Feb. 10, 2026]
[14] SonarQube, Available: https://www.sonarsource.com/products/sonarqube/ [Accessed: Feb. 10, 2025]
[15] Checkmarx [Online] Available: https://checkmarx.com [Accessed: Feb. 10, 2026]
[16] Check Point, “What is Dynamic Application Security Testing (DAST)? Available: https://www.checkpoint.com/de/cyber-hub/cloudsecurity/what-is-dynamic-application-security-testing-dast/ [Accessed: Feb. 10, 2026]
[17] wallarm, ÖWASP ZAP – Zed-Angriffs-Proxy”[Online] Available: https://lab.wallarm.com/what/owasp-zap-zed-angriffs-proxy/?lang=de [Accessed: Feb. 10, 2026]
[18] PortSwigger, “Burp Suite DAST”[Online] Available: https://portswigger.net/burp/dast [Accessed: Feb. 10, 2026]
[19] Check Point, “What is Software Composition Analysis (SCA)?”[Online] Available: https://www.checkpoint.com/de/cyber-hub/cloudsecurity/what-is-software-composition-analysis-sca/ [Accessed: Feb. 10, 2026]
[20] OWASP Dependency-Check [Online] Available: https://owasp.org/www-project-dependency-check/ [Accessed: Feb. 10, 2026]
[21] GitHub, “Dependabot”[Online] Available: https://github.com/dependabot [Accessed: Feb. 10, 2026]
[22] Aikido, The all-in-one Veracode alternative”[Online] Available: https://www.aikido.dev/comparison/veracode-alternative [Accessed: Feb. 10, 2026]
[23] Accuknox [Online] Available: https://accuknox.com [Accessed: Feb. 10, 2025]
[24] SOOS [Online] Available: https://soos.io [Accessed: Feb. 10, 2026]
[25] Aikido, SState-of-the-Art SAST, Built for Developers”[Online] Available: https://www.aikido.dev/scanners/static-code-analysis-sast [Accessed: Feb. 10, 2026]
[26] E. A. Oliveira, S. Rios, and Z. Jiang, ÄI-powered peer review process: An approach to enhance computer science students’ engagement with code review in industry-based subjects,ïn Proceedings ASCILITE 2023, Christchurch, 2023, pp. 184-194.
[27] Z. Sun, L. Yang, Y. Yu, and C. Shu, ÄI Code Review Bots on GitHub: Current Practices and Limitations,ärXiv preprint arXiv:2505.14721, 2025.
[28] L. Heander, E. Söderberg, and C. Rydenfält, SSupport, Not Automation: Towards AI-supported Code Review for Code Quality and Beyond, in 33rd ACM International Conference on the Foundations of Software Engineering (FSE Companion ’25), Trondheim, Norway, June 2025, pp. 591-595.
[29] Z. Rasheed, M. A. Sami, M. Waseem, K.-K. Kemell, X. Wang, A. Nguyen, K. Systä, and P. Abrahamsson, ÄI-powered Code Review with LLMs: Early Results,ärXiv preprint arXiv:2404.18496, 2025.
[30] Ausbildung in der IT,Sandbox, 2026 [Online]. Available: https://ausbildung-in-der-it.de/lexikon/sandbox [Accessed: Jan. 27, 2026]
[31] GData,Was ist eigentlich eine Sandbox?, 2026 [Online]. Available: https://www.gdata.de/ratgeber/was-ist-eigentlich-eine-sandbox [Accessed: Jan. 27, 2026]
[32] B. Włodarski, R. Sołtysiak, I. Nowakowski, and J. Miler, Impact of software development processes on the outcomes of student computing projects: A tale of two universities,”e-Informatica Software Engineering Journal, vol. 16, no. 1, pp. 220112, 2022.
[33] K. Beck et al., Manifesto for Agile Software Development,”2001. [Online]. Available: https://agilemanifesto.org/ [Accessed: Jan. 30, 2026].
[34] Software Quality Lab, SSoftware Architecture in Software Development”[Online]. Available: https://www.software-qualitylab.com/de/expertise/architecture-and-modelling [Accessed: Feb. 10, 2026]
[35] Appleute, Mobile Anwendungsarchitektur: Schichten, Typen, Prinzipien, Faktoren”[Online]. Available: https://www.appleute.de/app-entwicklerbibliothek/mobile-anwendungsarchitektur/ [Accessed: Feb. 10, 2026]
[36] Amasanti, Giorgio, and Jasmin Jahic. The impact of ai-generated solutions on software architecture and productivity: Results from a survey study. European Conference on Software Architecture. Cham: Springer Nature Switzerland, 2025.
[37] ArchUnit, Available: https://www.archunit.org [Accessed: Feb. 10, 2026]
[38] Anthropic, Claude Code Hooks,”2025. [Online]. Available: https://docs.anthropic.com/en/docs/claude-code/hooks [Accessed: Jan. 30, 2026].
[39] “Destructive Git Command Protection for Claude Code,”GitHub, [Online]. Available: https://github.com/anthropics/claudecode/discussions/1808 [Accessed: Jan. 30, 2026].
[40] N. Soderberg, TDD Guard: Automated Test-Driven Development enforcement for Claude Code,”2025. [Online]. Available: https://github.com/nizos/tdd-guard [Accessed: Jan. 30, 2026].
[41] K. Beck, Test Driven Development: By Example. Addison-Wesley Professional, 2002.