1 min lesson
Vetting third-party MCP integrations
Answer this: "You connect a new MCP server. It exposes a tool whose name and description closely mirror a trusted internal tool the agent already uses, and the agent starts calling the new one. What happened, and which controls catch it?"
Step 1 of 2
Vetting third-party MCP integrationstreat every server like an untrusted dependency
The right analogy is supply-chain security. An MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server is a dependency that runs with your agent's reach, so apply the same rigor you'd apply to a package you're about to import.
- Vet and pin the server - known publisher, reviewed behavior, pinned version, no silent updates that change what its tools do.
- Sandbox and least-privilege it - the server's tools get only the capabilities that integration needs and its outputs are treated as untrusted content, not trusted instruction.
- Bound the egress - what the model is allowed to pass into a server's tool call is constrained, so it can't quietly hand over secrets or whole files.
- Label provenance - content that came from an external MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server is marked as untrusted in context so downstream controls can clamp on it.