ACP and Microsoft Foundry Agent Service: governance beyond the Azure boundary
Of the three hyperscalers’ enterprise agent surfaces, Microsoft’s Foundry Agent Service is the most coherent — and that’s not a backhanded compliment. Microsoft has more enterprise governance DNA than AWS or Google, and Foundry shows it.
Each agent gets its own Microsoft Entra Agent ID, a new identity type purpose-built for agents. Azure RBAC scopes apply natively. Conditional Access policies extend to agent identities. Customer Managed Keys rotate independently of Microsoft-managed encryption defaults. Bring-your-own-model is GA, with Foundry honoring pre/post LLM hooks via Azure API Management or Mulesoft. The April 2026 open-source Agent Governance Toolkit — a stateless policy engine with sub-millisecond p99 enforcement — completes the picture.
For Microsoft-stack-deep enterprises, this is real. Active Directory + Microsoft 365 + Azure + Foundry is a single-vendor governance story with native Purview / Defender / Sentinel integration. Hard to beat inside its scope.
What it doesn’t span: the rest of your AI stack. This post is the honest read on Foundry’s coverage and where ACP plugs in for cross-environment unification.
What Foundry covers well
- Microsoft Entra Agent ID: the closest any cloud has come to “agents are first-class identity principals.” Scoped Azure RBAC, integrates with Conditional Access, audit-trail-native. The cleanest agent-identity story among the hyperscalers.
- Agent Governance Toolkit (OSS): stateless policy engine intercepting every agent action before execution. Sub-ms latency. You can self-host it; it’s open source on GitHub.
- Bring-your-own-model: connect any provider through Azure API Management or Mulesoft. Foundry honors pre/post LLM hooks, policy-based model selection, multi-region failover.
- Customer Managed Keys for data at rest. Standard setup uses your Azure resources for fine-grained data governance.
- Native integrations with Microsoft Purview (data governance), Defender (threat detection), Sentinel (SIEM).
For Fortune 500 teams already running Active Directory and Microsoft 365 — the typical Foundry buyer — this is a single-vendor stack. No cross-product reconciliation. No multi-vendor identity graph.
What’s outside Foundry’s scope
Same architectural pattern the other two hyperscalers have: Foundry is designed to govern agents that run inside Azure. Four categories of agent activity sit outside that surface — by design, not by oversight:
- Coding agents on developer laptops. Claude Code, Cursor, Codex CLI run locally on developer Macs, in IDE processes, calling LLM APIs directly. The natural intercept point for them is the agent runtime’s own hook surface, which is a different architectural layer than Foundry.
- Agent code outside Azure. A CrewAI service on Cloud Run, a LangGraph supervisor on Render, a Vercel AI SDK app on Cloudflare Workers — these run outside Foundry’s runtime, so the natural intercept point is in the agent code itself.
- Multi-cloud workloads. Foundry unifies governance inside Azure, which is exactly its intended scope. Cross-cloud unification is a separate architectural concern that lives above any single cloud’s product.
- Code-level integration in arbitrary frameworks. Foundry’s intercept is at the agent-runtime layer. For per-tool-call interception inside Python or TypeScript agents that don’t run on Foundry, a code-level pattern at the tool dispatch boundary fits naturally — that’s where ACP composes.
These aren’t bugs in Foundry. They’re the natural boundary of what an Azure-native control plane is built to govern.
Where ACP composes alongside Foundry
Three concrete intercept points ACP adds at a different architectural layer:
- Cross-cloud unified audit. Same audit log across Azure, AWS, GCP, on-prem, developer laptops. The CISO’s “who did what through which agent last Tuesday?” gets one query, regardless of cloud.
- Cross-framework breadth. 15 framework / client integrations covering coding agents, multi-agent frameworks (CrewAI, LangGraph), TypeScript SDKs (Vercel AI, Mastra, Anthropic Agent SDK), Python SDKs (Pydantic AI, AutoGen, Google ADK), MCP clients (Claude Desktop, Cline). Foundry covers Foundry-managed agents — one surface.
- Vendor-agnostic identity propagation. Foundry’s Entra Agent ID is excellent if your IdP is Microsoft Entra. ACP works the same with Auth0, Okta, Firebase, Google, custom OIDC — and propagates the verified end-user identity to non-Azure APIs that don’t speak Microsoft’s identity protocols.
How to compose them
Three patterns, parallel to the AWS Bedrock equivalent:
Pattern 1 — Foundry for Azure, ACP for everything else
Default for multi-cloud or coding-agent-heavy environments:
- Azure-hosted Foundry agents → Foundry’s native governance + Entra Agent ID + Agent Governance Toolkit
- Non-Azure agents (CrewAI on GCP, LangGraph on AWS, Cursor on dev laptops) → ACP
- Cross-environment audit → forward Microsoft Sentinel events into your SIEM alongside ACP’s webhook stream
Pattern 2 — ACP via Azure API Management
Foundry’s bring-your-own-model honors pre/post LLM hooks via Azure API Management. Configure ACP as one of the hook destinations. APIM calls ACP before the LLM dispatches; ACP applies policy + audit + PII scanning. Foundry’s agent identity flows in via the request context.
Pattern 3 — ACP at the tool-handler layer for Foundry agents calling external tools
Your Foundry agent calls a tool exposed by your service (custom MCP server, internal API). Foundry governs the call. ACP governs the response — wrap the receiving handler with @governed and the response gets PII redaction, audit, policy checks before it returns to the agent.
The Microsoft-stack-deep edge case
If your entire AI stack lives inside Microsoft’s world — Active Directory + Microsoft 365 + Azure-everywhere + Foundry-managed agents only + Purview as your audit destination + Defender for AI threat detection + Sentinel as your SIEM — Foundry alone is genuinely sufficient. Microsoft has the tightest single-vendor story in the category.
For everyone else (multi-cloud, developer-laptop agents in scope, multi-framework, multi-IdP), Foundry is one piece of a stack that needs an above-cloud unification layer.
The short version
Foundry is the right answer for Azure-hosted agents at Microsoft-deep enterprises. ACP is the right answer for agents outside Azure, for cross-environment unified audit, and for the long tail of multi-framework and developer-tool agents that don’t fit Foundry’s enforcement model. Use both — same agents, two governance scopes, one audit story.
Detailed install: /integrations/microsoft-foundry-agent-service.
Reference architecture → · Get started →