From Blind Spots to Board-Ready: Taming Local AI with an MCP Proxy

Modern desktop AI assistants, such as Claude Desktop for example, are powerful productivity boosters. They can interact with local tools on a user's machine to automate tasks, from filling out forms in a web browser to diagnosing system performance. But for an enterprise, this power comes with a massive blind spot.

When an AI model directly triggers a local tool, the interaction is a black box.

MCP (Model Context Protocol) is an open standard that enables AI models to interact with external tools and data sources through a standardized interface, allowing them to perform actions like browsing the web, accessing files, or running commands on the user's machine.

Note: This article builds on the EAIS™ (Enterprise AI Stack) framework introduced in our previous blog post. If you're not familiar with the 8-layer EAIS™ model, I recommend reading that article first for the complete context.

The Problem: Uncontrolled, Ungoverned AI

The typical architecture for a desktop AI assistant creates a direct, unmonitored channel between the AI model (whether cloud-hosted or self-hosted) and the tools running on a user's machine. This governance gap exists regardless of whether you're using a cloud-based AI service like Claude or a self-hosted model running on your own infrastructure.

Desktop Client ⟷ AI Model ⟷ Local Tool on Desktop

Or, put differently, we are missing layer 4 of the EAIS™:

This direct path means the enterprise has:

• No visibility: What tools are being used? What data is being accessed?
• No control: Can we block risky commands or tools?
• No compliance: How can we prove we are protecting sensitive data?

This architecture completely bypasses the critical orchestration layer needed for enterprise-grade AI. Without this crucial layer, there is no central point to enforce policy, audit usage, or ensure safety.

The Solution: A Centralized MCP Proxy for Control

Here I describe a working prototype that introduces a central server that acts as a proxy for all tool-related communication, even for tools running on the user's local machine. This establishes the critical orchestration layer.

Desktop Client ⟷ Central Server ⟷  AI Model
↕
Local Tool on Desktop

Or, put differently, we now have layer 4:

In this architecture, the desktop client establishes a secure connection to our central server. When the AI model needs to use a local tool, it makes a request to our server. Our server then securely proxies that request back to the actual tool running on the user's desktop. This simple change is transformative, forcing all tool interactions through a central chokepoint that we control.

Policy vs. Approval: A Critical Distinction

This architecture allows us to separate two vital concepts: automated Policy Enforcement and user-driven Approval.

Layer 4: Automated Policy Enforcement (The Server's Job)

The central server acts as the first line of defense. Its primary role is to be the automated guardian of enterprise policy, preventing users from accidentally shooting themselves or the company in the foot. It can enforce rules before a tool call ever reaches the user's machine.

For example, the server can:

• Block forbidden actions: Instantly reject a tool call that tries to run a non-whitelisted command like rm -rf to delete files.
• Prevent data leakage: Scan outbound data and redact PII or block the request if it contains sensitive project codenames.
• Enforce access control: Deny the use of a specific tool (e.g., file_system_access) for users in a certain role.

This is an automated, invisible process. A bad call is simply stopped, and the user is informed why.

Layers 6-8: User Approval (The User's Mandate)

If a tool call is deemed safe by the server's policies, it may still require human oversight. This is where the new user approval workflow comes in. The desktop client now intercepts every tool call and asks for explicit permission.

• Intercept and Prompt: The AI wants to navigate to google.com/search?q=USDEUR+exchange+rate. The server's policy allows this, but the desktop client stops the call and presents a dialog to the user: "Do you approve this tool action?"
• User Mandate: The tool only runs after the user clicks "Approve." If they click "Deny," the desktop client sends a synthetic error message back to the AI model, which can then report the denial to the user.
• Defer to Downstream Approval: The AI is asked to "check the current USD to EUR exchange rate." The server's policy confirms this is a valid action. The user approves the initial tool use.

This separation is key: The server enforces what is possible, while the user provides the explicit mandate for what should proceed.

The Story in the Logs: Tracing a Governed Tool Call

Here is a play-by-play of how the MCP proxy architecture handles a user request, using log snippets from the different components to tell the complete story of a governed, user-approved, and successful interaction.

1. System Startup and Connection

First, the central server starts listening. The desktop client then connects to it and launches the local MCP tool (Playwright).

• server.log: The central server initializes, ready for connections.

  2025-08-05 10:53:14,802 - INFO - Starting server...
  2025-08-05 10:53:14,802 - INFO - Serving for desktop on ('127.0.0.1', 5000)
  2025-08-05 10:53:14,802 - INFO - Serving for shim on ('127.0.0.1', 5001)

• desktop.log: The desktop client starts the local tool and connects to our central server.

  2025-08-05 10:55:33,051 - INFO - Starting MCP tool: npx @playwright/mcp@latest
  2025-08-05 10:55:33,069 - INFO - Connected to server at 127.0.0.1:5000

2. The Handshake: The Server Proxies the MCP Initialization

Next, the AI model's SDK (via the shim) initiates a handshake with the local Playwright tool. The desktop_mcp_comms.log clearly shows our central server acting as the intermediary. This requires user approval for the very first communication.

• desktop.log: The desktop client intercepts the first tool call and prompts for approval.

  2025-08-05 10:55:33,069 - INFO - Tool call received from server. Requesting user approval.
  2025-08-05 10:55:54,114 - INFO - Tool call approved by user. Forwarding to MCP.

• desktop_mcp_comms.log: After approval, the server forwards the initialization request from the AI's SDK to the local tool, and the response is sent back.

  SERVER->MCP (stdin): b'{"method":"initialize", ... "id":0}\n'
  MCP->SERVER (stdout): b'{"result":{"protocolVersion":"2025-03-26", ... "id":0}\n'

3. User Request and AI Tool Use

The user first asks for the exchange rate, but the AI initially indicates it cannot access live information. The user then clarifies by telling the AI to use its tools, which triggers the approval workflow.

• server.log: The server logs the user's prompt that initiates the tool use.

  2025-08-05 10:58:46,431 - INFO - Received from desktop for model: What is the USDEUR exchange rate? Use your tools

• server_shim.log: The Gemini SDK sends the browser_navigate tool call to our server.

  2025-08-05 10:58:54,163 - INFO - SDK->SERVER (stdin): b'{"method":"tools/call","params":{"name":"browser_navigate","arguments":{"url":"https://www.google.com/search?q=USDEUR+exchange+rate"}},"jsonrpc":"2.0","id":3}\n'

• desktop.log: The desktop client again intercepts the call and waits for the user's decision.

  2025-08-05 10:58:54,164 - INFO - Tool call received from server. Requesting user approval.
  2025-08-05 10:58:55,484 - INFO - Tool call approved by user. Forwarding to MCP.

4. Successful Navigation and Data Retrieval

The AI successfully navigates to Google and retrieves comprehensive exchange rate information. The proxy's observability captures the complete interaction.

• desktop_mcp_comms.log: We see the successful navigation and the rich page snapshot returned from Google's search results.

  SERVER->MCP (stdin): b'{"method":"tools/call","params":{"name":"browser_navigate","arguments":{"url":"https://www.google.com/search?q=USDEUR+exchange+rate"}},"jsonrpc":"2.0","id":3}\n'
  MCP->SERVER (stdout): b'{"result":{"content":[{"type":"text","text":"### Ran Playwright code\n```js\n// Navigate to https://www.google.com/search?q=USDEUR+exchange+rate\nawait...

5. The Final, Synthesized Answer

The AI model successfully retrieves the exchange rate information and provides a comprehensive summary to the user based on the data from Google's search results.

• server.log: The AI generates the final text for the user based on the retrieved exchange rate information.

  2025-08-05 10:59:00,904 - INFO - TEXT: Based on the information I
  2025-08-05 10:59:00,921 - INFO - TEXT:  found, 1 US Dollar is equal to 0.86 Euro. Please keep in mind that this rate was
  2025-08-05 10:59:00,928 - INFO - TEXT:  updated on August 5th at 3:58 PM UTC and is subject to change.

This log trail provides a concrete, technical demonstration of the MCP proxy's power. Every step, including user approvals and successful data retrieval, is visible and, most importantly, passes through a central point of control, making true enterprise governance a reality. The exchange rate example shows how the system can successfully handle real-world queries that require web navigation and data extraction, all while maintaining full visibility and control over the AI's actions.

Next Steps: Leveraging central control

This MCP proxy implementation demonstrates how Layer 4 (Orchestration) can be established to desktop AI systems. The next step is to leverage this central control to build a more powerful and secure AI system by extracting actionable insights from the comprehensive logging data and implementing robust policy enforcement.

The centralized logging architecture provides rich data for constructing meaningful Key Performance Indicators (KPIs) including:

• Number of tool calls per day/week
• Percentage of chats resolved successfully
• Blocked vs. approved tool call rates
• Average response times and system performance
• User engagement and adoption metrics
• Policy adherence rates and blocked tool call percentages

You can build dedicated parsing programs to convert these logs into database records for historical analysis, or use AI to help write parsing scripts and optimize database queries for KPI extraction. This transforms raw log data into actionable business intelligence for data-driven AI governance decisions, while the policy enforcement layer provides automated protection against unauthorized or risky actions.

See It in Action

Want to see this MCP proxy architecture working in real-time? Check out our demonstration video that shows the complete workflow from user request to governed tool execution:

This video demonstrates the complete user approval workflow, policy enforcement, and the seamless integration between the desktop client, central server, and local tools.

To continue the journey, follow me on LinkedIn and subscribe to the Yttrigen blog.