VIGIL MESH

Documentation

Connecting an AI assistant to your tools

MCP connectors expose a VIGIL-MESH workspace's tools to AI assistants. The assistant connects to an MCP endpoint — a public JSON-RPC service protected by full OAuth — discovers the available tools there and calls them on your behalf. The essential point: network tools do not escape the console's rules; they inherit the same access policy as the rest of the mesh. This page explains what MCP is, how the endpoint is protected, how the console's rules apply, and what to watch on the security side.

What is MCP (Model Context Protocol)

MCP, the Model Context Protocol, is a standard protocol that lets an AI assistant discover and use tools exposed by an external service. Rather than hard-coding each integration, the assistant queries an MCP server to list the tools, learn their parameters, then invoke them. A VIGIL-MESH MCP connector is such a server: it presents your workspace's tools in a form the assistant knows how to consume.

Tool discovery

The assistant asks the server for the list of tools and their descriptions. Nothing is presumed: what is not exposed does not exist for it.

Tool invocation

The assistant invokes a tool with its arguments and receives a structured result, which it integrates into its answer or its reasoning.

Workspace tools

The exposed tools are those of your VIGIL-MESH workspace, including network tools — hence the importance of the rules described below.

A public JSON-RPC endpoint with full OAuth

The connector is exposed as a public JSON-RPC endpoint: requests and responses follow the JSON-RPC convention, and the service is reachable from outside the workspace so that assistants hosted elsewhere can connect to it. Public does not mean open: access goes through a full OAuth flow.

  1. 1
    OAuth authorizationThe assistant obtains explicit consent through the OAuth flow before any access. This is the step where you decide who authorizes the assistant and for which workspace.
  2. 2
    Token issuanceOnce consent is given, an access token is issued. Every JSON-RPC call presents it; without a valid token, the endpoint refuses.
  3. 3
    Authenticated JSON-RPC callsThe assistant lists and invokes tools over JSON-RPC, token in hand. The token's scope bounds what it can reach.

Inheriting the console's rules

An MCP connector does not open a back door into the mesh. The network tools exposed to an assistant respect the same access policy as any other actor: what the console forbids stays forbidden, whether the call comes from a person or from an AI. The assistant inherits the granted rights, it does not bypass them.

Concretely, a network tool invoked via MCP is subject to the role and access rules defined in the console — see /en/docs/console-roles. If the policy does not allow reaching a resource, the tool does not reach it any better on the grounds that an assistant is asking. The surface accessible to the AI is therefore, at best, equal to what the console allows for the identity that consented.

  • Network tools inherit the policy: the console remains the single source of access authorizations.
  • An assistant cannot grant itself more rights than those of the identity that performed the OAuth consent.
  • Restricting a role in the console immediately restricts what an assistant tied to that role can do.
  • Audit what you expose: the right MCP perimeter is the smallest one that makes the assistant useful.

Security

A public MCP endpoint connected to network tools concentrates several risks: access from the outside, actions triggered by an AI, and potentially manipulated inputs. A few reflexes limit the exposure without giving up the use.

  • Treat OAuth consent as a decision: grant it only to assistants and identities you control, and revoke tokens that are no longer needed.
  • Apply least privilege: expose the smallest set of tools, and let the console restrict the associated roles.
  • Beware of content injection: an assistant can be pushed into calling a tool by a text it reads. Do not expose a tool whose abusive triggering would be serious.
  • Log tool invocations so you have a trace in case of abnormal use.
  • Periodically reassess the exposed surface: a tool useful for a while can become a risk once forgotten.
Can an assistant do more than what I authorized in the console?
No. Network tools inherit the console's policy. OAuth consent grants access, but never beyond what the console allows for the identity concerned.
Does the public endpoint expose me without protection?
Public refers to reachability, not openness. Without a valid OAuth token, the endpoint refuses calls, and the token's scope bounds what can be reached.
How do I cut off an assistant that has become suspicious?
Revoke its OAuth token; you can also restrict the corresponding role in the console, which at once reduces what any assistant tied to that role can do.
Read nextNo-code studio