Topic starter
02/08/2026 11:31 am
TL;DR: AI agents using Model Context Protocol are forcing identity governance into runtime decisions, according to Cyberhaven. Broad permissions, weak logging, and unmanaged credentials make these integrations hard to see and harder to contain once they are live.
Editorial analysis by NHI Mgmt Group, based on content published by Cyberhaven: “MCP Security: How to Secure MCP Integrations”.
Key questions
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.
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.
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.
Glossary terms: Model Context Protocol, Tool Poisoning, Indirect Prompt Injection, Governance Gap
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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 governance needs runtime controls, not static access reviews
This post was modified 2 days ago by NHI Mgmt Group