In this blog post Microsoft Agent Framework MCP Approval Policies Governance Guide we will explain why a routine framework update can quietly change which AI actions need human sign-off, and what technology leaders should check before approving it for production.
The issue is not whether an AI agent can answer questions. It is whether that agent can use connected tools to retrieve sensitive records, update customer data, send messages or trigger business processes without the right person reviewing the action.
What the technology does in plain English
Microsoft Agent Framework is a development platform for building AI agents and multi-step AI workflows. These agents can use models from services such as Azure OpenAI and Anthropic Claude, maintain context and interact with other business systems.
Model Context Protocol, usually called MCP, is a standard way to connect an agent to external tools. Think of MCP as a universal adapter that can let an agent search documents, query a database, create a service ticket or call an internal application.
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 ConsultingWhen an agent connects to an MCP server, it performs discovery. This means it asks the server which tools are available and what those tools claim to do.
An approval policy then decides whether a person must approve a tool before the agent uses it. Without a sensible policy, businesses usually end up with one of two bad outcomes: every action requires approval and the system becomes frustrating, or too many actions run automatically and create unnecessary risk.
What changed in the latest Python release
Microsoft Agent Framework Python 1.25.0, released on 9 November 2026, added callable MCP discovery approval policies. In practical terms, developers can now use policy logic to decide which discovered tools require approval instead of applying one fixed setting to everything.
The release can also use approval information supplied through Microsoft Foundry Toolbox, including tool-name and read-only filters. It supports explicit caller overrides and can refresh approval decisions for tools retained after an MCP catalogue update.
That last point matters. An MCP server can change the tools or metadata it publishes without your application necessarily being rebuilt, so approval decisions need to remain correct as the available catalogue changes.
This release also includes other changes, including a move to Python 3.11 or later and new limits for MCP discovery. It should therefore be treated as a governed upgrade, not a small security feature that can be enabled in isolation. Our Microsoft Agent Framework release and upgrade governance guide explains how to test and approve these broader changes.
Why callable policies matter to the business
Approvals can follow risk rather than inconvenience
A fixed policy may require the same approval for reading a public product guide and deleting a customer account. That creates approval fatigue, where employees start approving requests without properly reviewing them.
A callable policy can evaluate information about each tool and apply different treatment. Low-risk searches may proceed automatically, while financial transactions, data changes and external communications pause for review.
The business outcome is faster automation without giving the agent unrestricted authority.
Read-only does not always mean harmless
The new support for read-only filtering is useful, but it should not become an automatic trust signal. A tool that only reads data could still retrieve payroll details, customer records, legal documents or commercially sensitive information.
Approval decisions should consider both what the tool does and what information it can access. A read-only search of public documentation is very different from a read-only query across executive mailboxes.
Metadata should be verified rather than blindly trusted
MCP servers publish descriptions and other information about their tools. This metadata helps the framework identify tools, but it is supplied by the server and may change when the server is updated.
For important systems, tool metadata should be treated as an input to your policy rather than the final security decision. CloudPro Inc generally recommends an approved list of MCP servers, known tool names and independently defined risk categories.
Overrides need their own controls
Explicit caller overrides allow an application to replace a default approval decision. This can be useful when a trusted workflow has additional context, but an override can also become a shortcut around governance.
Overrides should only be available to approved application components. Every override should record who or what requested it, which policy was bypassed, the reason and the final outcome.
What a practical policy might look like
The following simplified pseudocode illustrates the decision model. It is not intended as a drop-in production configuration.
def decide_approval(tool, user, environment):
if tool.server not in APPROVED_MCP_SERVERS:
return "block"
if tool.name in HIGH_RISK_TOOLS:
return "human_approval_required"
if tool.read_only and tool.data_classification == "public":
return "allow"
if environment == "production":
return "human_approval_required"
return "block"The important point is that the decision is based on several factors. These include the server, tool, data classification, user and environment rather than trusting a single label.
For more detail on designing the approval flow itself, see how MCP approval policies secure Microsoft AI agent tool use. The next governance step is ensuring those policies remain effective across releases, catalogue refreshes and changing business permissions.
A realistic governance scenario
Consider a 200-person professional services company introducing an agent to help its finance and operations teams. The agent connects to an MCP server offering tools for searching invoices, viewing customer accounts, changing payment details and emailing suppliers.
If every tool is automatically approved, a misleading email or poorly worded request could lead the agent towards a sensitive action. If every tool requires approval, employees will spend their day confirming routine invoice searches.
A risk-based policy provides a better balance:
- Searching general invoice status can run automatically for authorised finance employees.
- Reading bank details requires approval because the information is sensitive.
- Changing payment details requires approval from a separate finance manager.
- Sending an external payment instruction requires a second verification step.
- Any unrecognised tool or MCP server is blocked by default.
This approach reduces repetitive work while retaining human control over actions that could cause financial loss, privacy incidents or fraud.
What CIOs and CTOs should review now
- Inventory every MCP connection. Record the owner, server location, authentication method, available tools and business systems each connection can reach.
- Classify tools by business impact. Separate public information searches from sensitive reads, record changes, external communications, code execution and financial actions.
- Set a safe default. New or unclassified tools should be blocked or require approval until they have been reviewed.
- Validate read-only claims. Confirm the underlying system permissions and data scope rather than relying only on published metadata.
- Control policy overrides. Limit who can introduce an override, require a documented reason and include overrides in security monitoring.
- Test catalogue refreshes. Confirm that renamed, replaced and retained tools receive the correct policy when an MCP server changes its catalogue.
- Record meaningful audit evidence. Capture the tool, arguments, requesting identity, approval decision, policy version, target system and result.
- Test the complete release. Pin the framework version, test it outside production and maintain a rollback path. Our release cadence and version governance guide provides a practical model.
How this supports Australian security requirements
MCP approval policies do not make an organisation compliant on their own. However, they can support the intent of the Essential Eight, the Australian Government’s cybersecurity framework that many organisations are expected or required to follow.
They are particularly relevant to restricting administrative privileges, controlling changes and creating evidence that sensitive actions were authorised. They can also support privacy and audit obligations by reducing unnecessary access to personal information.
The policy still needs strong identity controls, limited system permissions, secure authentication and monitoring. Where possible, the agent should use Microsoft Entra identities with only the permissions required for its specific job rather than shared accounts with broad access.
The governance decision is bigger than one feature
Callable MCP approval policies are a useful improvement because they allow controls to match real business risk. They do not remove the need for careful server selection, least-privilege access, testing, logging and release management.
CloudPro Inc combines more than 20 years of enterprise IT experience with practical work across Azure, Microsoft 365, OpenAI, Claude, Microsoft Defender and Wiz. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations assess these controls without turning a useful AI project into a giant compliance exercise.
If you are not sure whether your agents have the right approval boundaries, or whether the latest Agent Framework release is safe for your environment, we are happy to take a practical look with you — no strings attached.