MCP Tool Approval Policies That Keep Microsoft AI Agents Safe

In this blog post MCP Tool Approval Policies That Keep Microsoft AI Agents Safe we will explain how mid-market teams can decide which AI actions happen automatically, which need human approval and which should never be available.

The problem is rarely that an AI agent cannot complete a task. The bigger concern is that it completes the wrong task quickly, using live business systems and legitimate access.

An agent might safely look up an invoice status. It should not necessarily be able to change a supplier’s bank details, release a payment or delete a customer record without someone checking the request.

What MCP tool approval policies actually do

Model Context Protocol, usually called MCP, is a standard way for AI agents to connect to business tools and data. An MCP server can make approved functions available to an agent, such as searching documents, creating a support ticket or updating a customer record.

Microsoft Agent Framework provides the software layer for building and operating these agents. Its approval controls can pause selected tool calls before they run, send the proposed action to a person or application for review, and continue only after a decision is returned.

This is known as a human-in-the-loop control. It turns approval into part of the workflow rather than relying on an employee to notice a mistake afterwards.

Approval does not replace access control. The agent still needs its own identity, limited permissions and a secure connection to each system. Approval is an additional guardrail for actions where context and human judgement matter.

Why approving every tool call does not work

Some organisations respond to AI risk by requiring approval for everything. It sounds safe, but employees soon face a stream of low-value prompts for routine searches and read-only requests.

Approval fatigue follows. People stop reading the details and click approve simply to keep work moving.

The opposite approach is equally risky. Allowing every action to run automatically may produce an impressive demonstration, but it can expose the business to incorrect transactions, privacy breaches and operational disruption.

The practical answer is a risk-based policy. Our earlier article on why MCP tool access is a security decision explains why connecting a tool is only the beginning. Approval policy determines how that access can be used in day-to-day operations.

Use three approval levels

1. Automatic for low-risk, read-only work

Tools that only retrieve non-sensitive information can often run without approval. Examples include checking an order status, reading an approved policy library or searching a public product catalogue.

The business outcome is speed. Employees receive useful answers without introducing an approval bottleneck.

2. Human approval for sensitive or reversible changes

Actions that change data, communicate externally or affect a business process should normally pause for review. Examples include creating a supplier, sending a customer email, changing a service request or preparing a refund.

The approval screen should show the proposed action, affected record, important values, requesting user and reason. An approver should not have to interpret raw code or a vague message such as “Allow tool execution?”

3. Blocked for unacceptable actions

Some capabilities should not be exposed to the agent at all. Deleting backups, disabling security controls, exporting an entire customer database or granting administrator access are good examples.

This follows the principle of least privilege, meaning the agent receives only the access required for its job. Microsoft also recommends validating and authorising model-generated tool calls before they create side effects in business systems.

What a practical policy looks like

A finance agent could be allowed to search suppliers and read invoice status automatically. Creating a supplier or releasing a payment would always require approval, while deleting financial records would not be offered as a tool.

A simplified Python configuration for a hosted MCP tool could look like this:

finance_tools = HostedMCPTool(
 name="finance_mcp",
 url="https://finance-mcp.internal.example",
 allowed_tools=[
 "search_supplier",
 "get_invoice_status",
 "create_supplier",
 "release_payment"
 ],
 approval_mode={
 "never_require_approval": [
 "search_supplier",
 "get_invoice_status"
 ],
 "always_require_approval": [
 "create_supplier",
 "release_payment"
 ]
 }
)

The important part is not the code. It is the business decision behind each list. Tool names, approval behaviour and defaults should also be tested against the exact Agent Framework package and hosting model being deployed because local and hosted tools can process approvals differently.

A scenario mid-market teams will recognise

Consider a 180-person distributor introducing an agent to help accounts staff process supplier invoices. The agent can save hours each week by finding purchase orders, matching invoice details and identifying missing information.

Giving that same agent unrestricted payment access changes the risk completely. A misleading document, incorrect supplier record or poorly worded request could influence the agent to propose the wrong transaction.

A sensible policy allows searches and matching to happen automatically. Changes to supplier bank details require approval from finance and security, while payment release remains inside the existing financial authorisation process.

The company keeps most of the productivity gain without allowing an AI workflow to bypass controls that took years to establish.

Build the approval workflow around accountability

An approval button alone is not governance. Mid-market teams should record who requested the action, which agent and tool were involved, what information was submitted, who approved it and what happened afterwards.

Set time limits as well. An approval that sits unanswered for two days should expire rather than remaining available after the business context has changed.

These records can support incident investigation, internal audits and Australian privacy obligations. They can also contribute evidence for Essential Eight governance, although the Essential Eight—the Australian government’s baseline cybersecurity framework—does not specifically certify MCP approval policies.

Approval controls should sit alongside the identity, network and monitoring safeguards covered in our guide to securing agentic AI and MCP servers. Teams hosting MCP services on Azure Kubernetes Service can also use a governed AI agent gateway to create one controlled entry point.

Five steps to put approval policies into production

1. Inventory every available tool. Record its owner, purpose, connected system and the data it can access.
2. Classify the business impact. Separate read-only requests from data changes, external communications, financial actions and destructive operations.
3. Assign an approval level. Choose automatic, human approval or blocked. Avoid relying on an undocumented default.
4. Test denial and failure paths. Confirm what happens when an approver rejects a request, is unavailable or receives an incomplete explanation.
5. Review after every upgrade. Agent Framework is developing quickly. Include approval testing in the Agent Framework release and upgrade process.

The goal is controlled automation

MCP tool approval policies let businesses automate routine work without treating every AI action as equally safe. Low-risk work moves quickly, sensitive actions receive scrutiny and unacceptable capabilities remain unavailable.

CloudProInc brings more than 20 years of enterprise IT experience to this work. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations connect Agent Framework, Azure, Microsoft 365, Defender and Wiz controls into a practical operating model.

If you are unsure whether your agents have too much access—or whether constant approval prompts are slowing people down—we are happy to review the setup and help define a workable policy, with no strings attached.