KI-Agenten als digitale Insider: Governance und Sicherheit für den Mittelstand

KI-Agenten lesen E-Mails, greifen auf Geschäftsdaten zu und lösen Aktionen in angebundenen Systemen aus. Ein aktueller Google-Cloud-Bericht vom 24. August 2026 macht deutlich: Für den produktiven Einsatz reicht ein gutes Modell nicht – mittelständische Unternehmen brauchen eine belastbare Sicherheits- und Governance-Architektur.

KI-Agenten unterscheiden sich grundlegend von klassischen Chatbots. Sie beantworten nicht nur Fragen, sondern können Werkzeuge aufrufen, Dateien verändern, Tickets anlegen, Code ausführen oder Daten an Drittsysteme übertragen. Damit werden sie zu digitalen Akteuren mit eigenen Zugriffswegen – und im ungünstigsten Fall zu überprivilegierten „Insidern“.

Warum die Meldung für KMU relevant ist

Google Cloud bezeichnet Agenten als „ultimative Insider“: Unternehmen erlauben ihnen, E-Mails zu lesen, Datenbanken abzufragen und API-Aufrufe auszulösen. Laut dem am 24. August veröffentlichten Beitrag nennen 79 Prozent der befragten Tech-Verantwortlichen Sicherheit, Governance oder Betrieb als größte Herausforderung beim Skalieren von KI-Inferenz. 69 Prozent der befragten Führungskräfte bewerten eine Full-Stack-Plattform als kritische Voraussetzung; für 80 Prozent ist Daten-Compliance der wichtigste Faktor bei dieser Wahl.

Diese Zahlen stammen aus einer Herstellerstudie und sollten nicht als neutrale Marktprognose gelesen werden. Die technische Kernaussage ist dennoch nachvollziehbar: Sobald ein Agent handeln darf, verlagert sich das Risiko vom reinen Modelloutput auf Identitäten, Berechtigungen, Werkzeuge, Datenflüsse und Freigabeprozesse. Genau diese Schnittstellen sind in vielen mittelständischen Umgebungen historisch gewachsen und nicht für autonom agierende Software ausgelegt.

Quelle: Google Cloud: Empowering autonomous agents with advanced security governance

Das neue Risikomodell: Vom Assistenten zum handelnden System

Ein Chatbot ohne Werkzeuge erzeugt im Wesentlichen Text. Ein Agent mit Zugriff auf CRM, E-Mail, Dateispeicher und ERP kann dagegen reale Geschäftsprozesse beeinflussen. Ein scheinbar harmloser Auftrag wie „Bearbeite die neuen Kundenanfragen“ kann mehrere Schritte umfassen: Nachrichten lesen, Anhänge auswerten, Kundendaten abrufen, ein Angebot erstellen und eine E-Mail versenden.

Jeder dieser Schritte erweitert die Angriffsfläche. Eine manipulierte Nachricht kann versteckte Anweisungen enthalten. Ein kompromittiertes Werkzeug kann falsche Ergebnisse zurückgeben. Ein zu breit berechtigtes Konto kann Daten aus anderen Mandanten oder Abteilungen erreichen. Und eine fehlerhafte Entscheidung kann sofort eine externe Wirkung entfalten, wenn der Agent ohne Rückfrage versendet, bucht, löscht oder veröffentlicht.

Google unterscheidet in seiner MCP-Sicherheitsdokumentation deshalb zwischen „Human-in-the-Middle“ und „Agent-Only“. Im ersten Modus schlägt der Agent Aktionen vor, die ein Mensch einzeln freigibt. Im zweiten handelt er selbstständig; dort hängt die Sicherheit vollständig von Architektur und Kontrollen ab. Google nennt Prompt Injection, unsichere Tool-Ketten und naive Fehlerbehandlung als zentrale Risiken des autonomen Betriebs.

Quelle: Google Cloud MCP: AI security and safety

Die wichtigsten Angriffspfade

Indirekte Prompt Injection

Bei einer indirekten Prompt Injection steckt die schädliche Anweisung nicht in der ursprünglichen Nutzereingabe, sondern in Daten, die der Agent später liest – etwa in einer E-Mail, Webseite, PDF-Datei oder einem Datenbankeintrag. Wenn das System Daten und Befehle nicht zuverlässig trennt, kann der Agent den fremden Text als neue Arbeitsanweisung interpretieren.

Tool Poisoning und Schatten-Werkzeuge

Das Model Context Protocol (MCP) standardisiert die Anbindung externer Daten und Werkzeuge. Gerade diese Flexibilität schafft neue Risiken. OWASP führt unter anderem Token- und Secret-Lecks, schleichende Rechteausweitung, Tool Poisoning, unsichere Authentifizierung, fehlende Telemetrie und nicht autorisierte „Shadow MCP Servers“ in seiner MCP Top 10 auf. Google warnt zusätzlich davor, dass selbst ein zunächst vertrauenswürdiger MCP-Server dynamisch neue Werkzeuge ergänzen kann.

Überprivilegierte technische Konten

Viele Pilotprojekte verwenden ein vorhandenes Servicekonto, weil es bereits auf mehrere Systeme zugreifen kann. Das beschleunigt den Test, erschwert aber später Attribution und Begrenzung. Wenn mehrere Agenten dasselbe Konto nutzen, ist im Protokoll nicht mehr eindeutig erkennbar, welcher Agent welche Aktion ausgelöst hat. Langzeit-Schlüssel erhöhen zusätzlich das Risiko bei Diebstahl oder versehentlicher Offenlegung.

Quellen: OWASP MCP Top 10; Google Cloud MCP: AI security and safety

Sechs Kontrollen für einen produktionsreifen Agenten

1. Agenten und Werkzeuge inventarisieren

Der erste Schritt ist organisatorisch: Jeder produktive Agent erhält einen Eintrag in einem zentralen Register. Dokumentiert werden Zweck, Eigentümer, verwendetes Modell, Laufzeitumgebung, Datenquellen, Werkzeuge, technische Identität, erlaubte Aktionen und Abschaltweg. Das Register sollte auch externe MCP-Server und SaaS-Konnektoren enthalten.

Wichtig ist eine klare Trennung zwischen Experiment, internem Pilot und Produktion. Ein lokaler Testagent mit synthetischen Daten benötigt andere Kontrollen als ein Agent, der Kundendaten liest oder Bestellungen auslöst. Ohne diese Klassifizierung werden Pilotberechtigungen leicht zum dauerhaften Produktionsstandard.

2. Eine eigene Identität pro Agent vergeben

NIST arbeitet an Standards und praktischen Leitlinien für Identität und Autorisierung von Software- und KI-Agenten. Das zugrunde liegende Prinzip ist bereits heute anwendbar: Ein Agent muss identifizierbar, authentifiziert und seinem zulässigen Handlungsrahmen zugeordnet sein.

Google Agent Identity setzt dafür auf eine kryptografisch bestätigte Identität nach dem SPIFFE-Standard. Jeder Agent erhält eine eigene Identität; Zugriffe können dadurch direkt diesem Akteur zugeordnet werden. Im Unterschied zu gemeinsam genutzten Servicekonten sind diese Identitäten standardmäßig nicht zwischen mehreren Workloads geteilt, nicht imitierbar und erlauben Entwicklern keine Erzeugung langlebiger Servicekonto-Schlüssel. Das konkrete Google-Produkt ist nur eine mögliche Umsetzung – entscheidend ist das Architekturprinzip „eine Identität pro Agent“.

Quellen: NIST NCCoE: Software and AI Agent Identity and Authorization; Google Cloud IAM: Agent Identity overview

3. Least Privilege bis auf Werkzeugebene durchsetzen

Ein Agent sollte nur die Daten und Funktionen erreichen, die er für seine definierte Aufgabe benötigt. Ein Support-Agent braucht vielleicht Leserechte auf Wissensartikel und Schreibrechte für Ticketentwürfe, aber keinen Export der gesamten Kundendatenbank. Ein Einkaufsagent darf Preise abfragen, aber Bestellungen oberhalb eines Grenzwerts nicht selbst freigeben.

Berechtigungen sollten nicht nur pro System, sondern möglichst pro Werkzeug und Methode unterschieden werden. Lesezugriffe sind anders zu behandeln als Schreib-, Lösch- oder Ausführungsrechte. Zeitlich begrenzte Tokens und nutzerdelegierte Autorisierung sind dauerhaften, breit berechtigten API-Schlüsseln vorzuziehen.

4. Zugriffe über einen kontrollierten Gateway führen

Ein zentraler Kontrollpunkt kann Agent-zu-Tool- und Agent-zu-Agent-Verbindungen prüfen. Google beschreibt den Agent Gateway als Ein- und Ausgangspunkt für agentische Interaktionen. Er kombiniert ein Register genehmigter Agenten und Werkzeuge, Identitäten, Richtlinien und Telemetrie. Nicht registrierte entfernte MCP-Server und Werkzeuge sind standardmäßig blockiert; Zugriffe lassen sich nach Agent, Werkzeug und Lese- beziehungsweise Schreibart begrenzen.

Für KMU muss das nicht zwingend ein bestimmtes Cloud-Produkt sein. Entscheidend sind vier Funktionen: eine Allowlist zulässiger Ziele, zentrale Authentifizierung, Richtlinienprüfung vor dem Aufruf und vollständige Protokollierung. Direkte, unkontrollierte Internetzugriffe des Agenten sollten die Ausnahme sein.

Quelle: Google Cloud: Agent Gateway overview

5. Ein- und Ausgaben zur Laufzeit prüfen

Statische Tests vor dem Start reichen nicht, weil sich Nutzereingaben, Dokumente und Tool-Ausgaben laufend ändern. Google empfiehlt, Daten und Anweisungen zu trennen, Speicher zwischen Nutzern oder Mandanten zu isolieren sowie MCP-Aufrufe und Antworten zu prüfen. Model Armor ist ein Beispiel für eine Laufzeitkontrolle gegen Prompt Injection und den Abfluss sensibler Daten.

Eine solche Schutzschicht reduziert Risiken, ersetzt aber keine Berechtigungsgrenzen. Ein Filter kann Angriffe übersehen oder legitime Inhalte blockieren. Deshalb gilt Defense in Depth: selbst wenn eine manipulierte Anweisung durchkommt, darf der Agent nur einen begrenzten Satz von Aktionen ausführen.

Quellen: Google Cloud MCP: AI security and safety; Google Cloud: Model Armor

6. Kritische Aktionen freigeben und vollständig protokollieren

Nicht jede Aktion benötigt einen Menschen. Recherche oder das Erstellen eines Entwurfs kann häufig automatisiert erfolgen. Geldtransfers, Löschvorgänge, Veröffentlichung, Vertragsversand, Änderungen an Produktivsystemen oder die Ausgabe besonders sensibler Daten sollten dagegen eine explizite Freigabe auslösen.

Die Protokollierung muss mehr erfassen als die abschließende Textantwort: Nutzer, Agentenidentität, Modell- und Promptversion, aufgerufene Werkzeuge, Parameter, relevante Ergebnisse, Richtlinienentscheidung, Freigabe und externe Wirkung. Geheimnisse und unnötige personenbezogene Daten gehören dabei nicht unmaskiert ins Log. Zusätzlich braucht jeder Agent einen getesteten Not-Aus und einen Verantwortlichen für Sicherheitsvorfälle.

Quellen: Google Cloud: Advanced security governance; OWASP MCP Top 10

Zielbild für den Mittelstand

Diese Staffelung verhindert zwei typische Extreme: unkontrollierte Experimente mit Produktivdaten und ein überdimensioniertes Governance-Programm, das jede sinnvolle Automatisierung blockiert.

Ein umsetzbarer 30-Tage-Plan

Woche 1: Transparenz schaffen

Erfassen Sie laufende Agenten, persönliche Automationen, MCP-Server, Browser-Erweiterungen und technische Konten. Benennen Sie für jeden produktionsnahen Einsatz einen fachlichen und einen technischen Eigentümer. Stoppen Sie unbekannte oder nicht mehr benötigte Integrationen.

Woche 2: Rechte reduzieren

Ersetzen Sie gemeinsam genutzte Konten, wo möglich, durch eigene Identitäten. Entfernen Sie pauschale Administratorrechte, trennen Sie Lese- und Schreibzugriffe und hinterlegen Sie Geheimnisse in einem zentralen Secret Store. Legen Sie fest, welche Systeme und Werkzeuge überhaupt erreichbar sein dürfen.

Woche 3: Freigaben und Protokolle einführen

Definieren Sie Aktionen mit externer oder schwer umkehrbarer Wirkung. Bauen Sie dafür Freigabeschritte, Betrags- oder Mengenlimits und einen Abbruchpfad ein. Prüfen Sie, ob Protokolle die Kette von Nutzer über Agent und Werkzeug bis zur ausgeführten Aktion nachvollziehbar machen.

Woche 4: Angriff und Ausfall testen

Testen Sie manipulierte E-Mails, Dokumente und Tool-Ausgaben, unerwartete neue Werkzeuge, abgelaufene Tokens, Ausfälle angebundener APIs und fehlerhafte Freigaben. Üben Sie das Abschalten des Agenten und die Wiederherstellung veränderter Daten. Dokumentieren Sie offene Risiken und entscheiden Sie bewusst über den Produktivstart.

Herstellerprodukt oder offene Architektur?

Google verbindet Agent Identity, Agent Gateway, IAM, Model Armor und Observability in einer Plattform. Das kann Integrationsaufwand reduzieren, schafft aber auch Bindungen an einen Anbieter. Unternehmen mit Multi-Cloud-, On-Premises- oder spezialisierten SaaS-Anforderungen sollten die benötigten Kontrollfunktionen unabhängig vom Produktnamen definieren.

Der sinnvolle Auswahlmaßstab lautet daher nicht „Welches Modell ist am besten?“, sondern: Können wir jede Agentenaktion eindeutig zuordnen, begrenzen, prüfen und bei Bedarf stoppen? Offene Standards wie SPIFFE für Workload-Identitäten, OAuth für delegierte Berechtigungen sowie MCP und A2A für Interaktionen können Portabilität unterstützen. Sie garantieren jedoch keine sichere Konfiguration; Protokolle verbinden Systeme, Governance begrenzt deren Verhalten.

Quellen: Google Cloud IAM: Agent Identity overview; NIST NCCoE: Agent Identity and Authorization

Fazit: Autonomie braucht einen überprüfbaren Handlungsrahmen

Der aktuelle Google-Cloud-Bericht rückt ein Thema in den Vordergrund, das für KMU wichtiger ist als der nächste Modellbenchmark: Agenten werden zu eigenständigen digitalen Akteuren. Wer ihnen Zugriff auf E-Mail, Datenbanken und APIs gibt, muss Identität, Rechte, Datenflüsse und Freigaben genauso ernst nehmen wie bei menschlichen Beschäftigten und klassischen technischen Konten.

Die pragmatische Reihenfolge lautet: Agenten inventarisieren, jedem Agenten eine eigene Identität geben, Rechte auf notwendige Werkzeuge begrenzen, Interaktionen zentral kontrollieren, kritische Aktionen freigeben und alles revisionsfähig protokollieren. So entsteht kein vollkommen risikofreier Betrieb – aber ein System, dessen Handlungen nachvollziehbar, begrenzt und stoppbar bleiben.

EIST Consulting unterstützt mittelständische Unternehmen bei der Architektur sicherer KI-Agenten, der Auswahl geeigneter Cloud- und Open-Source-Komponenten sowie beim Aufbau pragmatischer Governance- und Betriebsprozesse.