Three questions for
your MCP gateway.

If you set up an MCP gateway this year, you did something useful. One connection now reaches the systems your agents need, the credentials are handled in one place, and the tool list is something you can read. This piece is not about whether to have one. It is about the three things to write down so that the good work is visible to the people who will ask.

Two architectures, one table.

The category splits cleanly in two, and the split decides what you are responsible for. Vendors below are listed alphabetically within their type. None is ranked and none is a competitor to SanctumShield; every one of them is an example of a category doing a real job.

Everything below is organised around three questions. They are the same three the MCP Gateway Governance Gap finding checks, so if you can answer them in writing, the finding closes.

Question 1. Who owns it?

One named human, not “the platform team.” Ownership is the first thing an auditor, an underwriter or a board member asks for, and a team name is not an answer. Gartner’s April 2026 guidance was written for exactly this moment. Aaron Lord, Sr. Director Analyst, recommended that software engineering leaders “create a formal security review for MCP use cases to prioritize low-risk patterns and explicitly exclude high-risk combinations.” A review needs a reviewer, and a reviewer needs a name.

How to record it. One row in your AI system register for the gateway itself, with an owner field, a review date, and the connected systems listed beneath it as children. The free Board AI Register template now has this row.

Question 2. What may it do, in writing?

The tool-scoping record answers four things: which tools, which sources, read or write, and which hosts may connect. It is the one-page not-allowed list applied to a gateway.

Type A. Use the vendor’s own scoping features. Most managed catalogs let you restrict a server to specific connectors, mark a connector read-only, or expose a custom tool set rather than the universal one. Configure it, then export the configuration. The export is the record. Date it.

Type B. The policy file is the record. Version it in the same repository as the gateway configuration, require a reviewer on changes, and keep the tool allowlist explicit rather than inherited from whatever servers happen to be registered.

“Which hosts may connect” deserves its own line because it is where most scoping records fall short. A gateway that any MCP client can reach with a copied URL is scoped by whoever holds the URL. Vendor-operated gateways usually let you bind a server to one named client, or to one user, and the enterprise tiers add allowlists. Self-hosted gateways do this in the policy file. Either way, write down the answer. If the honest answer today is “anyone with the link,” write that down too. A record that says so is worth more than a record that does not exist.

Question 3. Are the identities governed?

This is the question with the most evidence behind it, and the one practitioners most often skip. 8.5% of the 5,200+ open-source MCP servers analysed use OAuth; 53% rely on long-lived static secrets such as API keys and personal access tokens (Astrix Security Research, State of MCP Server Security 2025). A static key in an environment variable is a shared identity, and a shared identity cannot be revoked for one person or one agent.

Type A. Per-user identity should be inherited from your identity provider through SCIM and OAuth, never a shared API key. On the vendor’s trust page, look for five things: single sign-on, SCIM provisioning, audit log export, a written retention statement, and whether a DPA and, where you handle PHI, a BAA are available. Note the hosting region while you are there. If any of the five is not published, write “not published” in your record rather than assuming.

Type B. A named operator, a documented fail mode (does the gateway fail open or fail closed when policy evaluation fails?), and logs shipped to a store with a named reviewer. Exposure is the practitioner’s first check, and the trend is the reason. 492 MCP servers found running with no client authentication or traffic encryption, exposing 1,402 tools; about 74% hosted on major cloud providers and more than 90% giving direct read access to the data source (Trend Micro Research (Alfredo Oliveira and David Fiser), July 16, 2025). 1,467 exposed MCP servers by the follow-up scan, nearly triple the July 2025 count, with 1,227 still on the deprecated SSE transport (Trend Micro Research, Update on Exposed MCP Servers, April 28, 2026). nearly 7,000 internet-exposed MCP servers catalogued by early 2026, roughly half with no authentication controls; over 30 CVEs filed against MCP servers, clients and infrastructure between January and February 2026 (Cloud Security Alliance Labs, Agentic MCP Security Best Practices Guide v1 (draft, March 27, 2026)). The NSA’s Artificial Intelligence Security Center published its own design considerations for MCP in May 2026, and it is worth an hour.

What the gateway already gives you.

Most of the evidence for the three questions already exists inside the product. Managed catalogs keep an action history and let you export it. Self-hosted gateways log every tool call by default and several ship OpenTelemetry out of the box. Identity-aware gateways record which user an agent acted for. None of that is the record on its own, because a log answers what happened and a record answers what was decided and by whom. But it means the record is mostly a matter of pointing: this export, this policy file, this identity provider, this name. The gateway did the enforcement work. You are writing down that you govern it.

The sub-processor paragraph.

A Type A gateway is a processor under GDPR Article 28 and a business associate under HIPAA where PHI is in reach. This is not a judgment about the vendor. Zero-retention and vaulted credentials are real controls, and several vendors in the table publish them. They are still the vendor’s controls. The deployer’s job is to record the relationship, name an owner, scope what the agents may do through it, and review it on a cadence. The glossary entry says the same thing in fewer words.

Register it as one entry with children.

A worked example of the row, filled in the way a reviewer would want to read it:

You are in good shape if.

• One person’s name sits against the gateway in a register your board could be shown.
• A dated export or a versioned policy file says which tools, which sources, and read or write.
• Sign-in to every connected source runs through your identity provider, and removing a person from the IdP removes their reach through the gateway.
• For a vendor-operated gateway, the vendor appears on your processor list with the DPA on file.
• For a self-hosted gateway, you can say what happens when policy evaluation fails, and someone reads the logs.
• There is a review date in the future, not only one in the past.

Most practitioners reading this can get there in an afternoon. The gateway already does most of the work. What is missing is usually the page that says so. If you manage gateways for several clients, the same page works for each of them, and the review date is the column that keeps it honest: a register that is never re-read is a historical document.

The record is yours to keep.

The gateway does its job. It enforces and it logs. The record is yours to keep, and without it the good work is invisible to the people who will ask: the auditor, the underwriter, the director, the customer running a vendor review. SanctumShield’s finding type checks exactly these three questions and puts the answer in the Executive Risk Report, on a date, with a verification URL. A gateway is a control point. The record is what proves you govern it.