Zedmos

AI-Sicherheit

KI erlauben. Ohne sie aus den Augen zu verlieren.

Ihre Leute nutzen längst Assistenten, die Sie nicht ausgesucht haben — und zunehmend tun das auch die Werkzeuge auf ihren Rechnern: Coding-Agenten, die ein Repository lesen, Skripte im Maschinentakt, MCP-Clients, die selbständig Tools aufrufen. Das hier sieht jeden davon auf der Leitung: welcher Dienst, von wem genutzt, wo Daten verarbeitet werden, freigegeben oder nicht — und lässt Sie entscheiden, wer was nutzen darf, während geprüft wird, was hinausgeht. Auf Ihrer eigenen Firewall, mit dem urteilenden Modell auf Ihrer Hardware.

17
Anbieterregeln, Assistenten und Coding-Agenten
69
Inhaltsdetektoren in 8 Gruppen
5
Client-Klassen, nach Belegen entschieden
0
Prompts, die zur Bewertung an Dritte gehen

Was schiefgeht — und was dagegen hält

Das Risiko: niemand weiß, was genutzt wird

Assistenten kommen ohne Beschaffungsentscheidung ins Haus. Jemand meldet sich an, jemand anderes installiert ein Editor-Plugin, und die erste ehrliche Antwort auf „welche KI-Dienste nutzen wir?“ ist eine Vermutung. Für Verkehr, den Sie nicht benennen können, lässt sich keine Richtlinie schreiben.

Sichtbarkeit: das Inventar von der Leitung

Jeder KI-Dienst in Ihrem Verkehr, mit dem Anbieter dahinter, dem Ort der Datenverarbeitung und der Angabe, ob Sie ihn freigegeben haben. Siebzehn Anbieterregeln erfassen die Assistenten und, getrennt davon, die Coding-Agenten — Cursor, Codeium, Windsurf, Tabnine und GitHub Copilot — dazu ein Auffangeintrag für alles Weitere, das als KI klassifiziert wird. Dafür wird auf keinem Laptop etwas installiert.

Das Risiko: der Aufrufer ist nicht immer ein Mensch

Ein Coding-Agent, der ein Repository liest, ein Skript mit geliehenem API-Schlüssel, ein MCP-Client, der selbständig Tools aufruft — alle drei erreichen denselben Anbieter wie Ihre Mitarbeiter, und ein Filter, der nur das Ziel kennt, schreibt für einen Menschen dieselbe Logzeile wie für eine Schleife.

Kontrolle: eine Regel je Art von Aufrufer

Browser, SDK, Agent, MCP oder unbekannt — jede Klasse erhält eine eigene Aktion, wo nötig je Anbieter eine abweichende. Dazu: Allow- und Blocklisten auf dem Client, die Tool-Namen, die eine Anfrage tragen darf, ein Ratenlimit je Quelle, eine Größenobergrenze. Die Klasse steht fest, bevor der Body gelesen wird — ein Aufrufer lässt sich also abweisen, ohne ein Wort seines Inhalts zu prüfen.

Das Risiko: was getippt wird — und was zurückkommt

Der Prompt ist das Leck. Quellcode, eine Kundenliste, ein aus Bequemlichkeit eingefügtes Zugangsdatum. Und die Antwort ist ein eigenes Problem: Ein Assistent lässt sich dazu bringen, die Anweisung zu schreiben, die den Schaden anrichtet.

Schutz: geprüft, bevor es hinausgeht

69 Inhaltsdetektoren in 8 Gruppen — nationale Kennungen aus 22 Ländern, Cloud-Secrets, personenbezogene und Zahlungsdaten, Prompt Injection, sowie acht für Anweisungen, die einen Assistenten gegen Sie wenden: ein per Shell ausgeführtes Skript, eine Reverse Shell, eine Exfiltrations-Anweisung, der Versuch, die Leitplanken eines Agenten zu umgehen. Auch der Antwortweg kann abgegriffen werden — dort wird markiert und protokolliert, nie blockiert.

Das Urteil fällt bei Ihnen im Haus

Unstrukturierter Text wird von einem Sprachmodell auf Ihrer eigenen Hardware bewertet. Kein Prompt, kein Upload und kein Auszug geht zur Bewertung an Dritte — das ist der Unterschied zwischen einer Maßnahme, die Sie im Einkaufsfragebogen angeben können, und einer, die ihm einen Auftragsverarbeiter hinzufügt.

Aus, bis Sie es einschalten

Die Klassifizierung läuft immer — Inventar und Klasse stehen also vom ersten Tag an im Flow-Datensatz, und Sie sehen, was bereits unterwegs ist, bevor Sie etwas entscheiden. Die Kontrollen sind ein eigener Schalter, standardmäßig aus, je Policy-Gruppe.

Fünf Clients, ein Ziel, fünf verschiedene Antworten

Alle fünf erreichen denselben KI-Anbieter innerhalb einer Minute. Nur einer davon ist ein Mensch.

1Der Bodywas die Anfrage tatsächlich tat"jsonrpc":"2.0" · "method":"tools/call" · tool_resultsnicht fälschbar, ohne es zu tun2Die Headerwas der Stack des Clients ungefragt sendetx-stainless-* · client hints · fetch metadatanicht vom Skript-Autor gewählt3Der User-Agentwas er zu sein behauptet"Mozilla/5.0 (Windows NT 10.0; Win64; x64) …"eine Zeile, die jeder schreiben kannvon 1 und 2 überstimmtdie einzige Zeile, die ein Zielfilter liestKLASSEbrowsersdkagentmcpunknown
Drei Lesungen einer Anfrage, oben die am schwersten zu fälschende. Ein Client, der in Zeile 3 einen Browser behauptet und in Zeile 2 keinen einzigen Browser-Header sendet, wird nach seinem Verhalten klassifiziert, nicht nach seiner Aussage — und der Betreiber sieht, als was er sich ausgab.
Was den Anbieter erreichtWas ein Zielfilter siehtWas diese Engine sieht
Jemand im Marketingein Tab, eine Frage
Verkehr zu einem KI-Anbieter
BROWSERchromesendet die Header eines BrowsersErlaubt
Ein nächtliches SkriptBatch-Zusammenfassungen
Verkehr zu einem KI-Anbieter
SDKpython-httpxSDK-Transport gibt sich zu erkennenProtokolliert
Ein Coding-Assistentliest das Repository
Verkehr zu einem KI-Anbieter
AGENTclaude-codeTool-Ergebnisse zurück ans ModellMit Tool-Namen protokolliert
Ein MCP-Clientruft ein Tool auf
Verkehr zu einem KI-Anbieter
MCPmcp-clientJSON-RPC-Frame, Methode tools/callread_file abgelehnt
Ein getarntes Skriptgibt sich als Chrome aus
Verkehr zu einem KI-Anbieter
SDKspoofed-chromebehauptet Browser, sendet keinen seiner HeaderBlockiert
Die letzte Zeile ist die entscheidende. Jeder Filter, der dem User-Agent glaubt, lässt sie als Mensch durch — genau diese Lücke schließt das hier.