Reviewing Microsoft Foundry Agent Service — hosted agents and hypervisor isolation

Every agent session runs in its own hypervisor-isolated sandbox with a dedicated persistent file system, production-grade isolation at cloud scale rather than container-level separation alone. Each session gets an automatically provisioned Microsoft Entra ID as its own agent identity, and every model call, tool invocation, sub-agent hop, and handoff flows through one OpenTelemetry tracing pipeline.

The auto-provisioned agent identity is genuinely useful for a review — it means every agent has its own auditable identity by default, rather than sharing a service principal. What it doesn't do automatically is narrow that identity's permissions; a review still has to check what each agent's Entra Agent ID was actually granted.

The isolation model above describes Foundry's hosted-agent compute layer specifically. A separate, critical finding hit an adjacent surface: agents built in Azure AI Foundry and published into Microsoft 365 as Copilot-integrated agents. CVE-2026-35435 (CWE-284, improper access control) let an attacker escalate from a low-privileged role to extensive control over AI resources, agent configurations, and connected data — and because published agents inherit their creator's broad permissions into Outlook, SharePoint, OneDrive, and Teams, the practical blast radius reached well past the agent itself.

Hosted agents support deployment inside network-isolated Foundry resources, and can use a customer-provided Azure Virtual Network for outbound traffic — letting agents reach private resources like internal databases or APIs without opening them to the public internet. That capability is exactly the kind of thing a review needs to inventory explicitly: a BYO-VNet configuration expands an agent's reachable blast radius to whatever that VNet can see, which is easy to under-scope if it's configured once and not revisited as the network evolves.

For any system built on Foundry Agent Service, a design-time review should be able to answer:

• What is each hosted agent's Entra Agent ID actually scoped to access, verified against the agent's real tool set, not a template?
• If deployed with a customer-provided VNet, what internal resources does that VNet actually expose to the agent, and is that list current?
• Is OpenTelemetry tracing enabled and reviewed for every model call, tool invocation, and handoff — not just spot-checked?
• Does the persistent file system per session get cleaned or rotated, and what happens to any sensitive data written to it across a long-running session?
• If any agent is published into Microsoft 365 as a Copilot-integrated agent, is the tenant confirmed past the CVE-2026-35435 fix, and has the agent's inherited permission scope into Outlook/SharePoint/OneDrive/Teams been reviewed independently of its Foundry-side identity?

See reviewing Microsoft Agent Framework for the orchestration-layer questions that apply when Agent Framework code is what's actually running inside a Foundry-hosted agent.