Notifications
Clear all
Topic starter
09/07/2026 12:03 pm
TL;DR: MCP servers expand AI agent access to files, commands, APIs, and workflows, yet most are deployed from public sources without formal vetting, creating hidden supply-chain and privilege risks, according to Knostic. The governing problem is not just unsafe code, but a trust model that approves elevated runtime access before legitimacy, scope, and behavior are verified.
NHIMG editorial — based on content published by Knostic: What This Blog Post on MCP Server Security Vetting Covers
By the numbers:
- 35% of breaches involved data from unmanaged sources.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: What breaks when MCP servers are not vetted before use?
A: When MCP servers are not vetted, the enterprise loses control over privileged tool access inside AI workflows.
Q: Why do MCP servers increase identity and access risk in AI environments?
A: MCP servers increase risk because they act like high-privilege non-human identities inside the development stack.
Q: How do security teams know if an MCP server is behaving outside its approved scope?
A: They should compare observed file access, shell execution, and outbound calls against the server’s declared capability map.
Practitioner guidance
- Classify MCP servers as privileged identities Assign ownership, approval authority, and revocation criteria for each server before it reaches an agent or IDE.
- Vet source integrity and dependency chains Check repository ownership, commit history, maintainer patterns, package provenance, and any hidden execution paths in transitive dependencies.
- Enforce least-privilege capability maps Document the exact files, commands, APIs, and network paths each server may touch, then compare observed behavior against that map.
What's in the full article
Knostic's full blog covers the operational detail this post intentionally leaves for the source:
- Repository vetting steps for MCP servers, including source integrity checks and maintainer verification
- Permission and capability review guidance for file, shell, and API access in development environments
- Runtime monitoring examples for configuration drift, behavioral anomalies, and privilege expansion
- Inventory and guardrail patterns for keeping approved MCP servers from spreading unchecked
👉 Read Knostic's MCP server security vetting guidance →
MCP server security vetting: what IAM and AppSec teams need?
Explore further
09/07/2026 12:04 pm
MCP vetting is now an AI supply-chain control, not a developer preference. Once an MCP server can read files, execute commands, and call external tools, it sits inside the trust boundary for AI operations. That means approval decisions must join AppSec, IAM, and platform governance instead of living only in a developer workflow. The practical conclusion is that MCP servers need the same scrutiny applied to other privileged non-human identities.
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.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: Who should own approval for MCP servers in an enterprise?
A: MCP server approval should sit with a shared control group that includes AppSec, IAM, and platform ownership, not with developers alone. The reason is simple: these servers combine software provenance, privilege scope, and runtime behavior. A single team rarely sees all three risk dimensions well enough to govern them safely.
👉 Read our full editorial: MCP server vetting is now a core AI supply-chain control
