Topic starter
02/08/2026 11:31 am
TL;DR: MCP is quickly becoming the integration layer between AI agents and enterprise systems, but Cyberhaven says most security teams lack visibility, logging, and scope control over those connections. The core problem is not just exposure, it is that runtime agent decisions break assumptions built into traditional IAM and data governance.
Editorial analysis by NHI Mgmt Group, based on content published by Cyberhaven: “MCP Security: How to Secure MCP Integrations”.
Key questions
Q: What breaks when AI agents use MCP without strong scope enforcement?
A: Least privilege breaks in practice because the agent can execute far more than the business task requires.
Q: Why do MCP integrations create so much operational risk?
A: They create risk because the protocol connects runtime agent decisions directly to enterprise systems, often through broad tokens, weak logging, and unreviewed server permissions.
Q: What are the warning signs that an MCP deployment is overexposing enterprise tools?
A: Warning signs include overly broad tool discovery, agents reaching adjacent data without a fresh policy check, and responses being reused after user permissions change.
Practitioner guidance
- Establish a complete MCP inventory Record every MCP server, owner, connected system, permission scope, and approval status before any further expansion.
- Constrain every MCP server to minimum tool scope Review each tool and resource exposed to an agent and remove write, delete, export, or broad read access unless the business function truly requires it.
- Move MCP credentials into managed secrets Store API keys and OAuth tokens in a secrets management system, bind them to specific agent identities, and rotate them on a defined schedule.
Bottom line: MCP security is an identity governance problem because AI agents are choosing tools and data sources at runtime, outside the scope of many traditional access reviews.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:46 pm
MCP security is really governance of delegated runtime access, not just API protection. The central failure is that AI agents decide which tools to call after the session starts, so classic pre-approved entitlement models stop describing actual behaviour. That means MCP belongs inside identity governance, secrets governance, and data governance at once. Practitioners need to stop treating it as an integration convenience and start treating it as a governed access plane.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams respond when an MCP session can reach production systems?
A: Treat it as a session-governance problem, not a normal permissions review. Require task-scoped access, runtime policy for dangerous sequences, and correlated logging before deployment. If the session can read source code and trigger production changes, the authorisation boundary is too broad for safe autonomous use.
👉 Read our full editorial: MCP security exposes the governance gap in AI agent access