Vibe-Coding ohne Sicherheitsnetz: Wenn der Prompt die App baut und niemand die Tür abschließt

Lernen wir Norbert kennen. Norbert ist kein Entwickler. Norbert hat eine Idee, eine Kreditkarte und eine KI, die auf 'Bau mir eine App' mit erstaunlich hübschem Code antwortet. Zwei Nachmittage später steht ein lauffähiges Produkt, Norbert ist stolz wie Oskar. Norbert sollte eigentlich nervös sein.

Was gerade wirklich passiert

Vibe-Coding macht aus einer Idee in Rekordzeit laufenden Code. Das ist großartig, ehrlich. Das Problem ist nur: 'lauffähig' und 'sicher' sind zwei völlig verschiedene Paar Schuhe. Die KI erklärt Norbert bereitwillig, wie er die App auf einen Server oder zu einem Hosting-Anbieter bringt, wie er eine Datenbank anbindet und echte Daten importiert. Von Sicherheit war in dem ganzen Gespräch nie die Rede. Warum auch, Norbert hat ja nicht danach gefragt.

Und bevor du jetzt denkst, Norbert sei halt so ein Hobbybastler mit zu viel Freizeit: Norbert sitzt bei dir im Vertrieb. Oder im Controlling. Oder im Marketing. Er hat ein echtes Problem, eine Deadline und keinen Bock, drei Monate auf ein IT-Ticket zu warten. Also baut er sich die Lösung selbst. Mit Firmendaten. Ohne dass die IT davon weiß.

Die Stelle, an der es wehtut

Defaults sind selten sicher, sie sind bequem. Secrets landen im Code, im Frontend-Build oder im Git-Verlauf. Die Datenbank ist von außen erreichbar und hat keine Zugriffsregeln. Authentifizierung? 'Kennt doch keiner die URL.' Und dann, als Krönung, kommen die echten Daten rein: Namen, E-Mail-Adressen, vielleicht Zahlungsinfos. Alles schön beieinander, alles schön offen.

Beispiel gefällig?

So sieht es aus, wenn der service_role-Key im Frontend landet, lesbar für jeden mit geöffneten Dev-Tools:

# .env, gelandet im Frontend-Build und im Browser lesbar
VITE_SUPABASE_URL=https://deinprojekt.supabase.co
VITE_SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1...  # Vollzugriff. Im Browser. Für alle.
STRIPE_SECRET_KEY=sk_live_51Hxxxx                   # auch nicht besser

Der service_role-Key hebt in Supabase sämtliche Zugriffsregeln aus. Steht er im Frontend, liest jeder mit zwei Klicks die komplette Datenbank aus. Norbert weiß das nicht. Die KI hat es nicht dazugesagt. Und der Stripe-Key daneben ist die freundliche Einladung, auf Norberts Rechnung Geld zu bewegen.

Die üblichen Verdächtigen

• Secrets im Code, im Frontend oder im Git-Verlauf statt serverseitig und im Secret-Manager.
• Datenbank ohne Zugriffsregeln (Row Level Security) und frei aus dem Netz erreichbar.
• Keine echte Authentifizierung, nur 'security by die-URL-kennt-ja-keiner'.
• Sensible Daten importiert, ohne Verschlüsselung und ohne Rechtsgrundlage (die DSGVO lässt herzlich grüßen).
• Kein Backup, kein Logging, kein Plan B für den Tag, an dem es knallt.

Schatten-KI: die IT, von der die IT nichts weiß

Norberts App ist nur die Spitze vom Eisberg. Darunter liegt etwas, das bald so gut wie jedes Unternehmen betrifft: Schatten-KI. Also KI-Tools, die im Alltag längst laufen, aber nie bei der internen IT angemeldet wurden. Der Chatbot mit dem privaten Account, in den schnell mal das Angebot für den Großkunden kopiert wird. Die Browser-Erweiterung, die 'nur kurz' E-Mails zusammenfasst. Der Meeting-Bot, der ungefragt in jedem Teams-Call mitschreibt. Der KI-Agent, dem jemand per Klick Zugriff auf Postfach und Laufwerk gegeben hat.

Das Gemeine daran: Niemand macht das aus böser Absicht. Die Leute wollen einfach ihre Arbeit erledigen. Aber jede dieser Abkürzungen schiebt Firmendaten zu einem Anbieter, mit dem es keinen Vertrag gibt, keinen Auftragsverarbeitungsvertrag (AVV), keine Prüfung, wo die Daten landen, und keine Antwort auf die Frage, ob damit Modelle trainiert werden. Sicherheit und Datenschutz finden dann nicht statt, sie werden einfach übersprungen.

Drei Abteilungen, drei Kreditkarten, drei KI-Organisationen

Richtig lustig wird es (also, nicht wirklich), wenn der Wildwuchs organisiert passiert. Das Marketing legt sich beim KI-Anbieter A einen Team-Workspace an. Die Entwicklung hat beim selben Anbieter eine eigene Organisation für API-Keys, natürlich auf eine andere Kreditkarte. Der Vertrieb testet Anbieter B, und irgendwer hat bei Anbieter C noch einen Testzugang von vor einem Jahr, der fröhlich weiterläuft. Gefragt hat niemand, zugestimmt auch nicht. Ergebnis: mehrere Organisationen eines Anbieters plus mehrere Anbieter, alle mit Firmendaten, keiner davon zentral verwaltet.

Was das in der Praxis bedeutet:

• Kein Single Sign-on, keine MFA-Pflicht, jede Organisation hat ihre eigene Benutzerverwaltung.
• Kein Offboarding: Wer das Unternehmen verlässt, behält oft den Zugriff auf den Workspace mitsamt Chatverlauf und hochgeladenen Dateien.
• API-Keys in Organisationen, die niemand rotiert, weil niemand weiß, dass es sie gibt.
• Keine Logs, kein Audit: Bei einem Vorfall oder einer DSGVO-Auskunft kann niemand sagen, welche Daten wohin geflossen sind.
• Kein Verarbeitungsverzeichnis, das die Realität abbildet, und kein Überblick über Kosten.

Woran du Schatten-KI erkennst

Die gute Nachricht: Unsichtbar ist Schatten-KI nur, solange keiner hinschaut. Typische Spuren:

• KI-Abos in den Kreditkarten- und Spesenabrechnungen.
• Einwilligungen für unbekannte KI-Apps in Entra ID oder Google Workspace, die per OAuth auf Mail, Kalender oder Laufwerk zugreifen.
• KI-Domains im Proxy- oder DNS-Log und Treffer in der Cloud-App-Discovery (zum Beispiel Microsoft Defender for Cloud Apps).
• Browser-Erweiterungen mit Vollzugriff auf alle Webseiten.
• Meeting-Bots, die plötzlich als Teilnehmer in Calls auftauchen.

Warum Verbote allein nicht funktionieren

Der Reflex ist verständlich: KI sperren, Rundmail schicken, Haken dran. Funktioniert ungefähr so gut wie ein Rauchverbot auf der Raucherinsel. Wer keine erlaubte Alternative bekommt, nimmt das private Handy, den privaten Account und die eigene Kreditkarte. Dann ist die Nutzung nicht weg, sie ist nur noch unsichtbarer.

Der eigentliche Punkt ist simpel: Wenn das Unternehmen kein Angebot macht, entscheiden die Mitarbeitenden selbst. Und zwar Norbert, nach Bauchgefühl und Preisliste. Wer das verhindern will, muss schneller sein und kontrolliert bereitstellen, bevor mangels Angebot jemand anders die Entscheidung trifft.

Was wirklich hilft: Angebot, Policies, Training, Kontrolle

1. Kontrolliert bereitstellen

Gib den Leuten freigegebene KI-Werkzeuge, die gut genug sind, dass niemand ausweichen will. Mit Unternehmensvertrag und AVV, Single Sign-on, zentraler Verwaltung und klaren Einstellungen zu Datenspeicherung und Training. Pro Anbieter genau eine Organisation, verwaltet von der IT, nicht fünf von fünf Abteilungen. Und für alle Norberts, die bauen wollen: eine sichere Spielwiese ohne Produktivdaten, mit Vorlagen, in denen Secret-Management, Authentifizierung und Datenbankregeln schon eingebaut sind.

2. Policies, die man tatsächlich liest

Keine 40 Seiten PDF, die im Intranet verstauben. Eine KI-Richtlinie, die auf eine Seite passt und klare Antworten gibt:

• Welche KI-Tools sind freigegeben, und wo steht die aktuelle Liste?
• Welche Daten dürfen rein? Eine einfache Ampel hilft: öffentlich ja, intern mit freigegebenen Tools, vertraulich und personenbezogen nur nach Freigabe.
• Wer darf bei KI-Anbietern Organisationen, Workspaces und API-Keys anlegen? Antwort: die IT. Punkt.
• Wie läuft der Antrag für ein neues Tool, und wie schnell gibt es eine Antwort?
• Was muss passieren, bevor eine selbstgebaute App echte Daten sieht? Ein Review, keine Ausnahmen.

3. Training statt Angstmache

'KI ist gefährlich' ist kein Training, das ist eine Warnung, die jeder sofort wieder vergisst. Gutes Training ist praktisch: welche Daten wohin dürfen, wie man ein freigegebenes Tool sinnvoll nutzt, wie die üblichen Verdächtigen aussehen und wen man fragt, bevor es knallt. Pflicht ist das übrigens längst: Seit dem 2. Februar 2025 verlangt Artikel 4 des EU AI Act von Unternehmen, die KI-Systeme einsetzen, Maßnahmen für ausreichende KI-Kompetenz ihres Personals.

4. Bessere Kontrolle

Vertrauen ist gut, Sichtbarkeit ist besser. Ein paar Hebel, die sofort wirken:

• Benutzer-Einwilligungen für Drittanbieter-Apps einschränken und einen Admin-Consent-Workflow einführen, damit KI-Agenten nicht per Klick ans Postfach kommen.
• Cloud-App-Discovery einschalten, KI-Dienste bewerten und nicht freigegebene sperren, sobald es eine Alternative gibt.
• Bei Anbietern, die das unterstützen, die Firmendomain verifizieren und Accounts mit Firmenadresse in die zentrale Organisation holen.
• DLP-Regeln für die sensibelsten Daten, damit Kundendaten nicht im nächstbesten Chatfenster landen.
• Regelmäßig inventarisieren: Welche KI-Tools, Organisationen und API-Keys gibt es, und wem gehören sie?

Für alle Norberts, die trotzdem bauen

Vibe-Coding ist nicht der Feind. Blindflug mit echten Daten ist es. Die Minimal-Dosis Sicherheit, bevor der erste echte Datensatz reinkommt:

1. Secrets gehören serverseitig, nie ins Frontend und nie in Git. .gitignore an, Secret-Manager nutzen, kompromittierte Keys sofort rotieren.
2. Datenbank-Zugriffsregeln einschalten. Der sichere Default heißt 'zu', nicht 'offen'.
3. Echte Authentifizierung vor alles setzen, was Daten anfasst.
4. Vor dem ersten echten Datensatz klären: Wer darf was, wo liegen die Daten, und ist das rechtlich sauber?
5. Einmal von außen draufschauen lassen, bevor Kundendaten reinkommen. Lieber ein ehrlicher Blick jetzt als ein Anruf von der Datenschutzbehörde später.

Das eigentliche Problem

Vibe-Coding demokratisiert das Bauen, aber eben nicht das Absichern. Die Werkzeuge werden laut beim 'Bau mir was' und verstummen beim 'Sicher es ab'. Solange das so bleibt, produzieren wir im Akkord hübsche Apps mit offener Hintertür. Sicherheit ist kein Feature, das man am Schluss drüberklebt, sie ist das Fundament.

Und das ist am Ende kein Technikproblem, sondern ein Organisationsproblem. KI kommt in dein Unternehmen, so oder so. Die Frage ist nur, ob durch die Vordertür mit Vertrag, Regeln und Schulung, oder durch die Hintertür mit Norberts Kreditkarte.

Also, Norbert: bau weiter, bitte. Aber schließ die Tür ab, bevor du die echten Daten reinträgst. Und liebe IT: Gib Norbert einen Schlüssel, bevor er sich selber einen nachmacht. Mach MFA an. Think purple.