Security by Design für KI-Agenten: Wie autonome Systeme sicher in regulierte Prozesse eingebettet werden
KI-Agenten brauchen eigene Sicherheitsarchitekturen. Fünf Prinzipien, mit denen Unternehmen autonome Systeme absichern - von Least Privilege bis Incident Response.
Ein Agent, der autonom auf ein ERP zugreift und dort Aktionen auslöst, ist sicherheitstechnisch ein anderes Kaliber als ein Chatbot, der Fragen beantwortet. Trotzdem sehe ich in Projekten immer wieder dieselbe Schieflage: viel Investition in Funktionalität und Compliance, während die Sicherheitsarchitektur auf dem Niveau einer klassischen Webanwendung bleibt. Für einen Agenten, der Entscheidungen trifft und teilweise ohne Freigabe im Einzelfall handelt, reicht das meiner Einschätzung nach nicht.
Die eigentliche Sicherheitsfrage verschiebt sich nämlich: weg von „Kann das System gehackt werden?“ hin zu „Was darf ein kompromittierter Agent eigenständig tun, bevor jemand eingreift?“
Warum KI-Agenten ein eigenes Sicherheitsmodell brauchen
Klassische Anwendungen haben einen klar definierten Handlungsspielraum: Ein Nutzer löst eine Aktion aus, die Anwendung führt sie im vorgegebenen Rahmen aus. KI-Agenten durchbrechen dieses Muster. Sie interpretieren Eingaben, wählen Tools aus und orchestrieren mehrstufige Abläufe - mit einem Autonomiegrad, der je nach Einsatzszenario von reiner Assistenz bis zu eigenständiger Prozesssteuerung reichen kann.
Ein Agent auf Stufe L3 oder höher kann Entscheidungsketten anstoßen, die von außen schwer nachvollziehbar sind. Wird er kompromittiert - etwa durch Prompt Injection, manipulierte Datenquellen oder schlicht eine fehlerhafte Konfiguration - kann einiges an Schaden entstehen, bevor überhaupt jemand etwas bemerkt.
Fünf Prinzipien haben sich bei mir als Grundgerüst bewährt. Keines davon ist neu, und genau das ist der Punkt: Es geht nicht um exotische KI-Sicherheitstechnik, sondern darum, bewährte Prinzipien konsequent auf eine neue Systemklasse anzuwenden.
1. Least Privilege als Architekturprinzip
Jeder Agent bekommt nur die Berechtigungen, die er für seine aktuelle Aufgabe tatsächlich braucht. Klingt selbstverständlich - in der Praxis erhält der Agent beim Deployment aber häufig einen Service-Account mit breiten Rechten, weil die genauen Berechtigungen zum Einrichtungszeitpunkt schlicht noch nicht feststehen. Und dabei bleibt es dann.
Besser: Berechtigungen pro Aufgabe definieren und dynamisch zuweisen. Ein Agent, der Rechnungen prüft, braucht Lesezugriff auf das Buchhaltungssystem, aber keinen Schreibzugriff auf Stammdaten. Diese Granularität aufzusetzen kostet initial mehr - spätestens wenn der Agent in einen regulierten Prozess eingebettet wird, zahlt sie sich aber aus.
2. Eingabe-Validierung jenseits des Prompts
Prompt Injection ist das bekannteste Angriffsfeld bei LLM-basierten Systemen, aber längst nicht das einzige. KI-Agenten beziehen Daten aus externen Quellen: APIs, Datenbanken, Dokumente, E-Mails. Jede dieser Quellen ist ein möglicher Angriffsvektor - und in gewachsenen Landschaften sind es schnell mehr Quellen, als das Projektteam auf dem Schirm hat.
Die Absicherung beginnt dort, wo die Daten in den Agenten gelangen. Eingaben aus externen Quellen grundsätzlich als nicht vertrauenswürdig behandeln, ähnlich wie User Input in einer Webanwendung: validieren, bereinigen, und die Steuerungslogik sauber von den Daten trennen.
3. Sandboxing und Blast-Radius-Begrenzung
Ob ein ausreichend komplexes System irgendwann kompromittiert wird, lässt sich ehrlicherweise nicht ausschließen. Die Frage, die sich beeinflussen lässt, ist eine andere: Wie viel Schaden richtet ein einzelner kompromittierter Agent an, bevor die Isolation greift?
Sandboxing - die Isolation des Agenten in einer kontrollierten Umgebung - ist dafür das Mittel der Wahl. In der Praxis heißt das: Netzwerksegmentierung, begrenzte API-Scopes und definierte Timeouts für Agenten-Aktionen. Nichts davon ist KI-spezifisch, es wird bei Agenten nur schneller existenziell.
4. Audit-Trails als Sicherheitsinfrastruktur
Audit-Trails werden meist als Compliance-Anforderung verstanden, und das sind sie auch. Gleichzeitig sind sie eines der wirksamsten Sicherheitsinstrumente, die ein Agenten-Setup haben kann: Wenn jede Entscheidung protokolliert wird - welche Eingaben der Agent erhalten hat, welche Tools er gewählt hat, welche Aktionen er ausgelöst hat - lassen sich Anomalien erkennen, bevor daraus ein Vorfall wird.
Vorausgesetzt allerdings, die Logs werden auch gelesen. Ein Audit-Trail ohne Überwachung ist erstmal nur ein Archiv. Automatisierte Anomalieerkennung auf den Agenten-Logs wäre der logische nächste Schritt - in der Breite habe ich das bisher allerdings selten umgesetzt gesehen.
5. Incident Response für autonome Systeme
Was passiert, wenn ein KI-Agent sich unerwartet verhält? Die meisten Incident-Response-Pläne sind auf menschliche Akteure oder klassische IT-Systeme ausgelegt. Ein Agent, der eigenständig Prozesse steuert, braucht eigene Eskalationspfade - und die entstehen nicht von selbst.
Drei Fragen, die ich dafür in jedem Projekt geklärt haben will: Wer darf einen Agenten abschalten, und wie schnell geht das tatsächlich? Was passiert mit laufenden Prozessen, wenn er mitten in einer Aufgabe gestoppt wird? Und wie wird hinterher analysiert, ob der Agent korrekt gehandelt hat - oder ob eine Manipulation vorlag?
Sicherheit als Voraussetzung für Skalierung
Wer KI-Agenten über den Pilot hinaus skalieren will, kommt um eine durchdachte Sicherheitsarchitektur nicht herum. Die Regulierung weist mit dem EU AI Act und NIS2 zwar genau in diese Richtung - der eigentliche Grund ist aber ein geschäftlicher: Ein unsicherer Agent ist ein Risiko, das mit jedem zusätzlichen Einsatzszenario mitwächst.
Security by Design heißt dabei nicht, dass jeder Agent von Anfang an eine Festung sein muss. Es heißt, dass die Sicherheitsarchitektur von Anfang an mitgedacht wird - als Teil des Designs, nicht als nachträglich aufgesetzte Schicht. Der Unterschied klingt akademisch, entscheidet in der Praxis aber darüber, ob die Absicherung mit dem Agenten mitwächst oder ihm hinterherläuft.
Sie führen KI-Agenten ein und wollen die Sicherheitsarchitektur von Anfang an richtig aufsetzen? Das KI-Readiness Assessment von Nexus bewertet Ihre technische und organisatorische Reife - inklusive Security-Architektur und Governance-Struktur.