KI-Agenten, MCP und die neue Schatten-Automatisierung

Viele Unternehmen stehen gerade an einem seltsamen Punkt. Offiziell wird noch über KI-Richtlinien diskutiert. In der Praxis arbeiten Teams längst mit Agenten, Browser-Automationen, lokalen Coding-Assistenten, Chat-Workflows, Plugin-Verbindungen und internen Skripten. Was früher ein einzelner Prompt war, wird zunehmend zu einer Handlungskette: lesen, suchen, entscheiden, schreiben, committen, ticketen, mailen, buchen, deployen.

Das ist produktiv. Es ist aber auch der Beginn einer neuen Schatten-Automatisierung.

Der Begriff "Shadow IT" war früher relativ einfach: Jemand nutzt ein nicht freigegebenes SaaS-Tool. Heute ist die Lage feiner. Ein KI-Agent kann mit freigegebenen Tools arbeiten und trotzdem eine nicht freigegebene Prozesslogik ausführen. Er kann Daten aus einem CRM lesen, eine Tabelle interpretieren, Dateien aus einem Drive abrufen, Code ändern und ein Ticket schließen. Kein einzelner Schritt ist spektakulär. Die Kombination ist es.

Warum Agenten anders zu behandeln sind als Chatbots

Ein Chatbot antwortet. Ein Agent handelt. Diese Unterscheidung klingt klein, verändert aber die Sicherheitsarchitektur.

Sobald ein System Tools aufrufen darf, entstehen neue Fragen:

• Welche Daten darf der Agent sehen?
• Welche Aktionen darf er auslösen?
• Darf er Aktionen kombinieren, die einzeln erlaubt, gemeinsam aber riskant sind?
• Wer ist verantwortlich, wenn der Agent eine falsche Entscheidung vorbereitet?
• Wie wird nachträglich nachvollzogen, welche Quelle, welcher Prompt und welches Tool zu einem Ergebnis geführt haben?

Viele heutige KI-Projekte beantworten diese Fragen mit Benutzerberechtigungen: Der Agent darf, was der Nutzer darf. Das ist verständlich, aber gefährlich verkürzt. Ein Mensch hat Aufmerksamkeit, Kontext und Hemmungen. Ein Agent hat Geschwindigkeit, Skalierung und manchmal eine zu große Bereitschaft, plausibel klingende Lücken zu schließen.

Die bessere Denkweise lautet: Ein Agent braucht eigene Arbeitsrechte, nicht nur geerbte Benutzerrechte.

MCP als Chance und Risiko

Das Model Context Protocol und ähnliche Tool-Protokolle lösen ein echtes Problem. Sie schaffen eine strukturierte Art, Modelle mit Werkzeugen und Datenquellen zu verbinden. Statt für jede Integration eine Sonderlösung zu bauen, können Anwendungen standardisierte Schnittstellen anbieten.

Das ist gut für Geschwindigkeit. Es ist auch gut für Architektur, weil weniger wilde Einmal-Verbindungen entstehen. Gleichzeitig wird dadurch eine neue Ebene kritisch: die Tool-Beschreibung. Ein Modell entscheidet nicht wie ein klassisches Programm über eine hart codierte Funktion. Es liest Beschreibungen, Parameter, Rückgaben und Kontext. Wenn diese Ebene unsauber ist, kann ein Agent falsche Werkzeuge wählen oder zu viel Vertrauen in eine Quelle legen.

Risiken entstehen besonders dort, wo:

• Tool-Beschreibungen zu breit oder missverständlich sind.
• Ein Tool sowohl lesen als auch schreiben darf.
• Externe Inhalte in denselben Kontext gelangen wie Systemanweisungen.
• Logs nur den finalen Text zeigen, aber nicht die Tool-Aufrufe.
• Lokale Agenten Zugriff auf Dateien, Shell, Browser und Unternehmenssysteme zugleich erhalten.

Das heißt nicht, dass Unternehmen MCP meiden sollten. Im Gegenteil: Standardisierung ist oft sicherer als improvisierte Integrationen. Aber MCP-Server und Agenten-Tools gehören in dieselbe Governance-Kategorie wie interne APIs, nicht in die Kategorie "Produktivitätsfeature".

Prompt Injection wird operativ

Prompt Injection war lange ein Thema für Demos. Eine Webseite enthält eine versteckte Anweisung, ein Modell folgt ihr, alle lachen nervös. In agentischen Workflows wird daraus ein reales Prozessrisiko.

Stellen wir uns einen Vertriebsagenten vor, der Webseiten potenzieller Kunden ausliest, Ansprechpartner findet und CRM-Notizen erstellt. Wenn externe Inhalte beeinflussen können, welche internen Daten gelesen oder geschrieben werden, ist die Grenze zwischen Information und Anweisung unscharf. Gleiches gilt für Support-Agenten, die E-Mails lesen und Rückerstattungen vorbereiten, oder für Coding-Agenten, die Issues, Pull Requests und lokale Dateien zusammen auswerten.

Die Sicherheitsfrage lautet nicht nur, ob das Modell "klug genug" ist. Die Frage lautet, ob der Workflow externe Inhalte grundsätzlich als untrusted behandelt. Ein Agent sollte Webseiten, PDFs, E-Mails und Tickets nicht wie Kollegen behandeln, sondern wie potenziell manipulierte Eingaben.

Praktisch bedeutet das:

• Externe Inhalte dürfen keine Tool-Berechtigungen erhöhen.
• Schreibaktionen brauchen engere Regeln als Leseaktionen.
• Sensible Operationen sollten eine explizite Bestätigung verlangen.
• Der Agent sollte Quellen und Tool-Aufrufe getrennt protokollieren.
• Systemanweisungen und fremde Inhalte müssen technisch und konzeptionell getrennt bleiben.

Der gefährliche Komfort von "mach das kurz"

Agenten werden selten mit böser Absicht eingeführt. Sie entstehen aus Arbeitserleichterung. "Fass mir die Leads zusammen." "Erstelle daraus ein Angebot." "Prüf die offenen Tickets." "Mach einen Pull Request." Genau darin liegt der Reiz.

Aber jedes "mach das kurz" kann eine informelle Prozessänderung sein. Früher gab es für ein Angebot vielleicht vier Schritte: Bedarf prüfen, Preise validieren, Vorlage verwenden, Freigabe holen. Ein Agent kann diese Schritte in einem Fluss zusammenziehen. Das spart Zeit, aber es kann auch Kontrollen überspringen, die nie als Software-Regel modelliert wurden.

Viele Unternehmensprozesse funktionieren über soziale Reibung. Jemand fragt nach, jemand sieht eine Unstimmigkeit, jemand merkt, dass ein Kunde Sonderkonditionen hat. Automatisierung entfernt Reibung. Gute Automatisierung entfernt unnötige Reibung. Schlechte Automatisierung entfernt Kontrollpunkte.

Deshalb sollte ein Unternehmen vor der Einführung agentischer Workflows nicht nur fragen, was automatisiert werden kann. Es sollte fragen, welche Reibung fachlich wichtig ist.

Ein Governance-Modell, das Teams nicht lähmt

Die Lösung ist nicht, Agenten pauschal zu blockieren. Das würde nur dazu führen, dass Teams sie heimlich nutzen. Besser ist ein leichtgewichtiges Modell mit klaren Kategorien.

Eine sinnvolle Einteilung:

1. Assistenz ohne Tool-Zugriff: schreiben, strukturieren, erklären, brainstormen.
2. Lesen mit begrenztem Kontext: interne Dokumente, einzelne Tickets, ausgewählte Dateien.
3. Schreiben mit niedriger Auswirkung: Entwürfe, Kommentare, nicht produktive Dokumente.
4. Handeln mit Geschäftsauswirkung: CRM-Änderungen, Kundenkommunikation, Rechnungen, Codeänderungen.
5. Handeln mit Produktionsauswirkung: Deployments, Berechtigungen, Zahlungen, Sicherheitskonfiguration.

Jede Stufe braucht andere Regeln. Für Stufe 1 reichen Richtlinien und Datenschutzbewusstsein. Für Stufe 4 und 5 braucht es Audit-Logs, Freigaben, Rollback-Wege, Tool-Scopes und klare Verantwortlichkeit.

Das klingt nach Aufwand, ist aber handhabbar, wenn es früh gemacht wird. Später ist es schwerer, weil dann schon viele kleine Agenten-Workflows im Alltag kleben.

Worauf KMU besonders achten sollten

Kleinere Unternehmen haben oft einen Vorteil: weniger Legacy, kürzere Wege, pragmatischere Entscheidungen. Gleichzeitig sind Rollen breiter. Eine Person hat Zugriff auf Website, CRM, Buchhaltung, Cloud, Code und Kundenkommunikation. Ein Agent, der mit den Rechten dieser Person arbeitet, kann entsprechend viel bewegen.

Deshalb sollten KMU drei einfache Standards setzen:

• Tool-Zugriffe werden dokumentiert: Welche KI darf auf welche Systeme zugreifen?
• Schreibrechte sind enger als Leserechte: Ein Agent darf nicht automatisch alles ändern, was er lesen darf.
• Kritische Aktionen bleiben bestätigungspflichtig: Angebote, Zahlungen, Deployments, Löschungen, Massenmails und Berechtigungen.

Zusätzlich lohnt sich ein monatlicher Blick auf die Realität: Welche Tools nutzen Teams tatsächlich? Welche Browser-Erweiterungen, lokalen Agenten, Chat-Integrationen und Automationen sind neu dazugekommen? Nicht als Kontrolle mit erhobenem Finger, sondern als Inventar. Man kann nur absichern, was man sieht.

Die produktive Haltung

KI-Agenten werden bleiben, weil sie echte Arbeit abnehmen. Das Ziel ist nicht, sie kleinzuhalten. Das Ziel ist, sie erwachsen zu machen.

Ein erwachsener Agent hat begrenzte Rechte, klare Logs, nachvollziehbare Quellen, definierte Freigaben und einen Arbeitsbereich, der zu seiner Aufgabe passt. Er muss nicht überall hineinsehen. Er muss nicht alles selbst erledigen. Er muss vor allem zuverlässig in einem Prozess funktionieren, den das Unternehmen versteht.

Die Unternehmen, die hier früh gute Muster bauen, werden schneller arbeiten als andere. Nicht, weil sie mehr Tools ausprobieren, sondern weil sie Agenten in belastbare Arbeitsabläufe übersetzen. Das ist der Unterschied zwischen Spielerei und digitaler Wertschöpfung.