Notifications
Clear all
Topic starter
05/07/2026 6:49 pm
TL;DR: MCP is pushing AI from isolated inference into connected systems that call tools, data sources, and workflows at runtime, expanding the attack surface and reducing visibility, according to HiddenLayer. The security problem is no longer just model safety; it is governing dynamic AI-to-tool behaviour that existing controls were not designed to inspect or contain.
NHIMG editorial — based on content published by HiddenLayer: research on MCP and the shift from models to systems
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern MCP-connected AI systems?
A: Security teams should govern MCP-connected AI systems as runtime identity environments, not just integration layers.
Q: Why does MCP create more risk than a normal API integration?
A: MCP creates more risk because the model can combine tools, data sources, and workflows during execution rather than following a fixed request path.
Q: What do security teams get wrong about AI tool access?
A: Teams often assume that approving an AI tool or server is the same as controlling how it will be used.
Practitioner guidance
- Inventory every MCP trust relationship Map each model, server, tool, and downstream API into a single access graph so you can see where authority enters and where it can spread.
- Scope tool permissions to the smallest executable boundary Separate read, write, and action privileges for connected AI systems, and do not rely on broad connector-level approval.
- Add runtime telemetry to AI sessions Log tool calls, chained actions, and sensitive data movement at session level so you can reconstruct behaviour after the fact.
What's in the full report
HiddenLayer's full research covers the operational detail this post intentionally leaves for the source:
- The article’s deeper breakdown of runtime-centric visibility and how it differs from protocol-only monitoring.
- HiddenLayer’s descriptions of behavioral detection, adaptive policy enforcement, and continuous validation across AI workflows.
- The examples of MCP traffic visibility and agentic endpoint protection as emerging control patterns.
- The vendor’s framing of how AI Runtime Security is intended to sit between models, agents, and tools at execution time.
👉 Read HiddenLayer's research on MCP and the shift to AI systems →
MCP and AI systems: what it means for IAM teams?
Explore further
05/07/2026 7:09 pm
MCP is a runtime identity problem before it is a protocol problem. The industry keeps describing MCP as an interoperability layer, but the governance issue is that interoperability now carries identity and authority into live execution. That means the control plane is not just the model or the API gateway, but the trust relationship that allows a system to act across tools, data, and workflows. Practitioners should read MCP as a new category of machine access to govern, not as a simple integration pattern.
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.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which means most environments still rely on broad trust rather than task-scoped control.
A question worth separating out:
Q: How do organisations reduce the blast radius of connected AI systems?
A: Organisations reduce blast radius by scoping each tool to the narrowest possible task, separating read and write privileges, and retiring trust as soon as the business need ends. They should also tie each MCP component to a named owner and a review cadence so access does not persist by default.
👉 Read our full editorial: MCP and AI system shift expands runtime identity risk
