Third-party MCP servers are suppliers
Adding an MCP server grants tool-level authority to code you did not write and cannot see.
The procurement question nobody asks
Adding a third-party MCP server takes a line of configuration and gives an agent a set of new capabilities immediately. If a vendor asked for the same access through the front door — read this database, call this payments API, write to this repository — it would trigger a security review, a DPA and probably a questionnaire.
The MCP path skips all of it, not because anyone decided to, but because the granting mechanism looks like editing a config file.
Discovery is part of the surface
An agent can only call what it can discover. Filtering the tool list to what policy could ever allow is therefore a control in its own right: the agent never learns that a tool exists, so no prompt, however clever, can talk it into calling one.
Capability drift
Suppliers ship. A server that offered three read-only tools last quarter may offer a write tool today, and nothing in the protocol forces that change past a human. Governing at the gateway means new capabilities arrive denied by default and become an explicit decision rather than a silent expansion.
Treat it like any other dependency
Inventory which servers your agents reach, pin what they are allowed to do, record every call against them, and review the list on the same cadence as any other third-party access. The novelty is the protocol; the discipline is ordinary supplier management.
Decision boundary: Gleis evaluates each tool call against the policy your organisation approved and the evidence collected at the gateway. It does not determine legal rights, certify compliance, or replace legal review.