Separate cloud assurance from system authorization

Learning objective

Distinguish FedRAMP authorization boundaries and inherited versus system-owned controls when selecting deployment environments.

Core idea

A federal workload needs an approved service boundary and an accountable system owner. A US region, an approved model family, or the cloud provider’s assurance package does not establish that every application component and integration is covered.

FedRAMP’s agency guidance distinguishes reusable cloud-service certification from an agency’s authorization of its own federal information system. The agency authorizing official accepts risk for the particular information, configuration, integrations, and agency-operated controls. Select the service version and configuration that fit the agency’s requirements, reuse the provider’s assessed work, and document the remaining implementation in the agency system security plan (SSP). The agency’s authorization and compliance owners make the determination; the architect supplies the boundary and control allocation.

How it works

Select an offering, not a brand

Identify the federal use case, information category, required security treatment, and approved integrations before selecting an inference route. FedRAMP’s “Using a FedRAMP Certified Cloud Service” directs agencies to confirm the certified version of the offering, review its package and secure configuration guidance, and determine suitability for the agency’s information and mission. Certification classes describe the rigor and amount of certification information; they do not replace the agency’s security categorization or risk decision.

Anthropic’s government page identifies Claude API access through Amazon Bedrock in AWS GovCloud for FedRAMP High and through Google’s Vertex route with Assured Workloads for FedRAMP High. It explicitly excludes the direct Anthropic Claude API, including Claude Platform on AWS, from FedRAMP authorization. For Claude in Bedrock in AWS GovCloud, AWS authorizes each model separately; check the selected model against the AWS services-in-scope list referenced by Anthropic’s government page. Anthropic’s product documentation calls the Google product Agent Platform. Preserve the exact offering and approved configuration in the selection record rather than treating those names as interchangeable contracts.

Anthropic also describes Claude for Government as a FedRAMP High authorized product for government users. Distinguish that application offering from an API embedded in your own service. An employee’s approved chat product does not establish that the backend service they are designing uses the same boundary.

Trace the entire system and its external dependencies

Draw a boundary inventory covering the application, identity integration, prompt assembly, inference route, retrieval sources, tool services, logs, backups, administrative access, and incident workflow. Mark the operator and information exchanged at every external interface. These are proposed design artifacts for the SSP, not an Anthropic model setting.

Identify authorized use, users, information, system boundary, selected and tailored controls, and relied-upon services in the agency’s SSP. A telemetry collector or evaluation store outside the selected offering is an integration to assess, even if the model invocation itself stays inside an approved environment. Evaluate whether that flow is permitted, what it contains, and which control owner must operate it.

Avoid the shortcut “all data must remain in one vendor account.” The deciding facts are the authorized system boundary, approved external services and exchanges, and assigned controls. Conversely, a trusted commercial account is not automatically an approved destination for federal prompts merely because its storage is encrypted.

Allocate inherited, system-owned, and shared work

Use the provider’s FedRAMP Certification Package and secure configuration guidance to identify the capability you can rely on. The agency SSP documents each selected control, with detailed implementation for agency work and references to provider material for provider work. The following is an illustrative allocation; the actual package determines inheritance:

A fully inherited control needs a justified reference, not a copied implementation narrative. A shared control needs both the provider capability and the customer’s configuration or procedure. A system-owned control needs its own implementation and verification. “Inherited from the cloud” is incomplete when nobody can identify the package statement or the required customer action. Inheritance can also come from an agency common-control provider: identify that provider and the authorization or evidence being inherited. If a control is tailored out, record the approved rationale required by agency policy.

Authorize the system and maintain the allocation

FedRAMP’s guidance says agencies issue their own authorization to operate (ATO) or authorization to use (ATU) even when relying on a certified service. The ATO covers the federal information system leveraging external cloud services; do not create a standalone agency ATO for the cloud offering itself.

Maintain one agency SSP for the information system. Assess the agency-operated controls and verify their configurations work with the provider capabilities. Reference the provider’s package instead of duplicating its full assessment. This reduces redundant work without hiding the parts the agency still owns.

Track agency-owned weaknesses in a plan of action and milestones (POA&M). Provider vulnerability information may require an agency action, such as adding a safeguard or restricting use, but FedRAMP advises against copying provider vulnerabilities into the agency POA&M without such an agency action. Revisit the SSP when the use case, information, boundary, integration, configuration, or relied-upon provider capability changes.

Key distinctions and trade-offs

Region versus authorization boundary: US-only inference is a geographic property. FedRAMP assurance concerns a particular service offering and assessed controls; agency authorization concerns the system’s use. A region parameter cannot substitute for either decision.

Inheritance versus delegation of accountability: Reusing provider assurance saves reassessment effort. The agency still operates its controls and accepts its system risk.

Feature convenience versus approved scope: A commercial feature or model can improve capability while remaining unavailable or outside the selected government configuration. Verify availability and scope before designing a dependency; defer the feature if it cannot satisfy the authorized design.

Architecture / decision scenario

A government agency has 90 days to pilot a benefits-case assistant in an AWS-based federal environment. One proposal uses the direct Claude API with inference_geo: "us", retaining the team’s commercial tracing service. Another uses the documented Bedrock GovCloud route and an agency-approved logging integration.

The architect selects the second route, subject to package and configuration review and confirmation that AWS separately authorizes the chosen Claude model. The first proposal establishes US inference but uses an API Anthropic excludes from FedRAMP authorization; it also leaves the trace export unassessed. A direct API success response would resolve neither issue.

The security lead records the selected service and applicable assurance in the SSP. The identity owner configures agency groups and reviews privileges; security operations owns event routing and incident response; the application owner constrains retrieval and tools. Provider safeguards are referenced where justified, while the agency tests its own configuration. The authorizing official decides whether the complete system can operate, and the team records unfinished agency work in its POA&M rather than claiming the model route completed authorization.

Common exam traps

• Equating US-only routing with FedRAMP authorization.
• Treating the direct Claude API and Bedrock GovCloud as the same offering.
• Assuming every control is inherited because the infrastructure is assessed.
• Ignoring logs, administration, or tool exchanges when describing the boundary.
• Replacing the agency system authorization with a provider certificate.

Where the exam guide differs

What to remember

Select the exact approved offering and configuration, trace every integration, and allocate each control to provider, system, or shared operation. Reuse provider assurance with a defensible reference. The agency still authorizes its system and maintains its own controls, SSP, and remediation actions.

Knowledge check

References

• FedRAMP, Using a FedRAMP Certified Cloud Service
• FedRAMP, The Agency System Security Plan
• Anthropic, Claude for Government
• Anthropic, Claude on Google Cloud
• Anthropic, Data residency
• Anthropic, Claude Certified Architect – Professional Exam Guide