Microsoft Foundry Agent Service is a hosted environment for building and operating agents. The most consequential production design question is whose authority a tool call carries. A model may choose the right function and perfectly formatted arguments while still attempting an action outside the caller’s privileges. Agent identity, project identity and the identity of the human user must therefore be modeled as different concepts.
How the architecture works
Microsoft describes agent identities issued through Entra, with role assignments for resources and service-side token handling. Its documentation differentiates unpublished agents that may use a shared project identity from published agents with distinct identities. Tool integrations can involve identity tokens, OAuth on-behalf-of access or other connection-specific mechanisms. Security decisions belong to the identity and target resource systems, not to the LLM’s justification text.
A controlled, practical example
Imagine an agent asked to summarize an internal report and propose a new storage folder. It retrieves the report under a scoped principal, writes a proposal record and pauses. A reviewer approves the specific folder name and location. Only then can a narrowly scoped action create the folder; the execution checks the same tenant and target scope before committing. Publishing a separately identified agent may require assigning permissions to that new identity, so a once-working test connection should not be assumed to work in production.
Permissions, approvals and trust boundaries
Check both authentication and authorization: a valid access token can still lack the necessary resource role or target audience. Use narrow RBAC scope and separate read and mutation tools. When connecting to external MCP or A2A endpoints, assess the external server’s retention and revocation behavior. Keep tokens out of prompts. Bind each high-risk approval to immutable tool arguments and expiry, and verify the binding again inside the action service.
Limits and version caveats
Foundry names, APIs and availability evolve; older Azure AI Foundry Agent Service examples may not share the exact current resource model. The cited living docs establish identity concepts, not a specific region, customer SKU or endpoint that works for every subscription. Identity support can also vary by tool. Avoid claiming that every built-in tool uses agent-specific Entra credentials, and treat published-agent permission reassignment as a migration test.
Where it fits and what to use instead
Choose a managed identity-backed Foundry agent when Azure tenancy, monitoring and custom tool integration justify its infrastructure. Use simpler service-to-service code for deterministic steps that need no model-controlled routing. Other choices include Copilot Studio’s visual agent experience and cloud-neutral agent runtimes with explicit secrets brokers. AI 02 owns model choice and AI 10 owns billing; neither can replace an access-control threat model.
How to validate before deployment
Run an authorization matrix: shared project identity, published agent identity, user-delegated token, expired token and incorrect OAuth audience. Test permitted and forbidden Azure resources and a malicious tool response that asks for admin rights. Trace an entire request from authenticated person to agent, tool connection and final side effect. Confirm denial is observable and that the model cannot report action success after an authorization failure.
Version, tier and region applicability
The source links below describe specific capabilities or dated announcements; documentation may change afterward. Where no exact release version, eligible market, service region, contract plan or numeric quota is substantiated, those facts are unknown and are not inferred. This article is a researched implementation guide, not a record of hands-on testing, a license grant, a benchmark, or a current price quote. Independently recheck current product access and commercial terms before deployment.