The ATO Bottleneck: What Federal Agencies Discover When AI Procurement Meets the Authorization Process
Federal agencies are deploying AI tools across procurement, benefits processing, compliance monitoring, and workforce operations — but the Authorization to Operate process was written for static systems. FedRAMP authorizes cloud infrastructure, not AI model behavior. Most commercial frontier AI tools lack a FedRAMP authorization entirely. And the ATO a federal agency obtains for a specific AI system configuration becomes obsolete the moment the underlying model updates.
Key Numbers
Background
The Authority to Operate is the foundational security authorization that governs whether a federal agency can legally operate an IT system on government infrastructure or use a cloud service to process federal data. The process — governed by NIST SP 800-37, the Risk Management Framework — requires a system security plan, security control assessment, risk determination, and formal authorization from an Authorizing Official. For a standard government IT system, the ATO process takes 12 to 18 months from initial categorization to authorization. It was designed for infrastructure that, once deployed, remains relatively static: a records management system, a case management platform, a financial reporting tool. It was not designed for systems whose core behavior changes materially every 60 to 90 days without a formal change request.
FedRAMP — the Federal Risk and Authorization Management Program — extends this framework to commercial cloud services, allowing agencies to rely on a single cloud provider authorization rather than conducting individual agency-level assessments for each vendor. As of 2025, more than 300 cloud services hold a FedRAMP authorization. Microsoft Azure Government, AWS GovCloud, and Google Cloud Government hold High-impact authorizations. These authorizations cover infrastructure: compute, storage, networking, identity management. Microsoft's Copilot for Microsoft 365 Government holds a FedRAMP High authorization, making it one of the few AI productivity tools that agencies can deploy without initiating an independent ATO process. OpenAI's ChatGPT Enterprise, Anthropic's Claude, and Google's Gemini for Workspace — as offered through standard commercial channels — do not hold FedRAMP authorizations. A federal employee using a personal ChatGPT account to process work-related data is creating a data spillage event under most agency security policies.
Executive Order 14110, issued in October 2023, required federal agencies to designate a Chief AI Officer, establish AI governance boards, and submit inventories of AI use cases to the Office of Management and Budget within 60 to 365 days. OMB's implementing memoranda (M-24-10 and M-24-18) established minimum AI risk management practices, required agencies to conduct rights- and safety-impacting AI assessments, and mandated annual reporting. The NIST AI Risk Management Framework, which agencies are directed to implement, provides a vocabulary for categorizing AI risk but does not resolve the ATO question: whether the AI tool meets the authorization requirements that govern federal IT systems specifically.
The agencies that have moved fastest on AI deployment have done so through one of three paths. First, using Microsoft 365 Copilot for Government, which inherits the M365 Government FedRAMP authorization and requires no separate ATO — deployed across the Department of Defense, the Department of Homeland Security, and multiple civilian agencies. Second, deploying AI capabilities on FedRAMP-authorized IaaS platforms (Azure Government, AWS GovCloud) and treating the AI as an internally operated system subject to agency-level ATO rather than FedRAMP. Third, accepting risk and operating commercial AI tools under provisional approvals, memoranda of understanding, or informal guidance while the formal authorization process proceeds — a posture that produces a documented residual risk but keeps operations moving.
The gap between authorization posture and operational reality is structural. The Department of Defense's Chief Digital and AI Office (CDAO) has deployed AI tools across intelligence analysis, maintenance prediction, logistics optimization, and decision support at a pace that authorization timelines cannot match. The VA has piloted ambient AI scribes for clinical documentation — the same tools in production at civilian health systems under Issue #10 of this memo — with authorization status varying by facility and tool. GSA's AI Center of Excellence has catalogued agency AI use cases and provided procurement vehicles, but the actual authorization decisions for each use case remain with individual agency AOs. The IRS deployed AI for tax compliance pattern detection, fraud identification, and correspondence processing. CBP is using computer vision AI at ports of entry. Each of these represents a real deployment — and each represents an ATO challenge that has been resolved in ways that do not uniformly meet the formal requirements of SP 800-37 as written for static systems.
The model version change management problem is acute and almost entirely unaddressed in current federal AI governance documentation. When an agency obtains an ATO for a specific AI system configuration — a defined model version, a defined prompt structure, a defined set of capabilities — and the underlying model updates, the security posture of that system has materially changed. Under SP 800-37, a significant change to an authorized system triggers a change management review that may require reauthorization. Commercial AI providers do not issue formal change notifications that map to federal change management requirements. OpenAI, Anthropic, and Google update their production models continuously — sometimes with announced deprecations of specific versions, sometimes with silent behavior updates across the same API endpoint. An ATO that authorizes “GPT-4” is not an ATO for “GPT-4o” — but the API transition may not trigger a formal change management event inside the agency unless a process specifically designed to catch it exists.
Decision Required
How do you deploy AI capabilities at the pace the mission requires when the authorization process was designed for a world where systems do not change every 90 days?
Federal CIOs and Authorizing Officials face a genuine structural mismatch. The ATO process, as codified, requires a point-in-time security assessment of a defined system configuration. AI tools, as built and operated by commercial providers, are continuously updated services — not static configurations. Applying the existing ATO process to a continuously updated AI service requires either accepting that the authorization is perpetually stale, designing a continuous authorization program that does not currently exist in most agencies, or restricting AI deployment to a small set of tools for which the provider can commit to a stable, versioned, FedRAMP-authorized offering.
The rights-impacting AI question adds a compliance obligation that sits alongside the ATO question without resolving it. OMB M-24-10 requires agencies to conduct a minimum practice assessment for AI that affects rights or safety — including benefits eligibility, law enforcement, and employment decisions. A benefits processing AI tool at the VA or SSA that recommends eligibility determinations must meet these minimum practices regardless of its ATO status. An AI tool can have a valid ATO and still fail the rights-impacting assessment, or pass the rights-impacting assessment without having a completed ATO. The governance obligations do not consolidate.
Options
Limit AI deployment to the small set of commercial AI products that already hold FedRAMP authorizations, inheriting those authorizations rather than initiating independent ATOs. As of 2025, this primarily means Microsoft Copilot for M365 Government (FedRAMP High), Azure OpenAI Service Government (FedRAMP High on Azure Government infrastructure), and AWS Bedrock (available in GovCloud with FedRAMP authorization). This posture eliminates the authorization gap for covered use cases and is the most defensible approach under current OMB and DOD guidance. Its limitation is model access: FedRAMP-authorized AI offerings provide access to a subset of available frontier models — specifically, models that Microsoft and Amazon have integrated into their government cloud platforms — and typically lag commercial model releases by six to twelve months.
Implement a Continuous Authorization to Operate (cATO) program — a posture that several DOD components have moved toward under CISA and DISA guidance — in which security controls are monitored continuously and the authorization is maintained through ongoing evidence rather than periodic reauthorization. Under a cATO, model version changes are assessed through a defined change impact analysis process rather than treated as full reauthorization triggers. This is the most operationally sustainable posture for agencies deploying AI at scale, but it requires a security operations capability that most civilian agencies have not built. DISA's DevSecOps program provides a reference architecture, but operationalizing it requires security tooling, automation, and staffing investment that exceeds current capacity at most non-DOD agencies.
Deploy AI tools under a formal risk acceptance posture: the Authorizing Official documents the residual risk of operating ahead of full authorization, establishes monitoring requirements and trigger conditions for review, and signs a provisional authority to operate while the formal ATO process proceeds. This is the most common actual practice at agencies that have deployed AI capabilities quickly. It is legally defensible when the risk acceptance is documented and the AO is genuinely aware of and accountable for the residual risk — not when a provisional authorization is used to avoid the authorization process indefinitely. The risk is that a security incident involving an AI tool operating under provisional authorization creates a documented record of known governance gap that was not fully remediated.
Require that AI tools in sensitive or rights-impacting use cases be deployed on agency-controlled infrastructure, using open-weight models (Meta Llama, Mistral, Falcon) or fine-tuned models built and operated internally. This posture eliminates third-party API authorization complexity and gives the agency full control over model versioning, change management, and security architecture. It is operationally realistic for DOD and IC components with dedicated AI engineering organizations. It is not realistic for most civilian agencies, which do not have the ML engineering capacity to train, deploy, operate, and maintain production-grade LLMs — and which face a talent market where the engineers capable of doing this are not entering government service at the required scale.
Recommendation
The actionable path is a use-case tiering framework that maps AI deployment risk to authorization requirements — rather than applying the same ATO process uniformly to all AI tools. Most agency AI deployments are not rights-impacting, safety-critical, or processing classified information. An AI tool that drafts internal correspondence, summarizes meeting notes, or generates first drafts of reports carries a fundamentally different risk profile than an AI tool that recommends benefits eligibility determinations, generates law enforcement leads, or produces medical guidance. Applying the full SP 800-37 ATO process to the former while treating it as equivalent to the latter creates a compliance burden that agencies respond to by either avoiding AI deployment entirely or using unsanctioned commercial tools outside government systems — neither of which is the intended outcome.
Define three tiers. Tier 1: AI tools used for internal productivity in non-sensitive contexts — drafting, summarization, code assistance, meeting transcription. Authorize through FedRAMP-covered offerings where available (Copilot for Government, Azure OpenAI Service Government); where not available, operate under documented risk acceptance with defined sensitivity guardrails. Tier 2: AI tools used in mission support functions that do not directly affect rights or safety — logistics optimization, procurement analysis, compliance monitoring assistance. Require a formal ATO, but scope the assessment to the AI-specific risk surface rather than a full infrastructure assessment for tools hosted on already-authorized IaaS. Tier 3: AI tools used in rights- or safety-impacting contexts — benefits eligibility, law enforcement, clinical guidance, weapons systems. Require a full ATO, a rights-impact assessment under OMB M-24-10, and either a FedRAMP-authorized product or internally hosted infrastructure with full change management controls.
Address the shadow AI problem before addressing the formal authorization process. Every federal agency has employees using personal accounts to access commercial AI tools — ChatGPT, Claude, Gemini — for government work. This is a data spillage risk that exists regardless of what the formal authorization process produces. The technical control is data loss prevention (DLP) monitoring on government devices and networks. The policy control is explicit guidance on which AI tools are approved for which data classification levels, communicated to every employee who uses a computer. Most agencies have the technical capability to block unauthorized AI tool access; fewer have the policy clarity to tell employees what the approved alternatives are. The shadow AI conversation needs to happen before the ATO conversation — because the risks are occurring now, not after the authorization process completes.
Engage with OMB's AI use case inventory process as a governance foundation, not a compliance checkbox. The annual AI use case inventory requirement under EO 14110 forces agencies to enumerate what they are deploying — which is a precondition for applying the tiering framework above. Agencies that have completed thorough inventories have a prioritized list of use cases that require authorization work. Agencies that treated the inventory as a documentation exercise without operational consequence have no visibility into what their authorizing officials are actually responsible for. The inventory is the starting point. The authorization decisions follow from it.
Brief your Authorizing Official on the model version change management problem explicitly. Most AOs who signed off on AI system ATOs in 2023 and 2024 did not receive a briefing on what model version changes mean for their authorization. When GPT-4 became GPT-4o, when Claude 2 became Claude 3, when an Azure OpenAI endpoint updated silently — those were material changes to authorized system configurations. The AO needs to understand that they have authorized a specific system state that may no longer accurately describe the deployed system. The options are: establish a model version change monitoring and assessment process, move to a cATO posture, or restrict to versioned API offerings that the provider commits not to update without formal notification.
Enjoying this brief? The next one ships Tuesday.
One enterprise AI deployment, dissected weekly. Free during beta · No credit card · Unsubscribe anytime
Risks
Federal employees are using personal accounts to access commercial AI tools for government work. This is not a hypothetical future risk — it is occurring across every agency that has not deployed sanctioned AI alternatives fast enough to meet operational demand. When an employee pastes a contract draft, a personnel decision memo, or an intelligence summary into ChatGPT via their personal account, that data has left government systems without the processing agreements, residency controls, or classification controls that federal data handling requirements mandate. The spillage event does not wait for the ATO process to complete. The gap between what agencies have authorized and what employees are actually using is where the most significant near-term AI security risk lives.
A FedRAMP authorization certifies that a cloud service meets NIST SP 800-53 security control requirements for infrastructure — access control, audit logging, incident response, configuration management. It does not certify that the AI capabilities built on top of that infrastructure are free from hallucination, prompt injection, or output manipulation. An agency that deploys Microsoft Copilot for M365 Government under its FedRAMP High authorization is authorized to use the cloud infrastructure; it is not authorized in any meaningful sense against the AI-specific risk that the model will generate a confidently wrong answer in a procurement memo or a staff correspondence. The authorization gap for AI-specific failure modes exists across all FedRAMP-authorized AI offerings. No current FedRAMP authorization scope covers AI reliability, bias, or output accuracy.
When a commercial AI provider updates the model version behind an authorized system — even within an authorized platform like Azure OpenAI Service Government — the authorized system configuration has changed materially. Under NIST SP 800-37 change management requirements, a significant change triggers a security impact assessment. Commercial AI providers do not issue notifications formatted for federal change management processes; their release notes are written for developers, not for Authorizing Officials. Most agency IT teams are not monitoring provider release notes, mapping model version changes to their authorization scope, or triggering formal change assessments when model behavior changes. The gap accumulates silently: every model update that the agency does not assess is a change management deviation in the ATO record.
OMB M-24-10 required agencies to complete minimum practice assessments for rights- and safety-impacting AI use cases by June 2024. OMB M-24-18 set annual reporting requirements and indicated that compliance would be tracked. Multiple agencies submitted AI use case inventories that included benefits processing, law enforcement, and employment-impacting AI tools without completed minimum practice documentation. As OMB and agency Inspectors General increase scrutiny of AI governance — a trajectory that has accelerated since the AI Executive Order — agencies with rights-impacting AI deployments operating without documented minimum practice assessments are carrying an enforcement risk that did not exist before 2024. The IGs that conduct reviews of agency AI programs in 2025 and 2026 are doing so with a documented compliance standard to check against.
The federal procurement timeline for a new IT system runs 12 to 24 months from requirement definition through contract award through ATO. Commercial AI capabilities are evolving on a 6-month major release cycle. The practical consequence: by the time an agency completes procurement and authorization for a specific AI capability, the commercial market has moved to a materially different generation of tools. The ATO the agency obtained describes a system that is no longer state-of-the-art. Agencies that pursue individual ATOs for specific AI tools will find themselves perpetually chasing a market that moves faster than their procurement processes allow. This argues for investment in reusable authorization infrastructure — FedRAMP-authorized AI platforms that agencies can configure without new ATOs — rather than individual tool-by-tool authorization.
Questions Your Team Should Be Answering
These are the questions that distinguish organizations that get this right from those that do not. If your team cannot answer them, that is your first deliverable.
- 1.
Has your agency completed its AI use case inventory under EO 14110 and OMB M-24-10? For each use case: what is the authorization status, what data classification does it process, and has it been assessed against the rights- and safety-impacting AI minimum practices?
- 2.
Which AI tools are currently in operational use at your agency that are not covered by a completed ATO or an inherited FedRAMP authorization? Who is the designated Authorizing Official for each, and what is the documented risk acceptance status?
- 3.
Does your agency have a process for detecting model version changes in commercially operated AI tools — and triggering a change management assessment when the underlying model updates? Who receives provider release notifications, and who conducts the impact assessment?
- 4.
What is your agency's technical and policy response to shadow AI? Are DLP controls deployed to detect non-approved AI tool usage on government devices? Has guidance been issued to employees specifying which AI tools are approved for which data sensitivity levels?
- 5.
For AI tools used in rights- or safety-impacting use cases: has a formal minimum practice assessment been completed and documented per OMB M-24-10? If not, which tools are unassessed, what is the rights-impact scope, and what is the remediation timeline?
- 6.
Has your Authorizing Official been briefed specifically on the model version change management gap — that commercial AI model updates may not trigger the change management assessment process that SP 800-37 requires for significant system changes?
If this memo belongs in your next executive meeting or board pack, send it along. One click opens a pre-drafted email — edit or send as-is.
The Algorithmic Underwriting Audit: What NAIC AI Requirements Mean for Every Insurer Using AI in Pricing and Claims
State insurance regulators have moved. The NAIC Model Bulletin on AI has been adopted in 38+ states. Colorado mandates external algorithmic audits for life insurance AI. California CDI has challenged AI-generated property risk scores. Most carriers have deployed AI in claims and underwriting without building the governance documentation regulators are now requiring.
Read memo →The SR 11-7 Blind Spot: What Banks Discover When AI Hits Model Risk Management
Banks are deploying AI in credit underwriting, fraud detection, compliance monitoring, and customer service — but SR 11-7, the OCC/Fed model risk framework, was written in 2011 for statistical models. The validation gap for third-party LLM APIs, the model version change management problem, and what bank examiners are beginning to ask.
Read memo →The Shop Floor AI Bet: What Siemens' Industrial Copilot at BMW Means for Every Manufacturing CIO
Siemens Industrial Copilot is live at BMW plants — reading PLC logs, generating maintenance recommendations in real time. The data portability clause your current contract doesn't include, the safety governance process your EHS team hasn't defined for AI-generated maintenance steps.
Read memo →