Notifications
Clear all
Topic starter
27/08/2026 2:11 pm
TL;DR: MCP servers can be easy to test locally but much harder to trust in production, because tool scope, credential handling, dependency pinning, and ongoing visibility all determine whether an AI client can safely use them, according to Obot. The real issue is not initial installation but whether runtime governance can contain tool access after the first connection.
NHIMG editorial — based on content published by Obot: practical guidance for vetting third-party MCP servers before production use
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP servers create new risks for NHI governance?
A: MCP turns AI-facing integrations into persistent, callable access paths, which means secrets, resources, and tools all become part of the non-human identity surface.
Q: What breaks when an MCP server's tool descriptions do not match its actual actions?
A: The trust model breaks.
Practitioner guidance
- Inventory every MCP server as a governed identity Record each server's owner, purpose, exposed tools, credential source, and upstream dependencies before it is allowed into any production workflow.
- Separate read-only tools from write-capable tools Review delete, send, update, and shell-execution capabilities as distinct entitlements, then restrict them from broader team access unless there is a documented business need.
- Inspect OAuth scopes and secret paths Compare the server's stated function with the scopes it requests, and verify that tokens, API keys, and environment variables never cross into unintended destinations.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- Repository-level vetting checks for maintainer activity, commit history, and issue patterns before approval.
- Code-reading techniques for finding tool definitions, docstrings, and credential-handling paths in Python and TypeScript.
- Sandbox run guidance for evaluating server behaviour, logs, and hidden tool calls before production rollout.
- Central gateway and control-plane features for governing approved MCP servers, agents, and skills at scale.
👉 Read Obot's analysis of how to vet MCP servers for production trust →
MCP server vetting: are your controls keeping up in production?
Explore further
27/08/2026 2:12 pm
MCP server vetting is really NHI governance, not just software hygiene. A third-party MCP server carries credentials, tool permissions, and downstream API trust into production, so the identity problem starts the moment the server is allowed to act on behalf of an AI client. The organisation is governing a non-human identity with delegated authority, not merely approving code. The practical conclusion is that MCP servers need entitlement review, secret review, and lifecycle review together.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which is why exposed connectors often behave like overbroad identities rather than governed services.
A question worth separating out:
Q: How should teams govern MCP server installation in developer environments?
A: Treat MCP server installation as a controlled enrollment step, not a convenience action. If the installer can collect API keys, register tools, or establish persistent session authority, then approval, logging, and ownership need to happen at install time. The key control is deciding who can add trusted tools before they become part of daily developer workflow.
👉 Read our full editorial: MCP server vetting exposes the governance gap in AI access
