NIST 800-171, CUI und KI: Was Ihrem System-Sicherheitsplan fehlt

Tausende Organisationen verarbeiten kontrollierte, nicht klassifizierte Informationen (CUI) im Rahmen von Regierungsaufträgen, ohne sich im CMMC-Zertifizierungsprozess zu befinden. Bundesauftragnehmer, Forschungsuniversitäten, staatliche Behörden, Technologielieferanten und professionelle Dienstleister, die CUI gemäß DFARS 252.204-7012 erhalten, müssen die 110 Sicherheitspraktiken von NIST SP 800-171 implementieren und deren Umsetzung in einem System Security Plan (SSP) dokumentieren. Die meisten haben dies für den Zugriff menschlicher Anwender auf CUI getan. Für den Zugriff von KI-Agents hingegen fast niemand.

Diese Lücke ist nicht theoretisch. KI-Agents werden in DFARS-regulierten Organisationen für Angebotserstellung, technische Dokumentation, Vertragsverwaltung und Lieferkettenprozesse eingesetzt – alles Bereiche, in denen regelmäßig CUI verarbeitet wird. Diese Einsätze sind in bestehenden SSPs nicht abgedeckt. Sie werden nicht in Risikobewertungen berücksichtigt. Sie sind nicht in Zugriffsrichtlinien adressiert. Und sie erzeugen nicht die Audit-Logs, die laut den Audit- und Verantwortlichkeitspraktiken von NIST 800-171 für CUI-Zugriffsereignisse vorgeschrieben sind.

Dieser Beitrag unterscheidet sich vom CMMC-Artikel dieser Serie, der sich auf den C3PAO-Bewertungsprozess für Auftragnehmer der Verteidigungsindustrie konzentriert, die eine Zertifizierung anstreben. Hier geht es um die größere Gruppe von Organisationen, die CUI im Rahmen von DFARS-Verträgen verarbeiten, aber nicht auf dem CMMC-Zertifizierungspfad sind – und deren NIST 800-171-Compliance-Pflichten für KI-Agenten-Zugriffe auf CUI unabhängig vom Zertifizierungsstatus gelten.

Executive Summary

Kernaussage: Die 110 Sicherheitspraktiken von NIST 800-171 gelten für jedes System, das CUI verarbeitet, speichert oder überträgt – einschließlich KI-Agents. Organisationen, die 800-171-Kontrollen für den Zugriff menschlicher Anwender auf CUI umgesetzt haben, diese aber nicht auf KI-Agenten-Workflows ausgedehnt haben, weisen eine wesentliche Compliance-Lücke in ihrem System Security Plan auf. Diese Lücke stellt eine DFARS-Vertragsverletzung, potenzielle Risiken nach dem False Claims Act und eine Schwachstelle in der Cybersicherheitslage dar, die Angreifer in der Regierungslieferkette gezielt ausnutzen.

Warum das relevant ist: DFARS 252.204-7012 verpflichtet Auftragnehmer, die NIST 800-171-Compliance auch auf Subunternehmer und Dienstleister auszuweiten, die CUI in ihrem Auftrag verarbeiten. KI-Anbieter, deren Infrastruktur CUI verarbeitet – selbst vorübergehend während der Modellausführung –, sind Teil dieser Flow-Down-Kette. Eine Organisation, die keine NIST 800-171-konformen Zugriffskontrollen und Audit-Trails für KI-Agenten-Zugriffe auf CUI nachweisen kann, erfüllt ihre DFARS-Vertragsbedingungen nicht – unabhängig davon, ob eine CMMC-Bewertung ansteht.

wichtige Erkenntnisse

1. NIST 800-171-Compliance-Pflichten ergeben sich aus DFARS-Verträgen, nicht aus der CMMC-Zertifizierung. Jede Organisation, die unter DFARS 252.204-7012 tätig ist, muss alle 110 NIST 800-171-Praktiken für Systeme umsetzen, die CUI verarbeiten. Diese Verpflichtung besteht unabhängig von CMMC. Organisationen, die CUI verarbeiten, aber noch nicht im CMMC-Zertifizierungsprozess sind, sind nicht von 800-171 ausgenommen – sie bestätigen die Compliance lediglich per Selbstauskunft statt durch eine Drittbewertung.
2. Jeder KI-Agent, der CUI verarbeitet, ist ein Systembestandteil, der im SSP abgebildet werden muss. Der System Security Plan muss alle Systeme und Komponenten beschreiben, die CUI verarbeiten, speichern oder übertragen, sowie die jeweiligen Schutzmaßnahmen. Ein SSP, der Kontrollen für Workstations, Server und E-Mail-Systeme aufführt, aber KI-Agents mit Zugriff auf CUI-Repositorys nicht erwähnt, ist unvollständig – und ein unvollständiger SSP ist selbst ein 800-171-Compliance-Mangel.
3. NIST 800-171 Rev. 3 hat die Anforderungen an Zugriffskontrolle und Audit für KI-Einsätze verschärft. Die Überarbeitung 2024 von NIST 800-171 brachte erweiterte Anforderungen an die Granularität der Zugriffskontrolle, den Detaillierungsgrad von Audit-Logs und das Supply Chain Risk Management. Damit sind bestehende KI-Architekturen – die meist nur Sitzungsberechtigungen und Infrastruktur-Logging bieten – noch weniger für 800-171-Compliance geeignet als unter Rev. 2.
4. Die DFARS-Flow-Down-Pflicht erweitert die NIST 800-171-Anforderungen auf KI-Anbieter. Nach DFARS 252.204-7012 müssen Auftragnehmer die 800-171-Compliance-Anforderungen an Subunternehmer und Dienstleister weitergeben, die CUI in ihrem Auftrag verarbeiten. Ein KI-Anbieter, dessen Infrastruktur CUI während der Modellausführung verarbeitet, ist ein abgedeckter Subunternehmer oder Dienstleister. Der Auftragnehmer kann sich nicht auf allgemeine Sicherheitszertifizierungen des Anbieters verlassen – der Anbieter muss die 800-171-Anforderungen für den Umgang mit CUI erfüllen, und der Auftragnehmer muss dies im Vendor Risk Management dokumentieren.
5. False Claims Act-Risiken bestehen für Organisationen mit unzutreffenden NIST 800-171-Selbstauskünften. Das US-Justizministerium hat False Claims Act-Verfahren gegen Regierungsauftragnehmer eingeleitet, die unzutreffende NIST 800-171-Selbstauskünfte abgegeben haben. Eine Organisation, die 800-171-Compliance bestätigt, während KI-Agents ohne die erforderlichen Zugriffskontrollen und Audit-Trails mit CUI arbeiten, gibt möglicherweise eine falsche Zertifizierung ab – mit FCA-Risiken bis hin zu einzelnen Führungskräften.

NIST 800-171 und der SSP: Was KI-Einsätze abdecken müssen

NIST 800-171 gliedert seine 110 Sicherheitspraktiken in 14 Kontrollfamilien. Drei davon sind besonders relevant, wenn KI-Agents auf CUI zugreifen: Access Control (3.1), Audit and Accountability (3.3) sowie Identification and Authentication (3.5). Eine vierte – Configuration Management (3.4) – wird relevant, wenn KI-Agenten-Komponenten Teil der Systemgrenze sind. Jede dieser Familien enthält spezifische Praktiken, die im SSP adressiert und von KI-Einsätzen erfüllt werden müssen, damit das Unternehmen seinen DFARS-Pflichten nachkommt.

Access Control (3.1): Autorisierter Zugriff und Minimalprinzip

Praktik 3.1.1 verlangt, dass der Zugriff auf CUI auf autorisierte Anwender, Prozesse im Auftrag autorisierter Anwender und Geräte beschränkt ist. Praktik 3.1.2 fordert, den Zugriff auf die Transaktionen und Funktionen zu beschränken, die autorisierte Anwender ausführen dürfen. Für KI-Agents bedeuten diese beiden Praktiken dieselben Anforderungen wie CMMC AC.1.001 und AC.2.006: Der Zugriff muss authentifiziert, einer autorisierten Person zugeordnet und auf das für die jeweilige Aufgabe notwendige Minimum beschränkt sein. Ein KI-Agent, der über ein gemeinsames Servicekonto mit breitem CUI-Repository-Zugriff arbeitet, erfüllt keine dieser Praktiken.

Praktik 3.1.3 verlangt, den Fluss von CUI gemäß genehmigter Autorisierungen zu steuern. Für KI-Agents bedeutet das, dass die Governance-Schicht verhindern muss, dass kontrollierte Daten an unautorisierte Ziele gelangen – etwa externe APIs, nicht-DFARS-konforme Systeme oder Infrastruktur außerhalb der autorisierten CUI-Grenze. Systemprompts können diese Steuerung nicht erzwingen; nur eine ABAC-Richtlinie auf Datenebene kann technisch verhindern, dass CUI unautorisiert abfließt – unabhängig davon, wie das Modell instruiert wurde.

Audit and Accountability (3.3): Was das Log enthalten muss

Praktik 3.3.1 verlangt, System-Audit-Logs zu erstellen und aufzubewahren, um die Überwachung, Analyse, Untersuchung und Berichterstattung über unrechtmäßige oder unautorisierte Systemaktivitäten zu ermöglichen. Praktik 3.3.2 verlangt, dass die Identität der Anwender, die für die Aktionen ihrer Prozesse verantwortlich sind – einschließlich Prozesse, die in ihrem Auftrag handeln – sichergestellt wird. Für KI-Agents ist 3.3.2 die Praktik, die am direktesten eine Delegationskette verlangt: Das Audit-Log muss nicht nur erfassen, dass ein Agent eine Aktion ausgeführt hat, sondern auch die Identität der Person, die diese Aktion autorisiert und verantwortet.

Standard-Infrastruktur-Logs und KI-Inferenz-Logs erfassen in der Regel, welche Systemaktion ausgeführt wurde, aber nicht, wer im Sinne von 3.3.2 dafür verantwortlich ist. Eine Organisation, deren KI-Agenten-Audit-Trail API-Aufrufe eines Servicekontos protokolliert, ohne diese Aufrufe der verantwortlichen Person zuzuordnen, kann Praktik 3.3.2 für diese CUI-Zugriffsereignisse nicht erfüllen.

Identification and Authentication (3.5): Eindeutige Identifikation erforderlich

Praktik 3.5.1 verlangt, dass Anwender und Geräte – und insbesondere Prozesse wie KI-Agents – vor dem Zugriff auf Unternehmenssysteme und CUI identifiziert und authentifiziert werden. Praktik 3.5.2 fordert, Identitäten vor dem Zugriff zu authentifizieren. Für KI-Agents bedeutet eindeutige Identifikation, dass jeder Agent über ein eigenes, überprüfbares Identitätszertifikat verfügen muss – kein gemeinsames Servicekonto, dessen Identität über mehrere Agents, Workflows oder Zugriffsereignisse hinweg nicht unterscheidbar ist.

Supply Chain Risk Management (3.16): Die KI-Anbieter-Dimension

NIST 800-171 Rev. 3 hat explizite Anforderungen an das Supply Chain Risk Management in der Kontrollfamilie 3.16 eingeführt. Praktik 3.16.1 verlangt, einen Plan für das Supply Chain Risk Management zu erstellen und zu pflegen. Für Organisationen, die KI-Agents mit CUI einsetzen, ist die Beziehung zum KI-Anbieter ein Supply-Chain-Risiko, das bewertet und dokumentiert werden muss: Wie schützt der Anbieter CUI während der Modellausführung, welche Meldepflichten bestehen bei Vorfällen, und erfüllt er die 800-171-Anforderungen für die CUI, die er im Auftrag des Auftragnehmers verarbeitet?

Die SSP-Lücke: Was den meisten Organisationen fehlt

Ein NIST 800-171-konformer SSP muss die Systemgrenze, alle darin enthaltenen Komponenten und die Schutzmaßnahmen für CUI über alle Komponenten hinweg beschreiben. Bei den meisten Organisationen mit KI-Agents spiegelt der SSP eine Architektur vor der KI-Einführung wider – und KI-Agenten-Komponenten fehlen vollständig in der Systemgrenzenbeschreibung.

KI-Agents außerhalb der definierten Systemgrenze

Ist die KI-Agenten-Infrastruktur nicht in der Systemgrenzenbeschreibung enthalten, gelten die 800-171-Praktiken für diese Komponenten im dokumentierten Compliance-Status nicht. Ein Auditor, der den SSP mit den tatsächlichen Abläufen vergleicht, wird KI-Agents mit CUI-Zugriff als nicht abgedeckte Komponenten identifizieren – das heißt, der Self-Assessment-Score berücksichtigt diese Komponenten nicht und die DFARS-Zertifizierung der Organisation ist unzutreffend. Jedes System, das CUI verarbeitet, muss in die Grenze aufgenommen werden; jedes KI-System, das CUI verarbeitet, ist ein solches System.

Risikobewertungen, die KI-Einsätze nicht berücksichtigen

Praktik 3.11.1 verlangt regelmäßige Risikobewertungen der Unternehmensabläufe und des CUI-Systems. Die meisten aktuellen Bewertungen von Organisationen stammen aus der Zeit vor den KI-Einsätzen. Eine Bewertung, die KI-Agents mit CUI-Zugriff – deren Schwachstellen, Anbieterabhängigkeiten, Zugriffsumfang und Steuerungsmaßnahmen – nicht abbildet, ist keine aktuelle Risikobewertung im Sinne von 800-171.

Lücken im Plan of Action and Milestones

Sobald eine Organisation Compliance-Lücken im Zusammenhang mit KI-Einsätzen identifiziert, müssen diese Lücken im POA&M mit Zeitplan für die Behebung dokumentiert werden. Die Lücke zu erkennen, aber nicht zu dokumentieren, ist selbst ein Compliance-Verstoß: 800-171 verlangt die systematische Nachverfolgung von Sicherheitsmängeln, nicht nur deren Identifikation.

Best Practices für NIST 800-171-konformen KI-Agenten-Zugriff auf CUI

1. KI-Agenten-Komponenten im System Security Plan abbilden

Aktualisieren Sie den SSP, sodass alle KI-Agents und deren Infrastrukturkomponenten in der Systemgrenzenbeschreibung enthalten sind. Für jede KI-Komponente – Orchestrierungsschicht, Modell-Hosting, Vektor-Datenbank, API-Gateway – dokumentieren Sie die vorhandenen Schutzmaßnahmen, die verarbeiteten CUI-Daten und den Umsetzungsstatus der Praktiken. Das ist nicht optional: Ein SSP, der aktuelle KI-Einsätze nicht abbildet, ist unzutreffend, und ein unzutreffender SSP ist ein 800-171-Befund. Das SSP-Update sollte jeder weiteren Ausweitung von KI-Einsätzen mit CUI vorausgehen.

2. Authentifizierte Agenten-Identität mit Delegationskette implementieren

Jeder KI-Agent mit CUI-Zugriff muss auf Workflow-Ebene mit einer eindeutigen Identitätsberechtigung arbeiten, die dem verantwortlichen menschlichen Anwender zugeordnet ist (gemäß Praktik 3.3.2). Diese Berechtigung muss pro Agent und pro Workflow eindeutig sein – gemeinsame Servicekonten erfüllen weder Praktik 3.5.1 noch 3.3.2. Die Delegationskette (menschlicher Anwender zu Agenten-Identität zu CUI-Zugriffsereignis) muss in jedem Audit-Log-Eintrag erfasst werden, um die Verantwortlichkeitszuordnung zu gewährleisten, die 800-171 fordert.

3. Zugriff auf CUI auf Operationsebene durch ABAC einschränken

Implementieren Sie ABAC, das jede KI-Agenten-CUI-Anfrage anhand des authentifizierten Agentenprofils, der CUI-Klassifizierung der angeforderten Daten, des Workflow-Kontexts und der spezifischen Operation bewertet. Damit erfüllen Sie Praktiken 3.1.1 (autorisierter Zugriff) und 3.1.2 (Minimalprinzip) auf Operationsebene. Ein Agent, der zum Lesen eines Vertragsordners berechtigt ist, kann nicht alle Dateien herunterladen, nicht auf benachbarte CUI-Repositorys zugreifen und keine Operationen außerhalb seines autorisierten Umfangs ausführen – mit Durchsetzung auf Datenebene, nicht auf Modellebene.

4. Audit-Logs auf Operationsebene mit Verantwortlichkeitszuordnung erzeugen

Jede KI-Agenten-CUI-Interaktion muss in einem manipulationssicheren Log erfasst werden, das Praktiken 3.3.1 und 3.3.2 erfüllt: Agenten-Identität, verantwortlicher menschlicher Anwender, spezifische CUI, ausgeführte Operation und Zeitstempel. Diese Logs müssen die Überwachung und Untersuchung unautorisierter Zugriffe ermöglichen und für den vom Records Management vorgegebenen Zeitraum aufbewahrt werden. Standard-Infrastruktur- und Inferenz-Logs erfüllen die Audit-Anforderungen von 800-171 nicht ohne operationale, vollständige Attributionsdetails.

5. KI-Anbieter-CUI-Umgang im Supply Chain Risk Management bewerten und dokumentieren

Für jeden KI-Anbieter, dessen Infrastruktur CUI im Auftrag der Organisation verarbeitet, führen Sie eine DFARS-spezifische Vendor Risk Management-Bewertung durch: Prüfen Sie, ob der Anbieter die 800-171-Anforderungen für den Umgang mit CUI erfüllt, dokumentieren Sie die Bewertung und geben Sie die 800-171-Compliance-Anforderungen vertraglich weiter. Aktualisieren Sie den Supply Chain Risk Management-Plan gemäß Praktik 3.16.1, um KI-Anbieterbeziehungen abzubilden. Aktualisieren Sie das POA&M mit allen identifizierten Lücken. Ein KI-Anbieter, der CUI ohne dokumentierte 800-171-Compliance verarbeitet, ist ein DFARS-Flow-Down-Mangel, der die Compliance-Position des Hauptauftragnehmers beeinträchtigt.

Wie Kiteworks NIST 800-171-konforme KI-Agenten-Governance ermöglicht

Um den Zugriff von KI-Agents auf CUI NIST 800-171-konform zu gestalten, müssen drei Dinge gleichzeitig aktualisiert werden: der SSP zur Aufnahme der KI-Komponenten in die Systemgrenze, die technischen Kontrollen zur Steuerung des KI-Agenten-Zugriffs auf CUI auf Datenebene und die Anbieterbewertung, um sicherzustellen, dass die KI-Governance-Plattform selbst die 800-171-Anforderungen für den Umgang mit CUI erfüllt. Das Private Data Network von Kiteworks adressiert alle drei Aspekte: Es bietet die technische Governance-Infrastruktur für KI-Agenten-Zugriffe auf CUI, dient als im SSP dokumentierbare Systemkomponente mit NIST 800-171-Compliance-Fähigkeiten und unterstützt die Anbieterbewertung, die DFARS-Flow-Down verlangt.

Authentifizierte Identität und Delegationskette für Praktiken 3.5.1 und 3.3.2

Kiteworks authentifiziert jeden KI-Agenten vor dem Zugriff auf CUI mit einer eindeutigen Workflow-Berechtigung, die dem verantwortlichen menschlichen Anwender zugeordnet ist. Die vollständige Delegationskette wird in jedem Audit-Log-Eintrag erfasst. Damit werden die Anforderungen der Praktik 3.5.1 (eindeutige Identifikation) und Praktik 3.3.2 (Verantwortlichkeitszuordnung) erfüllt – und die Dokumentation bereitgestellt, die sowohl SSP-Implementierungsnachweise als auch DFARS-Compliance-Audits verlangen.

ABAC auf Operationsebene für Praktiken 3.1.1, 3.1.2 und 3.1.3

Die Datenrichtlinien-Engine von Kiteworks bewertet jede KI-Agenten-CUI-Anfrage anhand einer mehrdimensionalen Richtlinie: authentifiziertes Agentenprofil, CUI-Klassifizierung, Workflow-Kontext und spezifische Operation. Der Zugriff nach dem Minimalprinzip wird auf Operationsebene durchgesetzt, und der CUI-Fluss wird ausschließlich zu autorisierten Zielen gesteuert. Diese Durchsetzungsmechanismen erfüllen die Praktiken 3.1.1, 3.1.2 und 3.1.3 auf Datenebene, unabhängig vom Modellverhalten – und sind auditierbare Implementierungen, die im SSP dokumentiert werden können.

Manipulationssicherer Audit-Trail für Praktiken 3.3.1 und 3.3.2

Jede KI-Agenten-CUI-Interaktion wird in einem manipulationssicheren, operationsebene Audit-Log erfasst, das direkt in das SIEM der Organisation eingespeist wird. Das Log enthält Agenten-Identität, menschlichen Anwender, aufgerufene CUI-Daten, Operationstyp, Ergebnis der Richtlinienbewertung und Zeitstempel – und erfüllt so die Praktiken 3.3.1 und 3.3.2 mit dem operationellen Detailgrad und der Verantwortlichkeitszuordnung, die 800-171 fordert. Bei einer DFARS-Compliance-Prüfung kann als Nachweis ein exportierbares Evidenzpaket bereitgestellt werden – keine aufwändige Suche in verteilten Infrastruktur-Logs.

FIPS 140-3-Verschlüsselung und gesteuerte CUI-Dateioperationen

Alle über Kiteworks aufgerufenen CUI-Daten werden durch FIPS 140-3 Level 1-validierte Verschlüsselung während der Übertragung und im ruhenden Zustand geschützt und erfüllen so die Verschlüsselungsanforderungen von NIST 800-171. Die Funktionen Governed Folder Operations und Governed File Management von Kiteworks Compliant AI ermöglichen es KI-Agents, CUI-Repositorys zu organisieren und zu verwalten – jede Operation wird durch die Datenrichtlinien-Engine durchgesetzt. Damit werden RBAC- und CUI-Trennungsanforderungen ohne manuelle Provisionierung erfüllt und SSP-dokumentierbare Implementierungen für die Konfigurationsmanagement-Praktiken der Familie 3.4 bereitgestellt.

Für Organisationen, die CUI im Rahmen von DFARS-Verträgen verarbeiten und KI-Agenten-Einsätze NIST 800-171-konform gestalten müssen, bietet Kiteworks die technische Governance-Infrastruktur und die im SSP dokumentierbaren Implementierungen, die die Lücke zwischen der Compliance-Position vor KI und der operativen Realität agentenbasierter CUI-Zugriffe schließen. Erfahren Sie mehr über die NIST 800-171-Compliance-Fähigkeiten von Kiteworks oder fordern Sie eine Demo an.

Weitere Ressourcen

• Blog Post
  Zero‑Trust-Strategien für erschwinglichen KI-Datenschutz
• Blog Post
  Wie 77 % der Organisationen bei KI-Datensicherheit scheitern
• eBook
  KI-Governance-Lücke: Warum 91 % kleiner Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blog Post
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blog Post
  Regulierungsbehörden fragen nicht mehr nach einer KI-Policy. Sie wollen Beweise, dass sie funktioniert.