Welche Aufsicht Verteidigungssysteme ihren KI-Agents schulden

Ein neuer Ingenieur in einem Verteidigungsprogramm erhält am ersten Tag keinen Zugriff auf alle kontrollierten Dateien. Er bekommt Zugriff entsprechend seiner Sicherheitsfreigabe und Rolle, steht unter Aufsicht eines Programmleiters und es wird dokumentiert, welche Dateien er bearbeitet hat. Die meisten Auftragnehmer, die KI-Agents in Programmsysteme integrieren, verzichten auf all diese Maßnahmen. Der Agent wird angebunden, erhält weitreichende Zugriffsrechte für schnelle Ergebnisse und arbeitet mit deutlich weniger Kontrolle, als es selbst der neueste und am wenigsten vertraute Ingenieur je erwarten würde.

Diese Lücke ist kein kleiner Fehler. Ein KI-Agent, der technische Dateien lesen, Kommunikationen versenden oder Daten im Auftrag eines Auftragnehmers bewegen kann, ist faktisch ein Akteur mit Zugriff auf kontrollierte Systeme – genau wie ein Ingenieur. Dass er auf einem Modell und nicht auf der Gehaltsliste läuft, ändert nichts daran, worauf er zugreifen kann oder was passieren könnte, wenn er auf die falschen Programmdaten zugreift. Dieser Artikel beleuchtet, warum KI-Agents in Verteidigungsprogrammen routinemäßig weniger Governance unterliegen als Menschen und was es tatsächlich bedeutet, denselben Standard anzuwenden.

Executive Summary

Auftragnehmer, die einem neuen Ingenieur niemals uneingeschränkten Zugriff auf alle kontrollierten Dateien geben würden, gewähren KI-Agents genau diesen Zugriff – weil deren Einsatz als technisches Integrationsproblem und nicht als Governance-Frage betrachtet wird. Das Ergebnis sind Systeme, die kontrollierte Daten lesen, bewegen und versenden können – mit weniger Kontrollen als die Menschen, die sie entwickelt haben. Für Sicherheitsverantwortliche in Programmen stellt sich die praktische Frage: Wäre dieses Zugriffslevel akzeptabel, wenn der Akteur ein Mensch wäre? Und falls nicht, warum ist es für einen Agent akzeptabel?

wichtige Erkenntnisse

1. KI-Agents in Verteidigungsprogrammen erhalten häufig weitergehenden Zugriff auf kontrollierte Daten als neue Mitarbeiter. Die Geschwindigkeit der Einführung übertrifft die grundlegende Governance, die Auftragnehmer bereits für Menschen anwenden.
2. Ein Agent sollte die Berechtigungen der Person übernehmen, die ihn autorisiert, und nicht über ein separates, dauerhaftes Zugangskonto verfügen. Ein weitreichendes Servicekonto für einen KI-Agenten schafft genau jene überprivilegierten Zugriffe, die Auftragnehmer für Menschen über Jahre hinweg abgeschafft haben.
3. Sensible Aktionen, wie das externe Teilen von CUI, erfordern eine Freigabe – unabhängig davon, wer oder was sie auslöst.
4. Jede KI-Aktion muss einer bestimmten Person zugeordnet und mit derselben Sorgfalt protokolliert werden wie menschliche Aktivitäten. Ein Audit-Trail, der „die KI war es“ als ausreichende Zuordnung betrachtet, ist kein Audit-Trail.
5. Governance, die von Anfang an für KI-Agents entwickelt wird, erfordert keine neue Infrastruktur. Das Zugriffs-, Freigabe- und Protokollierungsmodell, das Auftragnehmer bereits für Mitarbeiter nutzen, lässt sich direkt auf Agents übertragen.

Warum KI-Agents mit weniger Kontrolle als Menschen eingebunden werden

Die Lücke entsteht selten absichtlich. Sie ist ein Nebeneffekt der rasanten Entwicklung von Agent-Funktionen – vom Experiment zum operativen Einsatz – und der unterschiedlichen Sichtweisen von Technik- und Sicherheitsteams auf das Problem.

Die Geschwindigkeit der Einführung überholt Governance by Design

Das Anbinden eines KI-Agents an ein Programmsystem ist oft eine Konfigurationsaufgabe, die in wenigen Minuten erledigt ist: API-Schlüssel vergeben, Berechtigungsumfang freigeben, fertig. Die entsprechende Governance für einen neuen Ingenieur – Sicherheitsüberprüfung, definierte Rollen, dokumentierte Zugriffsprüfung – wurde für Menschen entwickelt, die in Programmen mit menschlichem Tempo starten.

„Es ist nur ein Tool“ unterschätzt, was ein Agent leisten kann

Da ein KI-Agent als Tool und nicht als Anwender beschrieben wird, betrachten Auftragnehmer ihn eher wie Software als wie eine Person mit Zugriff auf kontrollierte Daten. Ein Tool, das eigenständig eine kontrollierte Datei lesen, sie weiterleiten oder auf Anweisungen im verarbeiteten Inhalt reagieren kann, trifft Entscheidungen – ganz anders als eine einfache Tabellenkalkulation.

Was „gleiche Governance wie für Menschen“ tatsächlich bedeutet

Die Übertragung von Governance auf KI-Agents ist keine neue Disziplin. Es sind die gleichen drei Komponenten, die Auftragnehmer bereits für Menschen anwenden – nur konsequent auch für Agents.

Identitätsübernahme statt dauerhafter Privilegien

Die wichtigste Designentscheidung ist, ob ein Agent mit einem eigenen, breit angelegten und dauerhaften Zugang arbeitet oder die spezifischen Berechtigungen der autorisierenden Person für die jeweilige Sitzung und Aufgabe übernimmt. Ein dauerhaftes Servicekonto mit weitreichendem Zugriff auf CUI schafft exakt jene überprivilegierten Konten, die Sicherheitsteams über Jahre hinweg abschaffen wollten. Ein Agent, der nur das tun kann, was der authentifizierte Anwender ohnehin darf, ist genauso begrenzt wie ein menschlicher Kollege, der im Auftrag handelt.

Freigabeschritte vor kritischen Aktionen

Ein Ingenieur, der CUI extern teilt, muss in der Regel vorab eine Bestätigung geben. Ein KI-Agent, der eine vergleichbare Aktion ausführt, sollte denselben Freigabeschritt durchlaufen: Ein Moment, in dem ein Mensch Umfang, Empfänger oder Konsequenzen prüft, bevor die Aktion abgeschlossen wird.

Zuordnung und Audit – nicht nur Aktivitätsprotokolle

Ein menschlicher Audit-Trail ordnet jede Aktion einer bestimmten, verantwortlichen Person zu. Die Aktionen eines KI-Agents müssen denselben Standard erfüllen: Nicht „ein automatisierter Prozess hat das getan“, sondern welcher Anwender den Agent autorisiert hat, was er durfte und was er tatsächlich getan hat.

Wo die Lücke bei Verteidigungsauftragnehmern praktisch sichtbar wird

Das häufigste Muster ist ein einziges, breit angelegtes Zugangskonto, das einmal vergeben und dauerhaft genutzt wird – zusammen mit Agents, die CUI ohne jeglichen Freigabeschritt teilen, weil das Einbauen dieser Pause mehr Entwicklungsaufwand erfordert als das Durchwinken des Agents. Selbst wenn Aktivitäten protokolliert werden, kann das Protokoll oft nicht beantworten, welche konkrete Person für eine Aktion verantwortlich ist – und fällt damit durch denselben Test, den ein menschlicher Audit-Trail ohne namentlichen Anwender nicht bestehen würde.

Agent-Governance auf dem bestehenden Zugriffsmodell aufbauen

Der praktische Weg ist kein neues Governance-Framework speziell für KI. Es geht darum, das Identitäts-, Freigabe- und Audit-Modell, das ein Auftragnehmer bereits für seine Mitarbeiter nutzt, konsequent auch auf Agents anzuwenden.

Wie eine Data Control Plane Governance auf KI-Agents auf menschlichem Niveau bringt

Die Kiteworks Data Control Plane verbindet KI-Agents über eine sichere Schnittstelle mit OAuth 2.0-Authentifizierung. Jede Agent-Operation übernimmt die bestehenden Berechtigungen des authentifizierten Anwenders – statt eines separaten, dauerhaften Zugangskontos. Dynamische attributbasierte Richtlinien bewerten Agent-Anfragen genauso wie menschliche Anfragen. Sensible Aktionen, wie Mitgliederänderungen oder ausgehende Übertragungen, erfordern eine explizite Bestätigung, bevor sie ausgeführt werden. Administratoren können destruktive Tools global deaktivieren oder einschränken, welche Aktionen ein Agent überhaupt versuchen darf. Jede Agent-Operation wird in einem fälschungssicheren, nicht gedrosselten Audit-Log erfasst, dem autorisierenden Anwender zugeordnet und direkt in SIEM-Tools eingespeist – so ist die Agent-Aktivität genauso nachvollziehbar wie die eines Ingenieurs.

Auftragnehmer, die prüfen möchten, ob ihre aktuellen KI-Agent-Implementierungen dieselbe Zugriffsprüfung bestehen würden wie neue Mitarbeiter, können eine individuelle Demo vereinbaren, um zu sehen, wie identitätsbasierte, auditierte Agent-Governance in ihrer eigenen Umgebung funktioniert.