Does Azure OpenAI in GCC High satisfy CUI handling automatically?

Azure OpenAI in GCC High carries FedRAMP High authorization for the platform. The authorization covers the cloud infrastructure. It does not by itself satisfy NIST SP 800-171 controls that require auditability at the request layer. Agencies and contractors using the GCC High environment still need to produce per-decision audit records that identify the user, the data classification, and the policy state. The HTTP enforcement layer fills the gap between platform-level authorization and per-decision evidence.

What about ChatGPT Enterprise or Claude Enterprise for federal use?

The Enterprise tiers of consumer AI services typically do not carry FedRAMP authorization unless the vendor has gone through the JAB or agency authorization process. Use of these tiers for CUI handling sits outside the FedRAMP boundary. The architectural fix is to block this traffic at the egress layer and route sanctioned usage through FedRAMP-authorized providers under the agency's contractual authorization.

How does M-24-10 interact with the EU AI Act for federal contractors with EU exposure?

US federal contractors operating in the EU or serving EU end users may fall within scope of the EU AI Act in addition to M-24-10. The EU AI Act Article 12 logging requirements overlap heavily with M-24-10 transparency and risk management practices. The same HTTP enforcement layer produces evidence that satisfies both regimes.

What about agentic AI workflows in agency operations?

Agentic workflows are emerging in agency operations for case processing, document analysis, and decision support. An agent acts on behalf of a user, may call multiple LLM endpoints, and may chain reasoning across CUI-bearing prompts. The audit record must trace the originating PIV identity and program context through the chain. The HTTP enforcement layer produces the connected record the agency's audit and accountability function requires.

Does this apply to state and local government?

State and local governments handle their own controlled information categories (sealed records, juvenile records, criminal justice information under CJIS). The architectural pattern is the same: HTTP enforcement at the AI request layer with identity-bound audit records. CJIS Security Policy v6.0 includes AI-relevant controls that map onto the same HTTP enforcement architecture.

Shadow AI for Government: FedRAMP, CUI, and the OMB M-24-10 Mandate

The Office of Management and Budget issued Memo M-24-10 in March 2024 directing federal agencies to manage AI risk through governance, innovation, and risk management practices. The memo requires agencies to inventory their AI use cases, designate Chief AI Officers, and apply specific risk-management practices to safety-impacting and rights-impacting AI. The memo presumes the agency knows where AI is in use. Shadow AI breaks that presumption.

Pasting controlled unclassified information into a non-FedRAMP-authorized AI model violates the FedRAMP authorization boundary by definition. NIST SP 800-171 controls on CUI handling do not stop at the network edge. The audit trail that an agency or contractor must produce on request lives at the AI request layer, not the document storage layer.

I want to walk through where shadow AI surfaces in agency work, what M-24-10 actually requires, and what the architecture for compliant AI use looks like.

Shadow AI

Shadow AI in federal agencies and contractor environments covers analysts, program managers, contracting officers, and contractor employees using AI outside the agency's sanctioned program. The usage patterns mirror the private sector:

Analysts using ChatGPT to summarize reports
Program managers drafting acquisition documents with model assistance
Contracting officers translating technical specifications
Contractor employees cleaning up project status updates
Inspectors general staff summarizing audit findings

Each pattern moves agency information that may include CUI into a model the agency has no authorization for and no audit trail with.

What M-24-10 actually requires

The memo organizes agency obligations around three pillars:

AI inventory and governance: Agencies must publish AI use case inventories, designate Chief AI Officers, and establish AI Governance Boards. The inventory presumes visibility into agency AI usage that shadow AI undermines.

Risk management for safety-impacting and rights-impacting AI: The memo defines high-risk AI categories with specific risk-management practices including pre-deployment testing, ongoing monitoring, and impact assessments. Shadow AI usage in these categories creates exposures that the agency's risk management cannot address.

Innovation and workforce: The memo directs agencies to remove unnecessary barriers to responsible AI adoption while building workforce AI literacy. The balance between adoption and risk management presumes architectural visibility into AI usage.

Where FedRAMP attaches

FedRAMP authorizes cloud service providers to handle federal data at specified impact levels (Low, Moderate, High). Most consumer AI tools (the ChatGPT consumer service, Claude consumer, Gemini consumer) are not FedRAMP authorized. Microsoft Azure OpenAI in the GCC High environment, AWS Bedrock in GovCloud, and Google Cloud AI in the public sector regions carry FedRAMP authorizations. Shadow AI usage that bypasses these authorized environments moves CUI outside the authorization boundary.

NIST SP 800-171 controls on CUI

Contractors handling CUI must implement the 110 controls in NIST SP 800-171. The control families cover access control, audit and accountability, configuration management, identification and authentication, system and communications protection, and others. Shadow AI usage breaks several control families simultaneously: 3.1.1 (limit access to authorized users), 3.3.1 (create and retain audit logs), 3.13.1 (monitor and protect communications boundaries).

DLP and audit blind spot

Agency security stacks invest in CDM (Continuous Diagnostics and Mitigation), Einstein for network monitoring, and DLP at the email and storage layers. The stacks handle traditional data movement patterns. AI prompts break the pattern.

Identity correlation

The egress packet from an analyst's workstation identifies the source IP and destination. The packet does not carry the analyst's PIV identity, the program code they support, the CUI category that should attach to the work, or the policy that should have applied. Without identity correlation, the egress event is a network alert without compliance context.

CUI marking at the prompt layer

CUI marking happens at the document level via NARA-prescribed banners and footers. AI prompts strip those markers when text is pasted into a chat interface. The CUI character of the content persists, but the marking does not travel with it. Prompt-level classification has to detect the CUI character independent of the marking.

Authorization boundary enforcement

FedRAMP authorization boundaries are enforced through network architecture and procurement. They are not enforced at the prompt layer. An analyst with access to a CUI-marked document can paste its content into a consumer AI tool. The network sees the egress traffic. The DLP sees the destination URL. Neither sees the CUI classification that should have blocked the request.

Governing shadow AI in government

A workable governance posture for shadow AI in federal and contractor environments has four layers.

AI traffic identification

The agency or contractor's egress proxy must recognize AI traffic as a distinct class. The destination list includes the major model providers in both their commercial and government cloud variants, plus vendor SaaS endpoints that embed AI under their own authorization boundaries.

PIV-bound identity mapping

Every AI request must carry the natural-person PIV identity of the user. The PIV identity links to the user's authorization scope, the programs they support, and the CUI categories they may handle.

Prompt-level classification for CUI markers and patterns

Inside the prompt, the enforcement layer needs to detect CUI markers and the content patterns that indicate CUI even when markers were stripped. Program codes, classified word lists per CUI category, source documents the system can fingerprint.

Inline policy enforcement with authorization boundary check

Detected CUI triggers a policy decision that checks whether the destination model is inside the user's authorized boundary. Routing to the FedRAMP-authorized environment when permitted, denying with audit when not.

DeepInspect

This is the layer DeepInspect operates at. The HTTP proxy sits inline between agency or contractor applications and the LLM APIs they call. For every request, the proxy reads the PIV-bound identity from the application's header, classifies the prompt content for CUI markers and patterns, evaluates per-program and per-authorization-boundary policy, and writes a tamper-evident audit record before the model receives the request.

The compliance fit is structural. The audit record identifies the user's PIV credential, the program scope, the CUI categories detected, the authorization boundary check result, and the policy outcome. The record satisfies NIST SP 800-171 control 3.3.1 audit logging, FedRAMP boundary enforcement evidence, and M-24-10 AI use inventory requirements simultaneously.

If your agency or contractor environment is moving from policy-only AI governance to architectural enforcement, Book a demo today.