In this blog post Microsoft Agent Framework MCP Approval Policies for Production AI we will explain what the latest approval controls mean, where the risks remain, and what technology leaders should review before allowing AI agents to act across production systems.
The high-level issue is simple. An AI agent that only drafts content creates a manageable risk. An agent that can update customer records, change access permissions, issue refunds or send company information outside the business needs much stronger controls.
Microsoft Agent Framework provides the software foundation for building and operating these agents. Model Context Protocol, or MCP, is the common connection method that lets an agent use external tools and business systems. Think of MCP as a universal adaptor for AI agents.
MCP approval policies are the traffic rules around that adaptor. They determine which tools an agent can use automatically, which actions require a person to approve them, and which actions should be blocked completely.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingWhat changed in Microsoft Agent Framework 1.25
Microsoft Agent Framework Python 1.25 introduced callable MCP discovery approval policies. In plain English, organisations can now apply their own decision logic when the framework discovers tools available through an MCP server.
Earlier approaches often relied on broad settings such as requiring approval for everything or allowing everything. That may be acceptable during a small pilot, but it creates problems in production.
Approving every action frustrates employees and turns managers into workflow bottlenecks. Approving nothing creates the risk that an agent will perform a sensitive or irreversible action without anyone checking it.
The new controls allow teams to make more precise decisions based on factors such as the tool name and whether a tool is described as read-only. Microsoft Foundry Toolbox metadata can also influence the approval requirement, while an explicit policy configured by your development team can override that metadata.
Our earlier MCP approval policies governance guide explains the configuration model in more detail. The important question for leaders now is how these controls should fit into a production governance process.
Approval policies are not the same as security permissions
This is where many AI projects go wrong. An approval policy can pause an action, but it does not replace identity, access and security controls.
If an agent has administrator-level access to Microsoft 365, Azure or a finance platform, clicking “approve” could still release an unnecessarily powerful action. The agent should operate with the minimum access required, even when a human approval step exists.
The same principle applies to the approver. Your system should record who approved the action, what they were shown, what data was involved and what happened after approval. A shared approval account or a simple yes-or-no button without identity checks is not enough for a production system.
For Australian organisations, this supports the intent of the Essential Eight, the Australian Government’s baseline cybersecurity framework. In particular, it complements controls around restricting administrative privileges, multi-factor authentication, application control and timely patching.
Approval policies do not make an agent Essential Eight compliant by themselves. They are one part of a broader control environment.
Do not automatically trust a read-only label
Microsoft Agent Framework can use MCP metadata indicating that a tool is read-only. This is useful because a tool that retrieves an approved product price is usually less risky than one that changes that price.
However, the framework does not independently prove that every read-only classification is accurate. It relies on information supplied through the configured Toolbox.
A poorly designed or compromised MCP server could describe a tool as read-only even though it sends data externally, creates an audit entry or triggers another system. Your team should therefore verify the behaviour of a tool before using its metadata to bypass approval.
A practical policy model might look like this:
# Illustrative governance logic rather than SDK configuration
verified read-only tool = allow automatically
reversible internal update = require business approval
payment or identity change = require specialist approval
unknown or unclassified tool = block
unapproved MCP server = block
sensitive data leaving Australia = block or escalate
This risk-based approach gives employees speed for low-impact tasks without treating every action as harmless.
What CIOs and CTOs should review before upgrading
1. Decide what happens when information is missing
Missing approval metadata can result in a tool not requiring approval by default in some Foundry Toolbox scenarios. Production policy should not depend on every external tool publisher describing risk correctly.
For sensitive environments, unknown should mean blocked or manually reviewed. That decision reduces the chance of a newly discovered tool becoming available before security and business owners have assessed it.
2. Test policy refreshes
Agent Framework 1.25 can reapply approval policies when MCP tool catalogues are refreshed or connections are restored. This helps policies stay attached as tools change, but it also means discovery is part of your production security boundary.
Test what happens when a tool is renamed, its metadata changes or the MCP server becomes unavailable during refresh. Your agent should retain a known safe state rather than quietly receiving broader access.
3. Prepare for the wider 1.25 changes
The Python 1.25 release requires Python 3.11 or later. It also introduces default limits for MCP discovery and request timing, helping prevent an unreliable or untrusted server from consuming unlimited resources.
These are sensible protections, but they can affect existing integrations. Do not push the upgrade directly into production. Pin the version, test it in a non-production environment and confirm that discovery limits, timeouts and approval flows behave as expected.
4. Separate policy ownership from development
Developers can implement approval logic, but they should not decide business risk alone. Finance should define what requires approval in payment workflows, security should control identity and access changes, and data owners should decide how sensitive information may be used.
Record these decisions in a simple tool register. Include the tool owner, MCP server, data accessed, possible business impact, required approver and review date.
5. Monitor the outcome, not just the approval
An approval record proves that someone clicked a button. It does not prove that the tool performed the expected action.
Production monitoring should connect the approval request to the resulting tool call, system change and audit record. Alerts should identify repeated denials, unusual approval volumes, new tools and actions occurring outside expected business hours.
A practical 200-person company scenario
Consider an anonymised example based on a common professional services rollout. A 200-person company introduces an AI service desk agent connected to Microsoft 365, Intune, which manages and secures company devices, and its ticketing platform.
The agent can safely retrieve approved support articles and check device compliance without approval. Resetting a standard user session requires service desk approval, while changing security policies or granting administrator access is blocked from the agent entirely.
The result is not maximum automation. It is controlled automation.
Employees receive faster answers, the service desk handles fewer repetitive requests, and high-impact security actions stay with authorised specialists. This is a better business outcome than either approving every minor lookup or giving the agent unrestricted access.
Make release watch part of AI governance
Microsoft Agent Framework is developing quickly. Approval behaviour, hosting options, security fixes and runtime safeguards can change between releases, so agent governance cannot be a one-time project.
Assign an owner to review release notes and security advisories. Maintain a tested version, document every upgrade decision and rerun approval tests whenever your agent, MCP server, identity model or tool catalogue changes.
You can also use the checklist in our Microsoft Agent Framework production guide for Australian teams to assess release stability, compliance and operational readiness. For a deeper look at balancing automation with oversight, see our guide to securing AI agent tool use with MCP approvals.
The business outcome is controlled confidence
Flexible MCP approval policies make it easier to move AI agents beyond demonstrations without choosing between slow manual reviews and unsafe automation. The value comes from applying clear risk tiers, minimum permissions, verified identities, audit records and regular release testing.
CloudProInc brings more than 20 years of enterprise IT experience to this work. As a Microsoft Partner and Wiz Security Integrator, our Melbourne-based team helps organisations connect Agent Framework, Azure, Microsoft 365, Microsoft Defender, Wiz, OpenAI and Claude without losing sight of practical security and business outcomes.
If you are not sure whether your production AI agents have the right approval boundaries, we are happy to review the setup and identify the highest-priority gaps — no strings attached.