As agents move into everyday business use, governance questions follow: who is responsible for them, what can they access, and how do we investigate a problem? This is the first post in a series about governing agents built with Microsoft Foundry.
Throughout the series, I'll use one enterprise agent scenario to explain what teams need to do and why.
Scenario: Geeker, a member of the sales team, has built a meeting-preparation agent. It can read customer records, prepare summaries, and use a tool to send email. The demo works. Is it ready for everyone in the company?
I would start with five questions:
- Can we find the agent, and who is responsible for it?
- Who can invoke it, and what can it access?
- Which actions need approval?
- If something goes wrong, can we see what happened?
- Can we disable it and remove its access when necessary?
These questions are a starting point for enterprise agent governance.
1. Do we know which agents exist and who is responsible?
The Foundry Control Plane inventory at Operate > Assets > Agents shows agents on supported platforms in the selected Azure subscription, including their project, current version, and status. A platform team can use this view to spot agents that are already in use but no longer have a clear owner. The list depends on subscription scope, platform support, and the viewer's permissions. An agent's absence from the list does not prove that it does not exist. Foundry agent inventory
Image source: Microsoft Learn
Once you find the agent, identify two people. A technical Owner handles configuration and incidents. A business Sponsor decides whether the agent should keep running and whether it still needs access to customer data. For the meeting-preparation agent, the Sponsor might be the head of sales operations rather than the developer who wrote it. Entra Owners and Sponsors
If the company also has agents built in Microsoft Copilot Studio or other platforms, the Microsoft Agent 365 Registry offers a broader, organization-wide inventory. It serves a different scope from Foundry's subscription-level view. Foundry and Agent 365 integration
2. Who can invoke the agent, and what can it read or write?
There are two separate access checks. The first is who can invoke the agent: the Foundry endpoint can use Microsoft Entra identity and Foundry permissions to authorize callers. The second is what the agent can access: reading from a CRM or writing to Storage still depends on the agent's own identity or delegated user authorization, as well as the target system's permissions. Allowing sales staff to invoke the agent does not give it access to every customer's records. Foundry endpoint authorization · Agent identity
You also need to know which version users are reaching. In Foundry's new agent model, an agent has a stable endpoint and a distinct identity as soon as it is created. By default, that endpoint serves the latest version. If production changes must be evaluated before release, pin the endpoint to an approved version; otherwise, creating a new version could change the behavior users receive. Configure agent versions
For existing projects: Earlier Foundry agents used a different publishing model. An agent under development could share a project identity and receive a distinct identity only when published. New and legacy models may coexist. When reviewing permissions or planning a migration, first check which model the agent actually uses. Do not infer its identity from whether someone says it has been “published.” Official migration guide
3. Which tools can it call, and which actions require human approval?
Foundry Toolbox provides a central place to manage the tools an agent uses and how those tools authenticate. For the meeting-preparation agent, looking up customer information and sending email carry different risks. The first calls for tightly scoped read access. The second may send information outside the organization, so the system should check recipients and require an approval step that can actually pause high-impact actions. Foundry Toolbox
Writing “ask me before sending an email” in a prompt does not make the email API wait for approval. The application executing the action or the downstream API must enforce authorization and approval. When connecting external tools, also find out where data is sent and who retains it. Microsoft's shared responsibility model for AI agents
![Microsoft's shared responsibility model for AI agents]](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/rh2kofmfc3mydlaoljbl.png)
Image source: Microsoft Learn
4. If something goes wrong, can we find out why?
Tracing in Foundry records an agent's execution, helping you see where a failure occurred and which tools it called. To use it, connect the Foundry project to Application Insights and decide who may view the telemetry and how sensitive data in it will be handled. An agent's final answer alone is usually not enough to explain why it read a particular customer's records. Set up Foundry tracing
Image source: Microsoft Learn
Before rollout, test cases that should fail: have an unauthorized user request customer records from a region they cannot access, reject an email approval request, or give the agent retrieved content containing malicious instructions. Foundry evaluations and AI Red Teaming can help uncover problems. The CRM's own permission checks still need separate verification. Foundry AI Red Teaming
5. If we need to stop it, where do we act?
If an agent's responses or tool calls become abnormal, you can disable a new-model Foundry agent's endpoint to prevent new calls. Disabling its Agent Identity in Entra instead prevents that identity from obtaining further access tokens. These controls have different effects. Older Agent Applications also support stopping their deployments. Before rollout, decide who is authorized to take each action during an incident. Foundry intervention options · Entra agent management
Image source: Microsoft Learn
Beyond emergency shutdown, access should not remain in place indefinitely without review. In Entra ID Governance, an access package can put an approval process and an expiration date on an agent's access. The business Sponsor can then decide whether to request an extension. I'll cover this in the next post. Agent identity governance overview
These five questions can fit in a single rollout record: agent and version, Owner and Sponsor, caller and data permissions, tool approvals, traces, and the person responsible for stopping it. If the team cannot fill in one of those fields, it knows what to address next without first creating a large governance process.
You can outsource your thinking, but you cannot outsource your understanding.
