Tomas Reyes, an IT program manager at a federal agency, found the perfect AI writing assistant for his policy team. It was cheap, fast, and the staff loved the pilot. Then his agency's security officer asked one question: "Is it FedRAMP authorized?" It was not. The tool's whole business ran on a cloud the government had never assessed, and the agency had no way to know where staff inputs went, how they were stored, or who could see them. The pilot died that afternoon. Tomas had spent six weeks championing a tool that could never legally hold government data. Understanding cloud authorization before you fall in love with a tool is how you avoid building on sand.

This lesson explains how the Federal Risk and Authorization Management Program, FedRAMP, governs AI tools that run in the cloud, and what AI adds on top of the standard cloud-security picture. Almost every modern AI tool is a cloud service, so this applies far more often than people expect. It also explains, carefully, what an authorization actually certifies, because the most expensive mistakes in this area come from assuming it certifies more.

What FedRAMP is and why it exists

FedRAMP is the federal government's standardized way of deciding whether a cloud service is secure enough to handle government data. Instead of every agency separately assessing the same cloud product, FedRAMP creates one rigorous review whose result other agencies can reuse. Do the security work once, reuse it many times. Underneath it sits the agency's statutory obligation under the Federal Information Security Modernization Act to secure the systems it operates, whether the infrastructure is run by the government or by a cloud provider. You can outsource the operation of infrastructure. You cannot outsource the obligation.

The core rule for Tomas is simple: if a cloud service is going to store, process, or transmit federal data, it generally needs a FedRAMP authorization at the right level. An AI assistant that sends staff prompts to a vendor's cloud is doing exactly that. No authorization, no government data, no matter how good the tool is. FedRAMP is not bureaucracy for its own sake. It is the question "where does our data actually go, and who can see it" turned into a process you can trust.

What an authorization says, and what it does not

This is the section to read twice, because a great deal of confusion in government AI procurement collapses two different things into one. An authorization is a statement about the assessed security posture of a defined environment: the controls implemented inside a stated authorization boundary, tested by an independent assessor, accepted by an accrediting official at a stated impact level, and maintained through continuous monitoring. That is a real and valuable statement, and it is the whole of what the authorization is.

What an authorization is not is a restriction on how the vendor may use your data. Whether your prompts are retained, logged, reviewed by vendor staff, passed to a subprocessor, or used to train the vendor's model is governed by your contract and the vendor's terms of service, not by the authorization. An authorized service can lawfully do things with your inputs that you never intended, if your agreement permits them. These are two separate clauses in two separate documents, and an agency that treats the authorization as covering both will discover the gap only when someone asks where the policy drafts went.

Three further things an authorization does not certify. It does not certify that the model is accurate, that its outputs are fair, or that it is fit for the decision you plan to use it for; those are performance questions with performance evidence. It does not certify anything outside the authorization boundary, which matters enormously when the AI feature calls a model hosted somewhere else. And it does not certify your deployment: your configuration, your access controls, and the controls designated as customer responsibility are yours to implement and evidence. Ask for the customer responsibility matrix by name, because it is the list of things the authorization explicitly leaves to you.

How the process runs

Authorization proceeds through four phases, and knowing them helps you read a vendor's status claim accurately. In preparation, the cloud provider assembles its security documentation, including the System Security Plan describing the architecture, the data flows and how each control is implemented, plus the evidence behind each one. In assessment, an independent assessor reviews the documentation and tests the controls, typically over a period of months. In authorization, a government accrediting official reviews the assessment result and decides whether to authorize the service, which is a risk acceptance rather than a technical finding. In continuous monitoring, the provider keeps monitoring its controls and reporting to the agency, and the authorization stays alive only so long as that continues.

Each control in the catalogue has three parts, and knowing the shape helps when you are reading an assessment package rather than a marketing page. The control is the description of the required security practice. The implementation is how this provider actually satisfies it in this environment. The assessment is the evidence that the implementation exists and works. A vendor answering a control question with the text of the control has told you nothing; the implementation and the evidence are the answer.

Impact levels, and which you need

FedRAMP defines three authorization levels based on the sensitivity of the data being handled, and the data determines the level, not the system's function. A chatbot handling social security numbers is not low impact because chatbots feel low impact.

Working rules help more than the definitions. A system handling personally identifiable information such as names, social security numbers or financial details lands at Moderate or High. A system handling citizen medical or mental health information lands at Moderate or High depending on the sensitivity and volume, and is not automatically one or the other. A system handling benefits applications or eligibility determinations lands at Moderate. Unclassified operational data with no direct citizen impact ranges from Low to Moderate. Classified information is High and generally follows a different authorization path entirely.

The practical move is to classify your data first, then require the matching level. Tomas's policy drafts were internal controlled information, so Moderate was the floor. Picking the level after you have chosen a tool is backwards and expensive, because it turns a requirements decision into an argument about a tool someone already wants.

The control families that matter most for AI

FedRAMP is built on the NIST SP 800-53 control catalogue, organised into control families. The baselines scale with impact: the Low baseline is the smallest set, Moderate is substantially larger, and High is larger again. Every family applies at every level, but six carry particular weight when the system is an AI system, and these are the ones worth reading closely in an assessment package.

• Access Control. Account management, access enforcement and least privilege, covering who can reach data and systems. For AI the sharp edge is that data scientists should not have blanket access to all training data, only to what the work requires.
• Audit and Accountability. What events are logged, what the log records contain, and whether logs are actively reviewed rather than merely stored. For AI this should extend to every data access, model update and prediction request, so an audit trail exists for decisions the system influenced.
• Identification and Authentication. Proving who is acting, with multi-factor authentication for privileged users and managed credentials. For AI the overlooked case is machine identity: interface authentication and service-to-service authentication, plus a trail of who changed what.
• System and Communications Protection. Boundary protection, cryptographic protection and protection of information at rest. For AI, government data must be encrypted both in motion and at rest, and model weights are an asset that needs protecting like any other.
• Configuration Management. Formal change control and separation of duties, so the person requesting a change is not the person approving it. For AI this must expressly cover model updates and training data changes, which otherwise slip through as routine operations.
• Incident Response. Incident handling and incident reporting, including notification to customers within a defined window. For AI the contract should state that adversarial attack, poisoning and model compromise are reportable incidents, because a vendor left to its own judgment may not classify a degraded model as a security event.

What AI adds on top of cloud security

FedRAMP was built for cloud services generally. AI introduces risks the standard catalogue does not fully capture, and you must probe these yourself even when a tool is authorized:

• Where do prompts and outputs go? Staff inputs to an AI tool may contain sensitive content. Are they stored, logged, or, worst of all, used to train the vendor's model? "Do not train on our data" must be explicit and contractual.
• Model and data separation. Development needs access to training data; a production inference system does not. Enforce separation of duties so the production system reads only what inference requires, and practise data minimisation by copying only the data the model actually needs into the cloud rather than the whole record set.
• Adversarial security. Model poisoning corrupts training data to bend the model's behaviour, adversarial examples are crafted inputs that produce wrong outputs while looking ordinary, and model theft reconstructs a model by querying it repeatedly. The defences are monitoring training data integrity, explicit robustness testing, and rate-limiting programmatic access.
• Explainability and auditability. Log every decision with its input, output and confidence; keep a complete history of model versions, training data and performance; and design the ability to explain a decision in from the start, because it cannot be retrofitted onto a system that never recorded the inputs.
• Data residency and sovereignty. Some government data must remain in specific locations, and some cannot go to a commercial cloud at all. An authorization does not answer your residency question; ask where the data physically resides and confirm against your own requirements.
• The model supply chain. What underlying model powers the tool, and is that component inside the authorization boundary or quietly calling an outside service? Many AI products are wrappers that send your data to another company's model, and that downstream service needs to be authorized too, or your data just left the boundary.

The trap to watch: a vendor says "we're FedRAMP authorized" but the AI feature you want routes data to a model that is not inside that authorization. Ask precisely what the authorization covers, and ask for the boundary diagram rather than the claim.

Reading a vendor's status claim

Three statuses come up, and each carries a different decision. Authorized means the provider completed assessment and an independent assessor confirmed the controls are implemented. The benefit is that the assessment work is done and you can move faster with less assessment burden of your own. The catch is the level: an authorization at Low is not an authorization at Moderate, and a vendor who says only "we are FedRAMP authorized" has not answered the question you asked. Get the level, the boundary and the date.

In process means documentation has been submitted and assessment is underway. It signals the provider is serious about federal work, and it tells you nothing reliable about when. The remaining timeline is genuinely uncertain and can extend by many months. Budget accordingly, and remember that "in process" is not "authorized" for any purpose that involves your data. Not authorized means the provider has not pursued FedRAMP or has withdrawn. This is a significant blocker for most government use, and the useful move is to ask why. Your options narrow to pursuing an individual agency authorization, which is markedly more expensive and slower, or asking the vendor to move onto an authorized provider. For a provider that is not pursuing authorization at all, the sound default is not to use it.

Authorization is day one, not the finish

An authorization does not end; it has to be maintained. A third-party assessor reviews controls annually. The provider monitors controls continuously and reports on a monthly rhythm to the agencies relying on the authorization. Security incidents are reported promptly under a defined notification window. Where controls are not met, the provider produces a Plan of Action and Milestones setting out the remediation timeline, and a full re-assessment follows on a multi-year cycle.

On the notification window, be precise in your own contract. The commonly cited requirement in this material is notification to the government within 24 hours of a security incident, and you should treat that as a floor to negotiate down rather than a ceiling to relax to. The binding window for your system is set by your agency's incident reporting policy and by the authorization package, and for some categories of incident it is considerably shorter. Write the number your agency actually requires into the contract, along with who at the vendor must send it and to whom, because a notification obligation with no named recipient reliably arrives late.

The agency's own responsibilities are the half of this that gets forgotten. You maintain the system security plan describing how your specific system is deployed on that cloud. You ensure your use of the service does not violate its security requirements. You monitor the logs and alerts the provider sends. You implement the controls designated as your responsibility rather than the vendor's. And your information security officer monitors compliance and reports to agency leadership. The provider reports; the agency decides what to do about what it reports. That decision cannot be delegated, and a stack of unread monthly reports is the most common way an authorized system quietly stops being compliant.

Three deployment patterns and what each requires

If the vendor's system is software as a service on cloud infrastructure, the vendor operates it and you consume it through an interface. Check three things: whether the vendor's system runs on an authorized cloud provider, what impact level that provider is authorized for against your data's sensitivity, and whether the vendor holds a separate authorization or security plan for their own application layer on top of the cloud. That third check is the one agencies skip, and it is the difference between an authorized platform and an authorized product.

If you choose the cloud and deploy a vendor's model there, on a government-community offering such as AWS GovCloud or Azure Government or another authorized environment, the cloud layer is usually already authorized and your work is authorising your own system on top of it. Expect authorized services to cost more than their commercial equivalents, because the security overhead is real, and expect to own the secure deployment yourself against the applicable controls. If the cloud provider is not authorized, the paths are all poor: your agency pursues an individual authorization at significant expense and delay, the vendor moves to an authorized provider, or you deploy on government-operated infrastructure instead, which is slower and more expensive but sidesteps cloud authorization entirely.

Budgeting for the authorization you did not plan for

Authorization is a schedule and budget item, and the single most common project failure in this area is discovering that at the wrong end of the plan. The figures below come from this curriculum's planning guidance rather than from any published schedule, so treat them as order-of-magnitude planning assumptions to validate against real quotes and your own security office's experience, not as commitments anyone has made to you.

On timeline: with an already-authorized cloud provider, plan roughly three to six months to authorize your own system on it. If the provider is still in process, add something like six to twelve months of waiting. If the provider is not pursuing authorization, an individual agency authorization is a twelve to twenty-four month proposition, which is usually the point at which finding a different provider becomes the cheaper option. On cost: authorized cloud services carry a meaningful premium over non-authorized equivalents, third-party assessment is a substantial one-off cost that may fall on the vendor or the agency depending on the arrangement, continuous monitoring is a recurring annual cost per service, and agency staff time for security oversight is an ongoing budget line that is almost never requested.

Work the arithmetic before you commit. Take the exercise of choosing between an authorized provider and one estimated at eight months from completing authorization, for a project with a twelve-month timeline. Eight months of waiting plus three to six months to authorize your application gives eleven to fourteen months. The optimistic end fits inside twelve months with a month to spare; the pessimistic end misses by two. So the second provider is only viable if every estimate lands at its best case and nothing slips, which is not how authorization schedules behave. That calculation, done in week one on the real numbers, is worth more than any amount of vendor reassurance later.

The push to make AI authorization faster

Authorization has historically been slow, which collides with how fast AI moves. The General Services Administration, GSA, which runs much of the government's shared technology buying, has pushed initiatives to accelerate authorization for AI and emerging tools, including streamlined paths and reuse of existing authorizations. The practical takeaway for you: do not assume a promising AI tool is permanently out of reach because it is new. Check whether it is in the authorization pipeline, and whether a faster path applies. But "in process" is not "authorized." Until the authorization is real, the rule still holds, and a faster process still produces an authorization about security posture rather than about how your data may be used.

A go/no-go decision flow for any AI cloud tool

Run any candidate AI tool through these gates in order. The first "no" stops you until it is resolved.

1. Will this tool touch federal data? If no (truly public, non-sensitive only), authorization may not be required. If yes, continue.
2. What is the data's impact level? Classify it: Low, Moderate, or High. This sets the bar, and the data sets the classification, not the application.
3. Does the tool hold a FedRAMP authorization at that level or higher? If no, stop. It cannot hold your data yet.
4. Does the authorization cover the AI feature and any model it calls? Ask for the boundary. Confirm the model is inside it, not a downstream service. If unclear, stop and ask.
5. Is our data excluded from vendor model training, and are residency and isolation confirmed? Get it in writing, in the contract, and understand that the authorization does not deliver this.
6. Are output handling, retention, disposal and incident notification addressed? Confirm before go-live, including who notifies whom, and within what window.
7. Do we know which controls are ours, and who will run them? Read the customer responsibility matrix and name the owner of the agency-side controls and the monthly monitoring reports.

Replay Tomas's tool through the flow and it fails at gate three: no authorization at the Moderate level his data required. Running the flow in week one instead of week six would have saved the pilot, the staff's hopes, and his credibility. The lesson is not "say no to new AI." It is "ask the authorization question before the love affair, not after."

Anti-Patterns

• Checking authorization status last. Capability and pricing get evaluated first because they are the interesting part, and security assessment happens at the end. Then the project discovers mid-flight that the provider is not authorized and faces a year or more of delay or an expensive individual authorization. Authorization status is the first requirement, not the final check.
• Assuming an authorized cloud makes everything on it authorized. The vendor's application running on an authorized platform is not itself authorized by that fact, and still needs its own assessment. Check two things separately: the cloud provider's status, and the vendor application's status or security assessment plan.
• Reading the authorization as a data-use guarantee. An authorization describes an assessed security posture inside a boundary. It says nothing about retention, logging, human review, subprocessors or training on your inputs. Those live in the contract, and an agency that never wrote them there has no basis for assuming any of them.
• Deferring security to the end of the project. Security feels technical and complex, so it gets pushed behind functional requirements. The system is then ready to deploy and the authorization is not done, which converts a planning problem into months of idle delay. Security planning, including the authorization path, starts at project inception because it drives both timeline and budget.
• Treating continuous monitoring as the vendor's job. The provider sends logs and reports; if nobody at the agency has the capacity to read them, compliance drifts while the paperwork looks perfect. Budget named agency staff time for ongoing monitoring, and treat an unread report as an unmonitored control.
• Assuming traditional controls cover AI risk. Firewalls and encryption address the threats the catalogue was written for. A system can be fully authorized and still vulnerable to adversarial inputs, model theft and data poisoning, because those attacks target the model rather than the infrastructure. Add controls for model integrity, training data security, adversarial robustness and comprehensive decision logging.
• Accepting "we are FedRAMP authorized" as an answer. The claim without the level, the boundary and the date is marketing. Three follow-up questions resolve it: authorized at what impact level, covering which components, and is the continuous monitoring current.

Practice Prompts

• Determine the impact level for four systems: one classifying FOIA requests over unclassified documents with no citizen personal information; one determining benefits eligibility using names, social security numbers and financial information; one analysing aggregate anonymised usage statistics with no individual-level data; and one routing national security briefings. For each, state the level, the baseline that applies, and the authorization timeline you would plan for.
• Compare two providers for a system needing Moderate authorization: one already authorized at Moderate with an established continuous monitoring track record, and one in process with an estimated eight months remaining and not yet usable at Moderate. For a project with a twelve-month timeline, write the recommendation and show the arithmetic behind it.
• Select five controls relevant to your AI system. For each, state what the control requires, how a cloud provider would implement it, how you would verify the implementation rather than accept the assertion, and what would go wrong if the control were absent.
• Build the budget estimate for deploying an AI system on cloud infrastructure: authorization-related costs, the premium on authorized services against non-authorized equivalents, agency staff for security oversight, and contingency for authorization delay. Mark every figure you had to source from outside this lesson.
• Work an incident scenario. Your system runs on an authorized provider and the vendor detects an unauthorized access attempt. Write the notification process and its deadline, who must be informed inside and outside the agency, what investigation follows, at what point affected citizens or stakeholders are told, and what finding would disqualify the system from continued operation.
• Take one AI tool your agency uses today and separate its two documents: find the authorization and note its level, boundary and date, then find the contract or terms of service clause governing retention and training on your data. If either is missing, that absence is your finding.

Reflection

Consider an AI system your agency is acquiring or already running on cloud infrastructure. What data does it handle, and what impact level does that data actually require rather than the one someone assumed? Which provider is behind it, and what precisely is their authorization status, level and boundary? How does the authorization timeline interact with the date the programme has already promised? Then the question that separates a plan from a hope: what capacity does your agency have to read the monthly continuous monitoring reports, and if the honest answer is none, who is going to notice the day a control lapses?

Glossary

• FedRAMP: The Federal Risk and Authorization Management Program, the government's standardized approach to cloud security assessment and authorization, designed so one assessment can be reused by many agencies.
• Impact level: The classification of a cloud service based on the sensitivity of the data it handles. Low, Moderate or High, determining which control baseline applies.
• Authorization boundary: The defined set of components an authorization covers. Anything outside it, including a model called from another provider, is not covered.
• NIST SP 800-53: The catalogue of security and privacy controls for federal systems, organised into families, from which the FedRAMP baselines are drawn.
• System Security Plan: The document describing a system's architecture, data flows and how each applicable control is implemented. The agency maintains its own for its deployment.
• Continuous monitoring: The ongoing process of monitoring controls to confirm they remain effective, reported by the provider and acted on by the agency.
• Plan of Action and Milestones: The document recording security control deficiencies and the timeline for remediating each one.
• Accrediting official: The government official who reviews the assessment and decides whether to authorize the system, which is an acceptance of residual risk rather than a technical finding.
• Customer responsibility matrix: The provider's list of controls it does not implement for you, which your agency must implement and evidence itself.
• Model poisoning: Corrupting training data so that the resulting model behaves in a way the attacker chose.
• Model theft: Reconstructing a trained model by querying the deployed system repeatedly, which is why rate limiting is a security control.

Related Lessons

• Federal Acquisition of AI: FAR/DFARS covers the contract terms that must sit alongside the authorization, including the data-use clauses it does not provide.
• AI Vendor Evaluation Methodology supplies the scoring approach for the status questions in this lesson.
• Evaluating AI Vendor Claims takes on the "we are FedRAMP authorized" claim in its natural habitat.
• Sovereign AI: Data Residency and National Security goes deeper on the residency question an authorization does not answer.
• PII and AI: The Bright Red Lines covers the data classification decision that sets your impact level.
• Privacy Impact Assessments for AI Systems is the parallel privacy assessment to the security one described here.
• Third-Party AI Risk Management handles the downstream model providers inside and outside the boundary.
• Enterprise AI Risk Management places authorization status into the agency's risk register.
• AI Incident Response: What to Do works the notification obligations from the agency side.
• Vendor Lock-In Prevention covers what happens when the only authorized option is also the only option.

Closing

FedRAMP and cloud authorization are complex but they are not obstacles to route around. The core principle is one sentence: government data requires infrastructure that meets federal security standards, and someone has to have checked. The process is rigorous because the stakes are, and understanding it early prevents both delay and the more expensive kind of failure, where a system runs for a year on infrastructure nobody assessed.

Hold the two ideas together and you will avoid the mistakes in this lesson. The authorization tells you the environment was assessed. The contract tells you what may be done with your data inside it. Tomas lost six weeks to a tool that failed the first test. The agencies that get hurt worse are the ones that pass the first test, assume it answered the second, and find out later that their staff's policy drafts became training data for someone else's model.

Key Takeaways

• FedRAMP gates cloud AI. If a tool stores, processes or transmits federal data in the cloud, it generally needs an authorization at the matching level. Most AI tools qualify, and the agency's own obligation to secure its systems is what sits underneath.
• An authorization certifies security posture, not data use. It speaks to assessed controls inside a defined boundary at a stated level. Retention, logging, human review, subprocessors and training on your inputs are contract terms. Two documents, two questions, and never assume one answered the other.
• Classify data first. The data sets the impact level, not the application's function. Decide Low, Moderate or High, then require that level. Choosing the tool first is backwards.
• Ask exactly what the authorization covers. Level, boundary and date. An authorization at Low is not one at Moderate, and a vendor application running on an authorized cloud is not itself authorized by that fact.
• Probe AI-specific risks the catalogue does not reach. Where prompts and outputs go, model and data separation, adversarial robustness, model theft, decision logging, residency and downstream model calls.
• Get "no training on our data" in writing. It is the most common gap and the most damaging if missed, and no authorization supplies it.
• Authorization is day one, not the finish. Annual assessment, continuous monitoring, prompt incident notification, remediation plans and periodic re-assessment keep it alive.
• Continuous monitoring is the agency's responsibility. The provider reports; the agency decides what to do about it and implements the controls designated as its own. You can outsource operation, not accountability.
• Plan the schedule and the budget honestly. Authorization on an already-authorized cloud is a matter of months; waiting for an in-process provider adds many more; an individual agency authorization is a year or two. Do the arithmetic against your delivery date before you shortlist.
• New does not mean blocked. GSA-led efforts are accelerating AI authorization, but "in the pipeline" is never "authorized." Wait for the real authorization, and run the go/no-go flow in week one.

Frequently Asked Questions

The vendor says they are FedRAMP authorized. Is that enough?

It is the start of the conversation. Ask three questions: authorized at what impact level, covering which components, and as of when with continuous monitoring current. An authorization at Low does nothing for Moderate data, an authorization covering the platform may not cover the application or the AI feature, and an authorization whose monitoring has lapsed is not the assurance it appears to be. Then ask the fourth question, which is not about the authorization at all: what does the contract say the vendor may do with our data?

Does an authorization mean the vendor cannot train on our prompts?

No, and this is the most consequential misunderstanding in government AI adoption. The authorization concerns the security of the assessed environment. What happens to your inputs afterwards, whether they are retained, logged, reviewed by staff, shared with a subprocessor or used for model improvement, is governed entirely by your contract and the vendor's terms. Require an explicit, written exclusion from training and from human review, name the retention period, and get it in the contract rather than in an email from a sales engineer.

Can we run a pilot on an unauthorized tool if we use fake data?

Sometimes, and only with real discipline about what "fake" means. A pilot on genuinely synthetic or public data may fall outside the requirement, but staff testing a writing assistant will paste in real drafts within days unless something physically prevents it, and a policy draft is federal data. If you go this route, define the permitted data in writing, tell participants explicitly what may not be entered, keep the pilot short, and get your security officer to agree the arrangement in advance. Bring them in before the pilot rather than after, because the answer to "may we" is far easier to obtain than the answer to "we already did."

Who is responsible for security once we are on an authorized cloud?

Both parties, along a line the provider will document for you. The provider implements the controls inside its environment and reports on them. Your agency maintains its own system security plan for how your system is deployed, implements every control on the customer responsibility matrix, configures the service correctly, monitors the logs and alerts it receives, and reports compliance to leadership. The half agencies underestimate is the reading: a monthly report nobody opens leaves you unaware of a lapsed control while your file shows an authorized system.

Our AI tool is a wrapper around another company's model. What do we check?

Both layers, and the join between them. Establish which components sit inside the wrapper vendor's authorization boundary and whether the underlying model provider is separately authorized at the level your data requires. Ask for the boundary diagram and the data flow, not a summary, because the question you are answering is whether your data crosses out of an assessed environment into an unassessed one. Then check the contract chain: your terms with the wrapper vendor do not automatically bind the model provider behind it, and a training-exclusion you negotiated with the front end is worth little if the back end operates under different terms.