Agentic AI: Harness sicher steuern

KI-Agenten verändern die Sicherheitsbetrachtung gegenüber rein dialogorientierten Sprachmodellen. Sobald ein Modell über APIs auf Unternehmensdaten zugreift, Werkzeuge aufruft, Aufgaben delegiert oder Aktionen in Zielsystemen auslöst, entsteht eine Ausführungskette mit eigenen Identitäts-, Berechtigungs- und Nachweisrisiken. Für das ISMS ist deshalb nicht nur das verwendete Modell relevant. Ebenso wichtig ist der Agentic-AI-Harness: die Software- und Kontrollschicht, welche Modell, Datenquellen, Speicher, Tools, Identitäten und Ausführungsumgebungen verbindet.

Dieser Blickwinkel unterscheidet sich von einer operativen Einführungscheckliste für einzelne Agenten. Im Vordergrund steht die Frage, wie eine Agentenplattform als zusammenhängendes Governance-Objekt geführt wird: mit eindeutigen Verantwortlichkeiten, vollständigem Inventar, kontrollierten Lieferbeziehungen und belastbaren Nachweisen über den gesamten Workflow.

Warum der Harness eine eigenständige Sicherheitsgrenze ist

Das Australian Cyber Security Centre (ASD/ACSC) beschreibt den Harness als Schicht, die einem Large Language Model externe Tools, Datenquellen, Speicher- und Planungsabläufe zugänglich macht und zugleich Aktions- sowie Ausführungsberechtigungen durchsetzt. Zu den sicherheitsrelevanten Bestandteilen gehören etwa Tool-Register, Connectoren, Berechtigungssysteme, Memory- und Session-Stores, Ausführungsumgebungen, Audit- und Observability-Funktionen sowie Update- und Supply-Chain-Pfade.

Damit verschiebt sich die Sicherheitsgrenze. Ein Modell kann eine Eingabe fehlinterpretieren; die folgenschwere Wirkung entsteht aber häufig erst, wenn der Harness daraus einen Tool-Aufruf, eine Datenabfrage oder eine Änderung in einem Unternehmenssystem macht. Das ASD/ACSC weist ausdrücklich darauf hin, dass sich Prompt Injection nicht verlässlich allein im Modell beheben lässt. Erforderlich sind daher nachgelagerte technische und organisatorische Kontrollen an den Integrationspunkten. Der Harness sollte folglich im Asset- und Konfigurationsmanagement nicht als unsichtbares Implementierungsdetail, sondern als kontrollrelevante Plattform erfasst werden.

Ein belastbares Inventar kann mindestens Zweck und verantwortliche Stelle, Modellanbieter und Harness-Version, Agentenrollen, Datenklassen, Speicherkomponenten, Tools, APIs, Connectoren, Ausführungsumgebungen sowie externe Unterauftragnehmer abbilden. Erst diese Sicht erlaubt es, Risiken konsistent mit dem jeweiligen Geschäftsprozess, den Schutzbedarfen und Abhängigkeiten zu bewerten.

Multi-Agent-Systeme brauchen eine Systemperspektive

In Multi-Agent-Systemen werden Aufgaben zwischen spezialisierten Komponenten verteilt. Das kann die Nachvollziehbarkeit erschweren: Delegationsketten, gemeinsamer Kontext, gemeinsame Speicher oder Infrastruktur und Vertrauensbeziehungen verbinden die Beteiligten zu einem Gesamtsystem. Eine NIST-Präsentation zu Multi-Agent-Systemen ordnet Identität, Vertrauen und Herkunft von Informationen daher als systemweite Eigenschaften ein. Ein einzelner Kompromittierungsfall kann über Delegation oder gemeinsame Ressourcen die Nachweisbarkeit des gesamten Workflows beeinträchtigen.

Praktisch sollte eine Organisation ein Multi-Agent-System aus Sicherheitsgründen als einen Agenten behandeln, wie es auch das ASD/ACSC empfiehlt. Das bedeutet nicht, dass alle Komponenten dieselben Rechte erhalten dürfen. Vielmehr muss das Sicherheitsmodell den vollständigen Ablauf abbilden: Wer hat den Vorgang ausgelöst? Welcher Agent durfte welche Teilaufgabe übernehmen? Welche Autorität wurde delegiert? Welche Daten oder Werkzeuge wurden verwendet? Und welche Aktionen waren am Ende zulässig?

Autorisierung sollte daher bei mehrstufigen Workflows nicht ausschließlich pro einzelnem API-Aufruf erfolgen. Sinnvoll ist eine workflowbezogene Kontrolle von ursprünglichem Auftrag, erlaubten Folgeschritten, Wirkungs- oder Budgetgrenzen und Eskalationsbedingungen. Agentenübergreifende Telemetrie, Provenance Tracking und kontinuierliche ereignisgesteuerte Sicherheitstests unterstützen diese Systemperspektive.

Service-Identitäten statt übertragener Nutzerrechte

Ein zentrales Governance-Thema ist die Identität des Agenten. Werden menschliche oder Enterprise-Zugangsdaten an Agenten weitergegeben, entstehen Verantwortlichkeits- und Nachweisprobleme. NIST hebt als Gegenmodell eigenständige Agentenidentitäten mit zugeordneten Credentials und Berechtigungen hervor und ordnet statische API-Schlüssel sowie langlebige Bearer Tokens als problematisch ein.

Für die IAM- und gegebenenfalls PAM-Governance folgt daraus: Jeder Agent sollte eine eigene, nicht geteilte Service-Identität erhalten. Rechte sind auf konkrete Aufgaben, Ressourcen, Umgebungen und Zeiträume zu begrenzen. Wo technisch möglich, sind kurzlebige Credentials, geregelte Token-Ausstellung und Rotation gegenüber dauerhaft hinterlegten Geheimnissen vorzuziehen. Besonders privilegierte Administrationszugriffe sollten von regulären Agentenfunktionen getrennt bleiben.

Diese Grundsätze müssen in einen nachvollziehbaren Identitätslebenszyklus überführt werden: Beantragung, Freigabe, technische Einrichtung, Änderung, regelmäßige Rechteprüfung und Entzug. Für die von der Durchführungsverordnung (EU) 2024/2690 erfassten digitalen Einrichtungen konkretisieren die Zugangskontrollvorgaben unter anderem dokumentierte Rechtevergabe und -entziehung, Least Privilege, eindeutige Identitäten, Register über gewährte Rechte, Logging und regelmäßige Überprüfungen. Die Verordnung gilt jedoch nicht pauschal für alle NIS2-Einrichtungen.

Human Oversight als wirksamer Kontrollprozess

Menschliche Freigaben sind keine universelle Antwort auf Agentenrisiken. Sie sind dort sinnvoll, wo ein Vorgang erhebliche oder irreversible Folgen haben kann: etwa vor Berechtigungsänderungen, Produktionsdeployments, externen Datenübermittlungen, Transaktionen oder Zugriffen auf besonders schutzbedürftige Informationen. Die freigebende Person benötigt dabei verständlichen Kontext zu Auftrag, beabsichtigter Aktion, betroffenen Zielsystemen, Datenbezug und erwarteter Wirkung. Wiederholte Pauschalbestätigungen ohne diese Informationen schaffen keine belastbare Aufsicht.

Die technische Gestaltung sollte Stop-, Ablehnungs- und Eskalationsentscheidungen auch tatsächlich durchsetzen können. Dazu gehören Sperren einzelner Tools und Connectoren, Grenzen für zulässige Folgeaktionen sowie bei Bedarf eine Rücknahme oder Isolation von Änderungen. Für Hochrisiko-KI-Systeme verlangt der AI Act ein dokumentiertes, fortlaufendes Risikomanagement sowie eine dem Risiko, Autonomiegrad und Einsatzkontext angemessene menschliche Aufsicht. Eine allgemeine Agentenplattform ist dadurch nicht automatisch ein Hochrisiko-KI-System; maßgeblich bleiben Rolle, Einsatz und Risikoklassifizierung.

Telemetrie und Incident Response über die gesamte Kette

Einzelne Tool-Logs reichen bei delegierten Workflows nicht aus. Das Mindest-Telemetriemodell sollte die auslösende Person oder Anwendung, Agentenidentität, delegierte Autorität, Modell- und Harness-Version, Kontext- und Datenquelle, Tool-Aufruf mit Parametern, Ergebnis, Freigabeentscheidung, Zielsystem und eine durchgehende Korrelation enthalten. Diese Daten unterstützen nicht nur den SOC-Betrieb, sondern auch interne Untersuchungen, Auditierbarkeit und die Bewertung fehlerhafter oder missbräuchlicher Entscheidungen.

Notfallverfahren sollten vor einem breiten Rollout erprobt werden. Dazu zählen Credential-Entzug oder -Rotation, die Sperrung einzelner Tools und Connectoren, die Deaktivierung eines Agenten, die Isolation kompromittierter Speicher- und Kontextquellen sowie die forensische Sicherung von Auditdaten. Die Erklärung des Canadian Centre for Cyber Security zu gemeldeter mutmaßlicher KI-Agentenaktivität gegen öffentlich erreichbare Regierungswebsites ist dabei kein Nachweis einer bestätigten Systemkompromittierung. Sie unterstreicht aber die Aktualität, agentische Aktivitäten in Erkennung und Reaktion mitzudenken.

ISMS, Beschaffung und Lieferantensteuerung verbinden

Eine isolierte Agentenrichtlinie bleibt meist zu eng. Fachlich tragfähiger ist die Integration in bestehende Prozesse für KI-Risikobewertung, Asset- und Konfigurationsmanagement, IAM/PAM, Secure Development, Change Management, Lieferantensteuerung, Logging, Incident Response, BCMS und Management-Reporting. Bei der Beschaffung von Agentenplattformen sollten Unternehmen insbesondere Architektur und Datenflüsse, Mandantentrennung, Identity Federation, Token-Management, Tool- und Connector-Governance, Audit-Export, Sicherheitsupdates, Subprozessoren, Modellwechsel sowie Exit- und Löschkonzepte bewerten. Ebenso wichtig sind dokumentierte Grenzen der angebotenen Sicherheitskontrollen.

Für vom Anwendungsbereich der NIS2 erfasste Unternehmen ist diese Einbettung besonders naheliegend. Artikel 21 nennt unter anderem Incident Handling, Business Continuity, Lieferkettensicherheit sowie Sicherheit bei Beschaffung, Entwicklung und Wartung als Elemente risikoorientierter Maßnahmen. Daraus folgt keine eigenständige, allgemein geltende Pflicht, einen „AI Harness“ als Kategorie zu führen. Es ist jedoch eine nachvollziehbare Risikobewertung, Agentenplattformen, deren Identitäten, Connectoren und externe Anbieter in die vorhandenen Governance- und Sicherheitsprozesse einzubeziehen.

Der entscheidende Kontrollgegenstand ist damit nicht die Modellantwort allein, sondern die kontrollierte Handlungskette. Wer Harness, Agenten, Identitäten, Tools und Lieferantenbeziehungen als zusammenhängendes ISMS-Objekt steuert, schafft eine bessere Grundlage für sichere Skalierung, nachvollziehbare Verantwortlichkeiten und wirksame Reaktion auf Störungen.