Lösung · AI Operations
Dein KI-Agent muss sich nicht irren, um Schaden anzurichten. Es reicht, dass jemand von außen mit ihm spricht.
Agenten-Governance entscheidet, was deiner tun darf. Sicherheit entscheidet, was jemand, der hier nicht arbeitet, ihn tun lassen kann: eine Anweisung, versteckt in einer E-Mail, die der Agent liest; ein Werkzeug, das niemand geprüft hat; ein Geheimnis, das im Kontext mitreist. Wir bauen diese Schicht —Isolation, Identität, Filterung und forensische Spur— und wir betreiben sie.
Das Problem
Ein Agent mit Rechten ist eine neue Angriffsfläche. Weder dein Sicherheitsdienstleister noch deine Governance-Schicht deckt sie ab.
- Dein Agent liest E-Mails, Tickets, Dokumente oder Webseiten. Das alles ist Text, den jemand von außen geschrieben hat, und das Modell unterscheidet nicht zwischen deinem Auftrag und dem, was im Inhalt ankommt.
- Die Zugangsdaten des Agenten sind nicht seine eigenen: sie gehören einem technischen Benutzer mit mehr Rechten als irgendjemand im Team und liegen in einer Umgebungsvariable, die seit dem ersten Tag niemand rotiert hat.
- Jedes Werkzeug, das du anschließt, erweitert, was er kann — und im selben Maß, was man ihn tun lassen kann. Niemand prüft, wer diesen Konnektor veröffentlicht hat, was er bei jedem Aufruf verlangt und was sich in der letzten Version geändert hat.
- Der Kontext schleppt Daten von einem Fall in den nächsten, weil die Sitzung nie geleert wird oder weil der Index, aus dem er Informationen holt, nicht nach den Rechten des Fragenden filtert.
- Wenn morgen jemand fragt, was der Agent getan hat, mit welchen Daten und unter welcher Version, liegt die Antwort verstreut in den Protokollen von drei Systemen ohne gemeinsame Kennung.
Was es kostet, alles zu lassen
Die Referenzliste der Branche lässt keinen Zweifel mehr: In der OWASP Top 10 for LLM Applications, Ausgabe 2025, steht Prompt Injection zum zweiten Mal in Folge auf Platz eins, die Offenlegung sensibler Informationen auf Platz zwei, die Lieferkette auf Platz drei und übermäßige Handlungsvollmacht —dem Agenten mehr Fähigkeit geben, als seine Aufgabe braucht— auf Platz sechs. Das ist kein Zukunftsrisiko: das ist exakt das Drehbuch, nach dem jeder auf dein System schaut, der es prüft — dein Großkunde, deine Versicherung oder deine Aufsicht. Und die Kosten fehlender Antworten zahlst du nicht in offenen Tickets: du zahlst sie in Daten, die rausgingen, in einer Aktion, die ausgeführt wurde, und in einer Erklärung, die du mangels Spur nicht liefern kannst.
Die Lösung
Wir bauen die Sicherheitsschicht des Agenten —Isolation, Identität, Filterung und forensische Spur— und betreiben sie als kontinuierliche Funktion
- 1Wir modellieren die Bedrohung Agent für Agent, den Schritt, den fast niemand macht: woher der Text kommt, den er liest, welche Daten er erreicht, welche Aktionen er ausführen kann und was passiert, wenn ein Dritter eines dieser drei Dinge kontrolliert. Daraus entsteht die Härtungsliste, in der richtigen Reihenfolge — nicht umgekehrt.
- 2Wir trennen Anweisung von Daten. Was von außen kommt, geht als Inhalt ein, nie als Befehl: Vorlagen, die der Inhalt nicht umschreiben kann, Eingabefilterung und Validierung der Ausgabe, bevor sie ein echtes System berührt. Dass sich das Modell überreden lässt, ist verkraftbar; dass seine Ausgabe ungeprüft ausgeführt wird, nicht.
- 3Wir geben jedem Agenten eine eigene Identität statt eines geteilten Generalschlüssels: kurzlebige Zugangsdaten, minimale Rechte pro Werkzeug und pro Datenbestand, und sensible Aktionen mit eng gefasster Autorisierung statt eines ewigen Tokens in einer Umgebungsdatei.
- 4Wir isolieren die Werkzeugausführung: begrenzte Umgebung, Allowlist für Ziele und Domains und echte Prüfung jedes installierten Konnektors —wer ihn veröffentlicht, welche Rechte er verlangt, was sich pro Version ändert. Die Lieferkette ist Risiko drei der Liste und zugleich das, was am leichtesten durchrutscht.
- 5Wir stoppen den Abfluss über den Kontext: die Informationssuche filtert nach den Rechten des Fragenden, die Sitzung wird zwischen Fällen geleert, und Geheimnisse wie personenbezogene Daten werden maskiert, bevor etwas an ein externes Modell geht.
- 6Wir schließen mit forensischer Spur und Reaktion: eine Fallkennung, die Modell, Werkzeuge und Systeme durchzieht, eine Aufbewahrung, mit der man wirklich ermitteln kann, ein Not-Aus pro Agent und ein geschriebenes Reaktionsverfahren. Und wir betreiben es: regelmäßige gegnerische Tests gegen die laufenden Agenten, nicht ein einmaliges Audit, das in drei Monaten veraltet.
Was sich ändert
Was du nicht mehr verlierst
Prompt Injection bleibt nicht theoretisch: sie wird gegen deine laufenden Agenten getestet, mit echten Fällen aus deinem Geschäft, bevor jemand von außen es tut.
Mechanismus
Der Agent teilt keinen Generalschlüssel mehr: jeder hat eigene Identität, minimale Rechte und kurzlebige Zugangsdaten — ein kompromittierter Agent öffnet nicht das ganze Haus.
Mechanismus
Der Kontextabfluss hängt nicht mehr davon ab, dass niemand fragt, was er nicht darf: gefiltert wird nach den Rechten des Fragenden und zwischen Fällen geleert — konstruktiv, nicht auf Vertrauensbasis.
Mechanismus
Was wir messen: Anteil der Agenten mit lebendem Bedrohungsmodell, % sensibler Aktionen mit eng gefasster Berechtigung oder Autorisierung, offene und geschlossene Befunde aus gegnerischen Tests, und Zeit bis zur vollständigen Rekonstruktion eines Falls.
Was wir messen
Datenblatt
- Wegfallende Arbeit
- im Nachhinein festzustellen, dass ein Agent überredet wurde, überschüssige Rechte trug oder sein Kontext Daten preisgab —und den Fall von Hand aus Protokollen zu rekonstruieren, die nicht zusammenpassen
- Übliche Einrichtung
- 3–6 Wochen
- Eingang
- die Agenten, die du bereits in Produktion betreibst, ihre angeschlossenen Werkzeuge, ihre Zugangsdaten und die Textquellen, die sie lesen
- Ausgang
- jeder Agent mit Bedrohungsmodell, eigener Identität und minimalen Rechten, isolierten Werkzeugen auf Allowlist, nach Rechten gefiltertem Kontext und einer durchgehenden Spur, mit der sich wirklich ermitteln lässt
- Kompatibel mit
- OpenAIAnthropicAzure OpenAILangChainLlamaIndexn8nServidores MCP
- Kann sich verbinden mit
- Tu gestor de secretos y tu proveedor de identidadTu SIEM o tu stack de observabilidadTu capa de gobierno de agentes, si ya la tienes montada
- Was wir messen
- Anteil der Agenten mit lebendem Bedrohungsmodell% sensibler Aktionen mit eng gefasster Berechtigung oder Autorisierungoffene und geschlossene Befunde aus gegnerischen TestsZeit bis zur Rekonstruktion eines vollständigen Falls
- Geeignet für
- Unternehmen mit Agenten, die bereits in Produktion laufen, Fremdtext lesen oder auf echte Systeme wirken, und die einem Kunden, einem Audit oder einer Aufsicht Rede und Antwort stehen müssen
- Nicht geeignet für
- wer noch im Proof of Concept ohne echte Daten und Schreibrechte steckt: da braucht es gutes Design, keine Härtung
Häufig gestellte Fragen
Im Gegner. Governance beantwortet «was darf mein Agent und wer haftet, wenn er irrt»: Richtlinien, Freigaben, Audit, Compliance. Das ist die Schicht gegen den eigenen Fehler, und sie ist in die KI-Agenten deines Unternehmens governen ausgeführt. Sicherheit beantwortet eine andere Frage: «was kann jemand, der hier nicht arbeitet, meinen Agenten tun lassen». Da hilft keine Richtlinie, denn der Angreifer liest deine Richtlinien nicht: man muss Anweisung von Daten trennen, Werkzeuge isolieren, Identitäten eng fassen und eine ermittelbare Spur hinterlassen. Beides ergänzt sich, und die Reihenfolge ist zweitrangig; was nicht funktioniert, ist eins zu haben und zu glauben, man habe beides.
Für Perimeter, Zugänge und Endgeräte ja, und daran rühren wir nicht. Die Straße endet bei der neuen Fläche: ein Agent, der Aktionen aus Text ausführt, den ein Dritter geschrieben hat, ähnelt nichts, was eine Firewall abdeckt. Prompt Injection ist kein Netzwerk-Exploit, sondern das Modell, das dem Falschen gehorcht. Werkzeug-Isolation ist keine Netzsegmentierung, sondern die Entscheidung, was ein zur Laufzeit improvisierender Prozess aufrufen darf. Und einen Konnektor zu prüfen ist kein Schwachstellenscan, sondern zu lesen, welche Rechte er verlangt und wer ihn veröffentlicht hat. Diese Schicht liegt im Niemandsland zwischen deinem Sicherheitsdienstleister und deiner KI-Beratung: deshalb bauen wir sie, und deshalb steht dahinter vollständige Sicherheit, klassisch und KI.
Nein — und sei misstrauisch, wenn jemand ja sagt. Solange das Modell Anweisungen und Daten über denselben Kanal verarbeitet, wird es immer Text geben, der es überreden kann; deshalb hält dieses Risiko zwei Ausgaben in Folge Platz eins der OWASP-Liste. Was geht —und was das Ergebnis wirklich ändert— ist, dass Überredetwerden allein keinen Schaden verursacht: minimale Rechte, damit die gefährliche Aktion gar nicht verfügbar ist; Validierung der Ausgabe, bevor sie ein System berührt; menschliche Autorisierung bei allem, was Geld kostet oder Menschen betrifft; und eine Spur, um es früh zu bemerken. Die Verteidigung ist keine Mauer: es sind Schichten, die verhindern, dass ein Modellfehler zum Geschäftsvorfall wird.
Bauen wir es in deinem Betrieb?
Du hast das Problem benannt. Wir liefern die Lösung und lassen sie gemessen laufen.