Ich habe es mehr als einmal gesehen. Unter dem Firmenlaptop liegt ein zweiter, zugeklappt, unauffällig. Er hängt an einem mobilen Hotspot. Er sieht euer Netz nie von innen. Und auf ihm läuft genau das, was die IT letzten Monat gesperrt hat.

Der Mann, dem er gehört, ist kein Saboteur. Er ist der Typ, der seine Arbeit fertig machen will.

Was Cloudflare in neun Tagen gebaut hat

Cloudflare hat im August zwei Bausteine für KI-Governance nachgeschoben, neun Tage auseinander.

Am 5. August kam WriteGuard in die private Beta. Das Werkzeug sitzt zwischen deinem Agenten und dem MCP-Server und entscheidet pro Werkzeug, was passieren darf. Jedes Werkzeug bekommt eine Risikostufe, von read-only über minimal impact und contained write bis critical. Ein Aufruf wird dann entweder durchgelassen, mit Attribution und einem Audit-Event angereichert, oder blockiert, bevor der Handler überhaupt anläuft. Cloudflares eigenes Beispiel: Der Agent soll keinen Merge Request abschliessen und kein Produktions-Deployment auslösen.

Am 14. August kam die Erkennung. Cloudflare Gateway liest bei TLS-inspizierten Anfragen den MCP-Protocol-Version-Header mit und klassifiziert den Verkehr. Damit wird zweierlei sichtbar: Schatten-MCP, also Verbindungen zu Servern, die niemand freigegeben hat. Und Portal-Umgehung, also Leute, die sich direkt mit einem genehmigten Server verbinden und dabei an euren Schutzmechanismen vorbeigehen.

Beides ist sauber gebaut. Und beides beantwortet eine Frage, die du wahrscheinlich gar nicht hast.

Die Erkennung sieht nur die, die ohnehin durch die Tür gehen

Der Satz, an dem alles hängt, ist «bei TLS-inspizierten Anfragen». Übersetzt: Der Verkehr muss durch dich hindurch, damit du ihn siehst.

Der Laptop unter dem Laptop läuft nicht durch dich hindurch. Er läuft über Mobilfunk. Er taucht in keinem Gateway auf, in keinem Header, in keinem Dashboard. Nicht weil Cloudflare schlecht wäre, sondern weil dort schlicht kein Messpunkt ist.

Und jetzt kommt der Teil, den die meisten übersehen. Dein Dashboard wird trotzdem grün. Es zeigt die Compliance derer, die sich ohnehin an die Regeln halten. Je konsequenter du blockst, desto sauberer sieht die Auswertung aus, weil jede Umgehung aus der Messung herausfällt. Du bekommst also nicht Sicherheit, du bekommst eine Zahl, die mit dem Ausmass des Problems negativ korreliert.

Das ist gefährlicher als gar keine Messung, weil du danach handelst.

Der Schalter entscheidet, bevor jemand die Aufgabe kennt

Jetzt Punkt zwei, und der ist unbequemer.

Nimm Confluence. Wir sperren dem Agenten spasseshalber den Schreibzugriff auf Seiten. Was hat das gelöst?

Liest der Agent ohnehin nur, hat die Regel nie gegriffen. Sie steht als grüner Haken in der Governance-Übersicht und hat exakt null bewirkt.

Soll der Agent aber eine Seite aktualisieren, dann fährt er vor die Wand. Und mit ihm der Mitarbeiter, der ihn beauftragt hat.

Denn das ist die eigentliche Schwäche: Die Entscheidung fällt pro Werkzeug, nicht pro Aufgabe. Sie wird von jemandem getroffen, der nicht weiss, was dein Mitarbeiter an diesem Dienstag zu erledigen hat. Der MCP-Entwickler hat den Schreibzugriff nicht aus Übermut eingebaut, sondern weil ohne ihn eine ganze Klasse von Aufgaben unlösbar ist. Wer ihn abschaltet, streicht diese Aufgaben, ohne sie je gesehen zu haben.

Danach gibt es zwei Ausgänge, und beide kosten dich Geld.

Der engagierte Mitarbeiter besorgt sich einen Weg daran vorbei. Du kennst ihn jetzt, er liegt zugeklappt unter dem Firmenlaptop. Aus einem kontrollierten Werkzeug ist ein unkontrolliertes geworden, und du hast es selbst dorthin geschoben.

Der nicht engagierte Mitarbeiter macht die Faust im Sack und erledigt die Aufgabe von Hand. Er beschwert sich nicht, er eskaliert nicht, er fällt in keiner Statistik auf. Die Effizienz, für die du die Agenten eingeführt hast, ist einfach weg. Still.

Rate, welcher der beiden in deinem Reporting auftaucht.

Es gibt eine Kontrolle, die niemanden vor die Wand fährt

Interessanterweise steckt sie im selben Produkt, nur bewirbt Cloudflare sie kaum.

Bei jedem erlaubten Schreibvorgang hängt WriteGuard die Agenten-Attribution an und protokolliert, wer im Namen von wem gehandelt hat. Jeder Aufruf wird als erfolgreich, fehlgeschlagen oder blockiert klassifiziert und als Ereignis weggeschrieben, quer über alle MCP-Server hinweg.

Das ist die Beweiskette. Und es ist die Frage, die dich im Ernstfall wirklich beschäftigt. Nicht «durfte der Agent das», sondern «wer hat es angeordnet, wann, in wessen Namen, und können wir das jemandem zeigen».

Der entscheidende Unterschied ist nicht juristisch, er ist verhaltensökonomisch: Protokollieren erzeugt keinen Umweg. Niemand schleppt einen zweiten Laptop ins Büro, weil sein Name in einem Audit-Log steht. Deshalb ist das die einzige Kontrolle in diesem Produkt, die auch nächstes Jahr noch misst, was wirklich passiert.

Das Wettrüsten hast du verloren, bevor es angefangen hat

Und damit sind wir beim eigentlichen Punkt.

Die Branche verkauft dir gerade immer feinere Blockierwerkzeuge, und jedes einzelne ist besser als sein Vorgänger. Nur ist die Rechnung dahinter absurd. Du rüstest mit Lizenzen, Projektbudget, Betriebsaufwand und einem Team, das Richtlinien pflegt. Dein Mitarbeiter rüstet mit einem alten Laptop und einem Hotspot, den er ohnehin in der Tasche hat.

Du kannst dieses Rennen nicht gewinnen. Nicht weil deine Werkzeuge zu schwach wären, sondern weil du gegen die eigenen Leute antrittst und die immer den billigeren Ausweg haben. Jede Verschärfung bringt dir kurz eine sauberere Statistik und schiebt dauerhaft ein weiteres Stück Arbeit dorthin, wo du nichts mehr siehst.

Das Problem ist nie gewesen, dass zu wenig blockiert wird. Das Problem ist, dass der freigegebene Weg langsamer ist als der Umweg. Solange das so bleibt, ist jede zusätzliche Sperre nur eine weitere Einladung, ihn zu nehmen.

Also dreh die Aufgabe um. Nicht «welche Werkzeuge sperren wir», sondern «welche Aufgabe stirbt mit jeder Sperre, die wir setzen». Halte die Sperrliste gegen die Aufgabenliste, nicht gegen die Risikoliste. Wo dein Agent eine Berechtigung wirklich braucht, gib sie ihm und protokolliere mit, statt ihn auszubremsen.

Deine Logs sind keine Fahndungsliste

Damit hast du plötzlich etwas in der Hand, und jetzt kommt es darauf an, was du damit machst.

Die naheliegende Lesart ist die Fahndungsliste. Wer hat was getan, wo war jemand zu weit, was sperren wir als Nächstes. Diese Lesart ist verlockend, weil sie sofort eine Massnahme produziert. Sie ist auch die teure, weil jede Massnahme daraus die Spirale von oben eine Windung weiterdreht.

Die nützliche Lesart ist die andere. In deinen Logs steht, wie deine Leute tatsächlich arbeiten. Welche Werkzeuge sie in welcher Reihenfolge greifen. Wo sie abbrechen. Welchen Schritt sie zum fünften Mal von Hand machen, weil der Agent ihn nicht darf. Wo der Umweg schneller ist als der vorgesehene Weg, und um wie viel. Das sind Daten, für die andere Unternehmen Nutzerforschung einkaufen. Du hast sie ohnehin liegen, und niemand liest sie so.

Was dabei gut läuft, machst du zum Standard, damit es nicht bei den drei Leuten bleibt, die es sich selbst beigebracht haben. Was schlecht läuft, räumst du weg, statt es zu verbieten. Und wo jemand regelmässig an derselben Stelle ausweicht, hast du keinen Compliance-Fall vor dir, sondern eine Anforderung.

Genau dort entscheidet sich, ob deine Governance trägt. Nicht in der Richtlinie, sondern in der Frage, ob du deine Leute in die Lage versetzt, ihre Arbeit regelkonform und trotzdem effizient zu erledigen. Solange sie sich zwischen beidem entscheiden müssen, verlierst du jedes Mal, und zwar unbeobachtet.

Kontrolle funktioniert nur, wenn der erlaubte Weg auch der schnellste ist. Alles andere ist ein Rüstungswettlauf gegen Leute, die eigentlich für dich arbeiten wollen.