MCP and AI system shift expands runtime identity risk

At a glance

What this is: This analysis explains how MCP and connected AI systems expand the runtime attack surface by linking models, tools, and workflows.

Why it matters: It matters because IAM, NHI, and AI governance teams now have to control runtime access and observability for systems that can act outside static policy assumptions.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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.

👉 Read HiddenLayer's research on MCP and the shift to AI systems

Context

MCP changes AI from a bounded model interaction into a connected runtime where models can call tools, query data, and move information across workflows. That shift matters for MCP and AI system governance because the trust boundary is no longer the prompt alone; it is the identity, permission, and observation model behind every tool call.

Existing IAM and NHI controls struggle here because they were designed for explicit entitlements and reviewable access, not for dynamic model-led action chains. Once AI systems can select tools and act during execution, security teams need visibility into who or what authorised the connection, what it can reach, and how much of the runtime remains outside monitoring boundaries.

Key questions

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. That means defining who owns each model-to-tool trust relationship, limiting the permissions behind every connector, and monitoring actual session behaviour. If the system can call tools dynamically, governance must cover execution, not only configuration.

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. That expands the blast radius of a single trust decision and makes traditional access review less effective. The core issue is runtime authority, not simple connectivity.

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. In reality, the dangerous part is the session itself, where the system can chain actions, move data, or misuse inherited privileges. Control must follow behaviour, not just registration.

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.

Technical breakdown

MCP extends identity from the model to the tool chain

Model Context Protocol is a connectivity layer that lets an AI system reach external tools and data sources through structured integrations. In practice, that means the security boundary shifts from the model endpoint to the full chain of connected services, credentials, and execution paths. The protocol itself is not the risk. The risk comes from the fact that the model can now operate across multiple systems with privileges inherited from the surrounding environment rather than from a single, reviewable request. In identity terms, MCP turns integration points into active trust relationships that must be governed like machine access, not like static application configuration.

Practical implication: treat each MCP connection as an identity-bearing integration and map the permissions behind every tool it can invoke.

Why runtime observability is the real control gap

Runtime observability means seeing what an AI system actually does while it is executing, not just what integrations were configured beforehand. That matters because tool chaining, data movement, and prompt-influenced behaviour can all happen inside a session that leaves little trace in traditional IAM logs. When AI systems act dynamically, configuration review alone cannot prove safe use. The control problem becomes one of execution visibility, anomaly detection, and policy enforcement at the moment of action. Without that layer, teams may know a tool is connected but still miss how the system used it, what data it touched, or whether it deviated from expected patterns.

Practical implication: add session-level telemetry and behavioural detection to the controls that already govern connected AI systems.

Supply chain risk now includes MCP servers and tools

MCP ecosystems often rely on open-source or third-party servers, plugins, and tool wrappers. That makes the trust model look less like a single app deployment and more like a software supply chain with live credentials and runtime authority. If a server, connector, or tool package is tampered with, the model may inherit malicious behaviour through a trusted path. This is why identity and supply chain governance now intersect for AI systems: the question is not only whether the component is approved, but whether the runtime trust relationship can be validated continuously.

Practical implication: require provenance, integrity checks, and lifecycle ownership for every MCP server and connected tool.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI integration into a covert execution path for data theft, manipulation, or unauthorized action.

1. entry via a compromised or impersonated MCP server or tool integration that the AI system trusts at connection time.
2. credential access or abuse occurs when the connected runtime inherits permissions that let the model reach APIs, files, or workflows beyond the original intent.
3. impact follows when unsafe tool chaining, data exfiltration, or manipulated outputs occur inside sessions that security teams cannot fully observe.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Runtime visibility is the missing premise in most AI control models. HiddenLayer’s analysis reinforces what NHI governance has already exposed in other contexts: static configuration does not tell you how a non-human system behaves once it is connected. If the runtime can chain actions, move data, and select tools dynamically, then pre-approval alone cannot establish safe use. The implication is that identity programmes must treat execution evidence as a first-class governance object, not a logging afterthought.

Tool trust is now lifecycle trust. When an MCP server, connector, or wrapper remains trusted after its purpose or ownership changes, the environment inherits persistent access paths that are difficult to distinguish from legitimate automation. That is the same pattern identity teams have seen with service accounts and other machine identities, only now the blast radius includes AI-driven action chains. Practitioners should re-evaluate whether every connected tool has an explicit owner, review point, and retirement trigger.

Supply chain thinking must extend into AI identity governance. Open-source and third-party MCP components are not just software dependencies, they are authority dependencies. A compromised connector can change what a model can see, call, or transmit without altering the model itself. For identity architects, that means provenance, approval, and revocation processes need to cover AI tool chains with the same seriousness applied to privileged machine identities.

Identity blast radius is the right named concept for MCP governance. The core issue is not simply that AI systems can connect to more things. It is that each connection can expand the operational consequences of a single compromised identity, tool, or server. Once runtime access spans multiple systems, the cost of weak scoping is no longer confined to one integration. Practitioners should measure how far one MCP trust decision can propagate across the environment.

From our research:

• 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.
• For a broader agentic-risk view, see AI Agents: The New Attack Surface report for how runtime behaviour and access scope intersect.

What this signals

Identity teams should expect MCP to collapse the distinction between integration security and access governance. Once models can trigger actions at runtime, the practical question becomes who owns the trust path, who can revoke it, and who can prove what happened inside a session. The more connected the AI estate becomes, the more identity discipline has to move upstream into design and ownership.

With 80% of organisations already reporting AI agents acting beyond intended scope in NHIMG research, the operational signal is clear: dynamic AI behaviour is no longer an edge case. That figure should push teams to treat connected AI as an access-governed population, not a software feature set.

Identity blast radius: the total operational impact an identity can cause once its permissions propagate across multiple systems and sessions. For MCP programmes, that blast radius grows whenever a connector can be reused, inherited, or chained without fresh validation, which is why review cadence alone will not solve the problem.

For practitioners

• 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. Include owners, approval source, and retirement criteria for each connection.
• 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. If a tool can trigger workflows, treat that as a distinct privilege that needs its own review.
• 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. Pair that telemetry with behavioural baselines that flag unusual sequencing or data access.
• Prove supply chain integrity for MCP components Require provenance checks, signed artifacts, and explicit lifecycle ownership for every server, plugin, or wrapper that can influence a model’s runtime actions. Reassess trust whenever a component changes maintainer, source, or scope.

Key takeaways

• MCP turns AI integrations into live identity relationships, so the governance problem is authority at runtime rather than configuration at build time.
• The practical risk is not limited visibility, hard-coded credentials, and weak tool scoping together create a control gap that traditional IAM cannot close on its own.
• Practitioners should govern MCP with the same discipline used for privileged machine access, including ownership, scoping, telemetry, and retirement.

Key terms

• Model Context Protocol: A protocol that lets an AI system connect to external tools, data sources, and workflows through structured interfaces. In governance terms, it expands the identity surface because the model can inherit authority from connected services during runtime, which turns integration design into an access-control problem.
• Runtime observability: The ability to see what an AI system actually does while it is executing, including tool calls, data movement, and action chaining. For identity teams, this is the evidence layer that shows whether a connected system stayed inside its intended authority boundary or drifted beyond it.
• Identity blast radius: The total operational damage an identity can cause once its permissions are propagated across multiple systems, tools, or sessions. In AI environments, the blast radius grows when one trust decision can unlock several downstream actions without fresh validation or revocation.
• Tool scoping: The practice of limiting exactly which actions a connected system can perform through a tool, rather than granting broad connector-level access. It is the control that keeps an AI integration task-bound, auditable, and easier to revoke when the business need changes.

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.

👉 HiddenLayer's full research covers runtime visibility, adaptive policy enforcement, and emerging MCP control patterns.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.