Azure AI Foundry · FedRAMP Moderate engineering
Azure AI Foundry configuration for FedRAMP Moderate systems
Technical how-tos for building private, identity-aware AI applications inside a verified federal cloud authorization boundary. Start with the architecture and scope decisions, then choose an implementation guide.
What makes an Azure AI Foundry deployment eligible?
Azure AI Foundry is the name many teams use to search for what Microsoft now documents as Microsoft Foundry. The platform combines models, projects, agents, tools, and management features. Those components do not automatically share one compliance boundary.
A FedRAMP Moderate-aligned configuration starts with an authorized cloud service offering and its current package. Verify the exact cloud, region or geography, service, model deployment type, feature status, and external dependencies. Your application still needs implemented controls, documented responsibilities, assessment evidence, and the applicable authorization decision.
Azure Government is not a universal prerequisite for every FedRAMP Moderate workload. Choose the offering required by the agency and data handling requirements. Likewise, a Government subscription does not make every preview, tool, model, or connected service acceptable.
Verified public offering records and service scope
As checked on October 7, 2026, the FedRAMP Marketplace lists these Microsoft offerings. The current Marketplace uses “FedRAMP Certified” terminology; these are provider offering records, not an authorization for your application.
| Offering and package ID | Listed status | Certification profile |
|---|---|---|
| Azure Commercial Cloud — F1209051525 | FedRAMP Certified; ongoing certification | Rev5; JAB path; Class D (High) |
| Azure Government (includes Dynamics 365) — F1603087869 | FedRAMP Certified; ongoing certification | Rev5; JAB path; Class D (High) |
Microsoft’s service compliance scope inventory, whose public and Government tables are marked February 2026, lists Azure OpenAI, Azure AI Search, and Document Intelligence within FedRAMP High scope in both clouds. The Government table also lists Microsoft Foundry portal and Azure AI Content Safety. A portal listing does not establish coverage for every agent capability, preview, model, or API; verify each component against the applicable package. A High-scope service can support a Moderate system’s inherited controls, subject to its boundary and customer responsibilities.
Full package review remains required. The Marketplace’s Quick Start guide directs reviewers to request security documentation using the package ID. Microsoft’s Service Trust Portal lists the Azure Commercial System Security Plan and Appendix A, but downloading the SSP requires signing in to a Microsoft cloud services account. These guides do not claim to have reviewed those protected documents.
Reference architecture: private, identity-aware AI
- Authenticated user
Verified tenant, audience, groups, and roles - Application gateway and runtime
Request authorization, rate limits, deterministic managed identity - Private service connections
Approved model deployment, document store, Search, and logs - Evidence and operations
Configuration snapshots, access decisions, redacted telemetry, recovery tests
Use separate identities for ingestion, retrieval, inference, and tool execution. Keep network paths and data-plane permissions explicit. A private endpoint restricts inbound access; it does not automatically restrict an agent’s outbound tool calls or enforce document-level authorization.
Microsoft’s Government documentation currently lists Foundry in US Gov Virginia and US Gov Arizona, with a feature subset. The documented Government project endpoint is https://{resource}.services.ai.azure.us/api/projects/{project}; a Government agent client uses the https://ai.azure.us/.default token scope. Those values are not interchangeable with commercial endpoints.
Choose a technical implementation guide
Private endpoints and identity
Configure account access, DNS, agent egress, least-privilege roles, and positive and negative network tests.
Configure the private network →Document-based RAG
Build chunk-level ACL filtering, ingestion boundaries, source citations, and authorization tests before generation.
Build permission-aware RAG →Agents and function calling
Choose supported agent capabilities, constrain tool dispatch, and enforce authorization outside the model.
Configure controlled agents →Document extraction
Separate OCR, model interpretation, deterministic validation, and human approval in a bounded pipeline.
Build the extraction workflow →Models, deployment types, and cost
Compare region and data-zone processing, deployment eligibility, token charges, and supporting services.
Choose models and estimate cost →Evaluation and observability
Exercise cross-user leakage, injection, tool misuse, retention, and redacted monitoring before release.
Verify readiness and evidence →Map engineering outputs to the Moderate control implementation
| Concern | Relevant NIST SP 800-53 families / controls | Evidence to produce |
|---|---|---|
| Access and privilege | AC-2, AC-3, AC-6; IA-2, IA-5 | Role exports, user authentication tests, denied tool and document access |
| Boundary and transmission | SC-7, SC-8, SC-13 | Private DNS results, public-path denial, approved egress, TLS and cryptographic configuration review |
| Data and recovery | SC-28; CP-9, CP-10 | Store inventory, encryption/key settings, retention and restore exercises |
| Audit and monitoring | AU-2, AU-3, AU-6, AU-9, AU-11; CA-7 | Redacted event schema, access protection, retention settings, alert tests |
| Change control | CM-2, CM-3, CM-6; SI-2, SI-4 | Pinned dependencies, reviewed infrastructure changes, model/version records, regression results |
This table supports control mapping. It does not establish that a control is fully satisfied or that all Moderate requirements are covered. Review inherited controls and customer responsibilities separately.
Deployment checklist and release gate
- Record the provider offering, authorization reference, system boundary, and applicable customer responsibilities.
- Approve the model, version, deployment SKU, processing geography, API, and feature status.
- Provision approved stores and private connections; verify the actual endpoint names in the selected cloud.
- Assign separate runtime roles and enforce per-user data and tool authorization.
- Configure retention, safety settings, egress, and content-minimized telemetry.
- Run denied-access, injection, deletion, recovery, quota, and release-regression tests.
- Package configuration and results for review through your program’s assessment and authorization process.
The implementation examples are small, inspectable components. Live Azure deployment, package review, and runtime acceptance tests must be completed in your environment before production use.
Sources and technical review
Technical review: . Microsoft documentation changes over time; recheck feature availability and your authorization package before deployment.
- Microsoft Foundry overview
- Microsoft Foundry in Azure Government
- Agent Service feature availability in Azure Government
- Data, privacy, and security for models sold by Azure
- Azure Government model deployment types
Microsoft’s Azure FedRAMP guidance describes shared responsibilities and notes that Azure Policy provides only a partial view of overall compliance. Use the cloud services in audit scope documentation to locate the provider’s current scope inventory.
Confirm the offering and applicable authorization status in the FedRAMP Marketplace and review the provider package and your system security plan. Service availability is not an authorization determination.