The problem is that those systems were almost never built for an AI to talk to them. That's where the Model Context Protocol (MCP) comes in — and the way Zihin puts it into production with the MCP Bridge.

What MCP solves

MCP is an open standard for exposing tools to a language model in a structured way: each capability becomes a function with a name, a description and typed parameters. The agent doesn't "guess" how to use your system — it gets a contract.

Tip: Think of MCP as the "USB-C" of agent tools: a standard connector between the model and any system, instead of a custom integration for every case.

From legacy to MCP, without a rewrite

The declarative MCP Bridge maps existing resources to MCP tools without requiring any change to the source system. In practice, three paths cover most cases:

• via API — a REST/GraphQL endpoint becomes a tool with a schema derived from its contract.
• via Database — parameterized queries become safe tools, with an allowlist of operations.
• via native MCP — MCP servers you already expose plug straight into the runtime.

The mapping is declarative. You describe what to expose; the Bridge takes care of how to present it to the agent:

tool: consultar_pedido
source: erp.orders
input:
  pedido_id: string
returns: json

The part that usually gets stuck: on-premise

Much of the critical data isn't in the public cloud — it's behind the firewall. The Tunnel establishes outbound connectivity from your environment to the runtime, without opening inbound ports or setting up a VPN. The agent reaches the on-premise legacy system; your network stays closed to the world.

Warning: Reach without control is risk. Every tool exposed through the Bridge follows the policies of its scope (tenant → agent → user) — the topic of the next post in this series.

Connecting is the first pillar: Reach. It's what takes AI off the slide and puts it where the work is actually done. Want to see it in your own setup? Book a diagnostic.

Originally published in Portuguese on the Zihin blog. I work at Zihin, which connects AI agents to a company's systems and processes, with permissions, human approvals and cost tracking.

Governance that lives in a PDF is intent. Governance that lives in the runtime is operations.

What a contextual policy (CSP) is

A Contextual Security Policy ties a permission decision to the context of the execution, not just to the identity of the caller. Five axes cover most real-world needs:

• Origin — which channel or application the request came from.
• Schedule — time windows in which certain actions are allowed.
• Data — which fields the agent can read or write.
• Behavior — limits on volume, frequency and escalation.
• Custom — rules specific to your domain.

Note: The policy isn't a front-end filter or a reminder in the prompt. It's a check executed in the runtime, before the tool runs — the agent simply can't cross the line.

Scope inheritance: tenant → agent → user

What makes this workable at scale is inheritance. You define the most restrictive policy at the top (tenant), and each level below can tighten — never loosen — what it inherited:

tenant   → the organization's compliance baseline
  agent  → what this agent can do
   user  → what this user can trigger on the agent

So a data-protection rule (LGPD, Brazil's privacy law) defined once on the tenant applies to every agent and user, with no need to paste it into each configuration. Less surface for human error — and human error is what causes most over-access.

Without evidence, there was no governance

Enforcing the rule is half the job. The other half is proving it was enforced. Every policy decision is recorded and can be reconstructed in the session replay: who asked, what the policy decided, and why.

Tip: An audit shouldn't be a weeks-long project. With full replay, answering "has the agent ever accessed this data?" is a query, not an excavation.

Governing is the second pillar — the inseparable partner of Reach. It's no use for the agent to reach everything if it doesn't respect limits wherever it lands. Put the two together and AI stops being a compliance risk and becomes an auditable asset. Talk to us.

Originally published in Portuguese on the Zihin blog. I work at Zihin, which connects AI agents to a company's systems and processes, with permissions, human approvals and cost tracking.

Today we use three possible paths, which let us make good use of what MCP offers. MCP (Model Context Protocol) is an open protocol created by Anthropic and now adopted by the main players in the market. In practice, that has made it the "USB-C" of enterprise AI: instead of building a handcrafted connector for every model–system pair, you build an MCP server once and any compatible client can connect to it.

The protocol exposes three primitives: Resources (data the model can read for context), Prompts (reusable templates for standardized flows) and Tools (functions the model can invoke to take real actions — fetching a record, firing an event, changing a status).

We've implemented three strategies in production over the last year, and that has been cutting costs and headaches. Which raises the question: what does it cost, today, not to implement this protocol? The MIT study (Project NANDA) showed that about 95% of enterprise generative AI pilots deliver no measurable P&L impact — pointing to enterprise integration failures as the core problem, not model quality. That's against an estimated US$30–40 billion invested in GenAI, with 95% of organizations getting zero return. In most cases, the bottleneck is the difficulty of maintaining many separate integrations, which cost time and money besides being inefficient. It becomes clear that one of today's bottlenecks in enterprise AI is integrating models with systems, not the quality of the models themselves. (Source: "The GenAI Divide: State of AI in Business 2025", MIT Project NANDA, via Fortune)

Note: The study attributes the failure to the "learning gap" and to integration with real workflows.

So how did our team choose to get around this problem? Precisely by applying three strategies, which vary in isolation and effort, presented by Fernando Junior, our Development Lead, based on what we run in production.

— Isabele Santos

Strategy 1 — Proxy + Swagger

Data flow: LLM → MCP Server (acting as a proxy) → existing HTTP REST API.

Automation: the server reads Swagger/OpenAPI files natively and generates the LLM "tools" 100% automatically.

Zero cost on the legacy side: no change needed in the original backend code.

Ideal scenario: perfect for fast prototyping, integrating external APIs or plugging in legacy systems where code changes are complex.

The limit of this approach: the quality of the generated tools is the quality of your OpenAPI documentation. Poorly described APIs produce tools the model uses poorly. It's the right strategy to get started in days — not to be a product's final destination.

Strategy 2 — Simple Project (Read-Only)

Lean micro-server: we build simplified projects in which the MCP Server skips the deep, complex layers of a typical web application. It focuses exclusively on exposing Tools with strict, predefined SQL scripts, eliminating the complexity of HTTP routing.

Safe execution (read): every instruction made available to the AI is guaranteed to be limited to read-only operations on the database. This approach creates a fast, efficient foundation for reporting, context validation and conversational BI with no structural risk.

— Fernando Junior

This is the structural answer to the question every manager asks: "what if the AI deletes my database?". Here the guarantee isn't an instruction in the prompt asking the AI to behave — it's architecture. The model only has access to predefined, read-only queries, and nothing else exists for it. Security by construction, not by trust.

— Isabele Santos

Strategy 3 — Integrated via Clean Architecture

Multiple entry points: our modern architecture lets the same business rule be triggered both through a traditional HTTP Controller and through the new MCP channel.

MCP adapter: the MCP Tool Handler is written as just a new adapter in the interface layer of our Clean Architecture, encapsulating the protocol's complexity.

Unchanged rules: the motto is "New door, same house". Our Use Cases and Core Domain stay completely unchanged, safe and reused with no duplicated logic.

MCP doesn't break what already exists: MCP acts as just one more side entrance, running in parallel with the existing controllers. We keep the Separation of Concerns principle intact, isolating human clients from AI agents. Clean Architecture lets us guarantee that the business rule (Use Cases) can't tell the difference between a conventional HTTP call and an execution generated by the LLM.

After implementation: what we learned running MCP in production

Putting an MCP server online is the easy part. What sustains operations comes afterwards — and three fronts deserve attention because they're exactly what separates those who have operated it from those who have only read the docs:

1. Security starts at the connection, not in the prompt. In our implementation, strict client identification happens when the connection to the server is initialized, via an API Key sent in an HTTP header. And authorization is dynamic: the data exposed — and even which Tools are listed — is filtered according to the permissions of the connected agent. A BI agent doesn't see the same tools as an operations agent; it doesn't even know they exist. The natural roadmap for this layer is full adoption of OAuth 2.0 and JWTs, the market standard.

2. Validate the server in isolation before plugging in the LLM. The best workflow practice we've adopted: test Tools and Resources locally with the MCP Inspector (the official debugging UI, which starts with a single npm command) before attaching the server to any LLM client. The Inspector lets you run each Tool with a click, fill in the input payload, analyze the output array and — crucially — inspect the raw JSON-RPC traffic in the History tab. Debugging the protocol together with model behavior means adding up two uncertainties; separating them saves hours.

3. Errors are part of the contract. MCP's return format includes the isError: true flag for recoverable failures — and that changes the game: the model interprets the failure and can fix its own arguments and try again, with no human intervention. Designing good error messages stopped being cosmetic; it became part of the interface with the agent.

— Fernando Junior

The most valuable side effect of all this is portability. An MCP server built today works tomorrow in any ecosystem that adopts the protocol, from Claude Desktop to IDEs like Cursor and VS Code, and even our own applications. Integration investment is no longer thrown away every time you switch model vendors.

The MIT diagnosis doesn't say generative AI failed. It says integration failed. And integration is an engineering problem with a known solution: a single standard instead of dozens of handcrafted connectors. The three strategies we've presented aren't theory; they're the three steps we use in production, from a prototype in days (Proxy + Swagger) to safe data access (Read-Only) to the long-term product (Clean Architecture). The decision rule is simple: the more mature and critical the system, the more structural the integration should be.

Whoever builds this foundation now isn't betting on a vendor — they're building the door through which any AI agent will enter their operation. That's exactly the foundation we brought into Zihin: the platform speaks MCP from day one, with a remote server ready to connect your systems to agents without a handcrafted integration project — with governance and security from the connection onward. If your team is stuck in the pilot phase, the problem probably isn't the model, it's the bridge. Book a diagnostic and see in practice how to plug your data and actions into governed AI agents.

— Isabele Santos

Q&A

Tip: Where do I start implementing MCP in my company? With the lowest-risk strategy: an MCP proxy over an existing, well-documented API (Swagger/OpenAPI), or a read-only micro-server over a reporting database. Both deliver value in days, without touching legacy code, and serve as a learning step before structural integrations.

Note: Does MCP only work with Claude? No. MCP was born at Anthropic, but it's an open protocol adopted by the main AI ecosystems in the market. An MCP server built today works with any compatible client — models, IDEs and your own applications.

Warning: Is it safe to give an AI access to the database? It depends on how the access is built. With a read-only MCP server exposing only predefined queries, the AI structurally can't change anything — the limitation lives in the architecture, not in behavioral instructions. For writes, the path is to expose specific Use Cases with per-agent authorization, never direct database access.

Note: Do I need to rewrite my systems to use MCP? No. The three strategies in this article exist precisely to avoid that: a proxy over existing APIs (zero change), a parallel micro-server (zero change) or a new adapter in the interface layer (minimal, isolated change). The business rule stays intact.

Sources

• The GenAI Divide: State of AI in Business 2025 — MIT Project NANDA (Fortune coverage)

Originally published in Portuguese on the Zihin blog. I work at Zihin, which connects AI agents to a company's systems and processes, with permissions, human approvals and cost tracking.