TL;DR: MCP standardises how AI agents request tools, files, and APIs, but Knostic says that flexibility also widens exposure to spoofed servers, over-privileged access, prompt injection, and insecure secrets storage. The real issue is that trusted-computing assumptions break when agents can chain actions across shared development environments without tight endpoint verification.
NHIMG editorial — based on content published by Knostic: Fast Facts on MCP Security
By the numbers:
- 84% of professional developers use or plan to use AI tools daily, highlighting the importance of granular permissioning.
- 5.5% exhibited tool-poisoning vulnerabilities, instances where modified or malicious servers altered tool outputs, injected false command responses, or redirected data flows to unauthorized endpoints.
Questions worth separating out
Q: How should security teams govern AI agent access through MCP?
A: Security teams should govern MCP as an identity and privilege boundary, not as a simple integration layer.
Q: Why do MCP-connected agents increase the risk of privilege sprawl?
A: MCP-connected agents increase privilege sprawl because they can chain file, shell, and API actions across shared environments once broad access is granted.
Q: What do security teams get wrong about MCP plugin risk?
A: Teams often treat plugins as if they were ordinary extensions, when in practice they can become trust-bearing execution components.
Practitioner guidance
- Validate every MCP endpoint before trust is granted Require certificate checks, allowlists, and hash validation for servers and plugins before they are loaded into IDEs or agent workflows.
- Scope tool permissions to the smallest workable workspace Assign file, shell, and API access per workspace and per server, then review those scopes whenever extensions or configurations change.
- Isolate agent sessions and reset them after completion Run MCP-connected agents in sandboxes or ephemeral containers so credentials, context, and command history do not persist beyond the task.
What's in the full article
Knostic's full research covers the operational detail this post intentionally leaves for the source:
- A deeper walkthrough of MCP server security failure modes, including spoofed endpoints, prompt injection, and unsafe command execution
- The full benchmark data behind hard-coded credentials, tool-poisoning findings, and configuration exposure patterns
- Practical examples of endpoint validation, plugin scanning, and policy enforcement inside development environments
- Implementation detail on how the Kirin layer adds real-time guardrails within IDE workflows
👉 Read Knostic's analysis of MCP server security risks and control gaps →
MCP tool access security: are your AI agent controls keeping up?
Explore further
MCP security is becoming the control plane for AI agent trust. The protocol standardises how agents request tools and data, so identity decisions now happen at the point of tool exposure rather than only at user authentication. That shifts governance from one-time login checks to continuous validation of endpoints, permissions, and command paths. Practitioners should treat MCP as part of the identity boundary, not just the integration layer.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
- In the same research, 53% of MCP servers expose credentials through hard-coded values in configuration files, which makes secret storage a governance issue rather than a local hygiene problem.
A question worth separating out:
Q: How do you know if MCP security controls are actually working?
A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.
👉 Read our full editorial: MCP security exposes the trust gap in AI agent tool access