Meshworq Team · 2026-06-22 · 8 min read · ai · mcp · architecture
An agent that can only talk is a demo. An agent that can act is a product. The distance between the two is a set of tools, and the distance between a useful product and a security incident is how you govern access to them.
The Model Context Protocol (MCP) is a standard way to expose tools, data sources, and actions to AI agents. Instead of hardcoding a bespoke integration for every capability, you describe tools in a common protocol and any MCP-aware agent can discover and call them. It is the difference between wiring each appliance directly into the mains and installing a set of standard outlets.
That standardization is genuinely useful. It also raises the stakes. A tool is, by definition, a way for a probabilistic system to reach into a deterministic one, your database, your ticketing system, your billing records, and make something happen. The protocol makes connection easy. It does not, on its own, make connection safe. Safety is architecture you add on top.
A responsible MCP surface is not "here are all our tools, go wild." It is three deliberate layers.
Every tool an agent can reach should be declared in one place, with a name, a schema, the scope it operates in, and the permissions it requires. A registry does the boring, essential work of making the tool surface knowable. You cannot govern what you cannot enumerate, and a registry is the enumeration.
A single source of truth also kills a subtle failure mode: capability drift, where the list of tools the agent thinks it has, the list the server actually serves, and the list the docs describe slowly diverge. When those lists disagree, you get either broken calls or, worse, tools reachable that no one remembers exposing. One registry, consulted by everyone, keeps them honest.
Between an agent asking to call a tool and the tool actually running, there should be a pipeline of gates, not a straight wire. Each gate is a checkpoint:
The gate pipeline is where "the agent wanted to" becomes "the system allowed it to." Those are not the same sentence, and the gap between them is your security posture.
Meshworq runs its governed MCP server exactly this way: a tool registry defines what exists, and a gate pipeline evaluates every call before it executes. The point is not to slow agents down. It is to make every action pass through a place where policy can say no.
Here is the design decision that matters most, and the one most easily gotten wrong.
The naive approach is to let the calling agent tell the server which tenant or workspace it is acting for. This is a cross-tenant hole waiting to happen. If the caller declares its own scope, then a confused, compromised, or cleverly prompted agent can declare someone else's scope and read data it should never see.
The safe approach inverts the trust. Meshworq issues workspace-minted MCP tokens: the workspace mints a token, and the tenant scope is derived from the token itself, not from anything the caller claims. When an agent calls a tool, the server reads the scope off the token and enforces it. The agent cannot ask for more than the token grants, because the agent is not the one making the claim.
This is the same principle behind good API key design: identity and scope belong to the credential, not to the request body. Applied to MCP, it means a tool call is bounded by the token that authorized it, and a token is bound to exactly one workspace.
It is worth being precise about maturity. A governed MCP hub is an emerging capability, and the honest framing is "carefully expanding surface," not "unlimited access." The right posture at this stage is:
None of this is a reason to wait. It is a reason to build the governance and the tool surface together, so that breadth arrives on top of a foundation rather than ahead of one.
Tools are what make agents economically interesting. An agent that can triage a ticket, check a duplicate, and route to the right expert is doing real work, and every one of those actions is a tool call. MCP is how that capability becomes composable and standard instead of a pile of one-off integrations.
The governance is what makes it something you can put in front of customers. A registry makes the surface knowable. A gate pipeline makes every call reviewable. Workspace-minted tokens make tenant isolation a property of the credential rather than a hope about the caller. With those three in place, giving agents real tools stops being a leap of faith and becomes an engineering decision you can defend.
MCP standardizes how agents reach real tools, which is exactly why it needs real governance. Build the hub as three layers: a registry so the tool surface is knowable, a gate pipeline so every call passes through policy, and workspace-minted tokens so tenant scope comes from the credential and never from the caller. Meshworq's governed MCP server follows this shape deliberately, expanding the surface carefully rather than opening it all at once. Safe superpowers are still superpowers, and they are the ones worth shipping.