Microsoft Foundry + ACP — Cross-cloud governance install guide

Microsoft has aggressively built out Foundry Agent Service into a full enterprise agent platform. Each agent gets its own Microsoft Entra Agent ID — a new identity type purpose-built for agents that propagates through Azure RBAC. The April 2026 open-source Agent Governance Toolkit ships a stateless policy engine with sub-millisecond p99 enforcement latency. Bring-your-own-model is GA, with Foundry honoring pre/post LLM hooks via Azure API Management or Mulesoft.

For agents that live inside Foundry, this is a strong governance surface — Microsoft has more enterprise governance DNA than any of the three hyperscalers and it shows.

What it doesn’t span: the rest of your AI stack. Claude Code in your developer’s terminal. Cursor in their IDE. CrewAI on Cloud Run, LangGraph on Render, custom multi-agent code on AWS. Foundry’s enforcement boundary is Azure — by design.

Agentic Control Plane is the layer above. This page is the honest read on what Foundry covers, what it doesn’t, and how the two compose into one identity-attributed audit trail across every environment your agents run in.

TL;DR. Use Foundry for agents you build inside the Azure runtime — they benefit deeply from Entra Agent IDs and Azure RBAC. Use ACP for everything else, and for unified audit across both. The two layers solve different scopes.

What Foundry ships

• Microsoft Entra Agent ID: a new identity type assigned per agent. Scoped Azure RBAC permissions, integrates with Conditional Access, audit-trail-aware. The closest any cloud has come to “agents are first-class identity principals.”
• Agent Governance Toolkit (OSS, April 2026): stateless policy engine that intercepts every agent action before execution. Sub-millisecond p99 latency. Open-sourced on GitHub.
• Bring-your-own-model: connect any provider through Azure API Management, Mulesoft, or Kong. Foundry honors pre/post LLM hooks, policy-based model selection, multi-region failover.
• Customer Managed Keys for data at rest, plus default Microsoft-managed encryption.
• Standard setup: opinionated config that uses customer’s own Azure resources for fine-grained data governance.
• Foundry deeply integrates with Microsoft Purview, Defender, and Sentinel for data governance and SIEM-side visibility.

This is the most coherent enterprise governance story among the three clouds. Microsoft’s audience — Fortune 500 teams already running Active Directory, Microsoft 365, and Azure — get a single-vendor stack.

Where Foundry stops

The same architectural boundary the others have: Foundry governs agents that run inside Azure. Out of scope:

1. Non-Azure agent runtimes. Foundry’s enforcement is Azure-runtime-bound. Claude Code on a developer laptop, Cursor in an IDE, MCP-driven Cline workflows, hand-rolled FastAPI agents on Render — none route through Foundry’s interception surface.
2. Cross-cloud workloads. Identity, audit, and policy are unified inside Azure. Multi-cloud teams (Azure + AWS + GCP) get three identity stories, three audit logs.
3. Code-level integration. Foundry’s intercept is at the agent-runtime layer (the Foundry execution surface). For tool-call interception inside arbitrary Python or TypeScript agents that don’t run on Foundry, you need a code-level pattern — that’s where ACP fits.

These aren’t gaps in Foundry. They’re its scope.

Where ACP plugs in

Three integration paths:

Path 1 — Self-built agents calling Azure OpenAI or Foundry-hosted models (works today)

Your agent runs in your code (Anthropic Agent SDK, OpenAI Agents SDK, custom loop). The LLM calls go to Azure OpenAI or Foundry. Tool execution happens in your code.

from acp_governance import configure, governed, set_context

configure(base_url="https://api.agenticcontrolplane.com")

@governed("query_db")
def query_db(sql: str) -> dict:
    return db.execute(sql)

Tool-call governance, identity propagation, output redaction — all independent of where the LLM lives. The same pattern works whether the model is Azure OpenAI, direct OpenAI API, or Bedrock OpenAI. See the Anthropic Agent SDK integration and OpenAI Agents SDK integration for code.

Path 2 — Foundry agents calling external tools / MCP servers

Your Foundry-hosted agent has Action Groups or tool calls that hit non-Azure endpoints — your CRM, a partner API, your internal service on AWS. Foundry governs the call. ACP can govern the response — wrap the receiving handler with @governed for PII redaction, audit row, and policy enforcement on the tool’s actual outputs.

Path 3 — Foundry agents using ACP’s MCP endpoint

Register mcp.agenticcontrolplane.com/mcp as an MCP server in your Foundry/Azure admin tooling. Your Foundry agents call ACP-managed tools through standard MCP. The two layers compose: Foundry’s Entra Agent ID identifies the caller; ACP’s policy engine evaluates the action.

Honest comparison

Microsoft-stack-deep enterprises (Active Directory, Microsoft 365, Azure-everywhere) will lean on Foundry first. Multi-cloud or developer-tool-heavy environments will lean on ACP first. Realistic enterprise uses both.

Install

For self-built agents (Path 1):

pip install acp-governance     # Python
npm install @agenticcontrolplane/governance  # TypeScript

For coding agents (Claude Code, Cursor, Codex CLI):

curl -sf https://agenticcontrolplane.com/install.sh | bash

Limitations

• Foundry-internal calls aren’t visible to ACP. When a Foundry-hosted agent calls another Foundry agent or Foundry-managed tool, the call stays in Azure — outside ACP’s interception surface. Use Foundry’s own audit (Purview, Sentinel) for those.
• Microsoft Entra Agent IDs don’t auto-flow to ACP. Foundry’s per-agent identity doesn’t automatically propagate to ACP’s audit trail. We’re tracking integration as a roadmap item; for now, propagate explicitly via custom claim on the JWT.
• The Agent Governance Toolkit is OSS, not a service. Microsoft ships the toolkit as open-source code; you operate it yourself. ACP is a managed service.

Related

• ChatGPT Workspace Agents integration — equivalent honest read for OpenAI’s hosted surface
• AWS Bedrock integration — equivalent for Amazon’s surface
• Google Agents CLI — equivalent for Google’s surface
• Anthropic Agent SDK — for self-built agents calling Azure-OpenAI-hosted models
• Reference architecture — how ACP composes with cloud-native governance