From the Microsoft edition of October 30, 2026
Microsoft documentation: in Azure Government, Foundry Agent Service supports prompt agents and core tools but not hosted agents, web/Bing search, computer use, SharePoint or A2A; preview features may lack FedRAMP, IL5 or CJIS commitments
Microsoft (Microsoft Learn) · State and local government (Azure Government) · United States (US Gov Virginia, US Gov Arizona)
- Publisher
- Microsoft Learn
- Original publication
- 2026-08-19 (ms.date); newly relevant with the Oct. 28 harness announcement
- Source retrieved
- 2026-10-31
What happened
Microsoft's Learn page on Foundry Agent Service feature availability in Azure Government lists US Gov Virginia and US Gov Arizona as regions. Prompt agents are available; workflows are in preview; voice-based prompt agents and hosted agents are not available. Tools available include Code Interpreter, File Search, Azure AI Search, Azure Functions, function calling, MCP servers and the OpenAPI tool (Custom Code Interpreter is preview); web search, Bing grounding, image generation, browser automation, computer use, Microsoft Fabric, SharePoint and agent-to-agent (A2A) are not. Publishing agents with Entra identities is supported. The page warns that preview features might not carry the same compliance commitments, such as FedRAMP, DoD IL5 or CJIS, as generally available features. It does not mention the Copilot harness announced Oct. 28.
Why it matters
Agencies on Azure Government cannot assume Microsoft's newest agent capabilities (hosted agents and the Oct. 28 harness) are available to them, and must treat preview features cautiously for CJIS or FedRAMP workloads. Filed now because the Oct. 28 announcement makes the gap decision-relevant.
Evidence and measured results
Vendor documentation table; authoritative for stated availability at its date but not an independent assessment.
Limitations and uncertainty
Page dated Aug. 19 (ms.date); availability may have changed. Absence of the harness from the page is the researcher's observation, not a Microsoft statement. Vendor documentation.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-31; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Government agencies hear about new Microsoft agent features but run in Azure Government, where many are unavailable.
- Stakeholders
- Agency CIO
- Compliance/CJIS officer
- Enterprise architect
- Program sponsor
- Discovery questions
- Must this workload run in Azure Government?
- Which compliance commitments (FedRAMP High, IL5, CJIS) are required?
- Which agent features does the design depend on?
- Value hypothesis
- Designing to documented government capabilities may avoid rework and compliance surprises.
- Potential engagement
- Azure Government agent feasibility and compliance check.
- Unsupported claims
- The Copilot harness is available in Azure Government
- Preview features carry FedRAMP/IL5/CJIS commitments
- Current availability (page dated Aug. 19)
Pre-sales engineering
Role takeaway
- Fit
- Agencies with regulated workloads in Azure Government.
- Architecture and integration
- Prompt agents with core tools in US Gov Virginia/Arizona; published agents with Entra identities.
- Prerequisites
- Azure Government subscription
- Feature-availability verification
- Compliance requirements list
- Constraints
- No hosted agents, web/Bing search, computer use, SharePoint or A2A
- Workflows preview only
- Security
- Use only features with documented compliance commitments for CJIS/IL5 workloads.
- Proof of value
- Prototype a prompt agent with File Search and MCP in a government region
- Validate compliance documentation for each feature
Delivery
Role takeaway
- Work
- Government-specific agent delivery with feature gating.
- Dependencies
- Microsoft availability updates
- Compliance sign-off
- Ownership
- Agency architecture team with compliance officer.
- Skills and adoption
- Developer briefing on government feature gaps.
- Governance checkpoints
- Availability check at kickoff and each phase
- Exclude preview features for regulated data
- Acceptance criteria
- Proposed: every feature verified as available in the government region before production
- Risks
- Designs built on unavailable features
- Preview features used for regulated data
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Agent designs in Azure Government are limited to prompt agents with core tools; designs relying on hosted agents, web grounding, computer use or SharePoint tools need alternatives.
Governance
Who approves, reviews and stays accountable for outcomes?
Compliance teams should treat preview features as lacking FedRAMP, IL5 or CJIS commitments until confirmed otherwise.
Security and privacy
What data, permissions and controls need testing?
For CJIS workloads in public safety, only features with documented compliance commitments should be used.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Developers trained on commercial Foundry features need guidance on what is unavailable in government regions.
Procurement
What should contracts, pricing and exit terms secure?
Buyers should confirm availability in their specific cloud before committing to agent projects described in commercial announcements.
Operating model
Which teams own the service once it runs?
Hybrid patterns (commercial for non-sensitive work, government for regulated) may emerge, with governance overhead.
Publication history
- 2026-10-30Microsoft · Issue 0213 resources
Stable resource ID: microsoft-learn-foundry-agent-service-azure-government-feature-gaps-hosted-agents-no-2026