MCP and ShadowMQ expose new runtime risks for AI agent security

At a glance

What this is: ShadowMQ and MCP together show how AI agent security now depends on runtime visibility into tool connections, deserialization paths, and inherited privileges.

Why it matters: For IAM, PAM, and NHI practitioners, the lesson is that agent access must be governed as a live identity problem, not just a software protection issue.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read AppSOC's analysis of ShadowMQ, MCP, and AI agent runtime risk

Context

AI agent security now extends beyond model behaviour into the runtime paths that connect agents to tools, data sources, and execution environments. When inference frameworks expose unsafe deserialization or protocol-level trust assumptions, the result is not just a software bug but a control failure that can hand attackers code execution, data access, or privilege inheritance. That makes MCP governance and agent identity controls part of the same security conversation.

The article’s core concern is that traditional AppSec tools were designed for web traffic, static code, and known request patterns, while agentic systems communicate through dynamic protocols and opaque payloads. For identity and access teams, the important intersection is that an agent’s tool permissions, inherited privileges, and data reach now need lifecycle governance in the same way service accounts and workloads do.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What breaks when MCP servers are not vetted before use?

A: When MCP servers are not vetted, the enterprise loses control over privileged tool access inside AI workflows. A server can read files, call APIs, run commands, or mutate workflows before anyone confirms it is legitimate or minimally scoped. That creates a supply-chain path to secret exposure, workflow manipulation, and lateral movement through trusted automation.

Q: How can organisations reduce blast radius when an AI tool is compromised?

A: Limit the tool's scope, separate high-risk functions from general collaboration data, and make revocation fast enough to matter. Pair least privilege with short-lived tokens, clear ownership, and logging that links the agent, the user, and the downstream system. Containment only works when those paths are visible.

Technical breakdown

Unsafe deserialization in AI inference frameworks

Unsafe deserialization happens when software reconstructs objects from attacker-influenced serialized data without strong validation. In AI inference stacks, that often appears in fast interprocess channels such as ZeroMQ, where developers trade safety for performance and convenience. If a server blindly unpacks pickle objects, malicious payloads can execute code in the worker process. The security problem is not limited to one framework. It reflects a broader pattern in AI infrastructure where privileged runtime components trust internal traffic too much.

Practical implication: treat serialized object handling as an attack surface and block unauthenticated internal channels before they reach production.

Model Context Protocol as a trust bridge for AI agents

Model Context Protocol is becoming the connective layer that lets AI agents reach repositories, databases, tickets, and chat systems. That convenience creates a trust bridge: once an IDE or agent trusts an MCP server, the server can inherit that trust and act with the agent’s permissions. If the MCP endpoint is rogue, compromised, or overbroad, the attacker does not need to break the model itself. They only need to control the tool layer that the model is allowed to call.

Practical implication: inventory every MCP connection and apply explicit allowlists, authentication, and per-tool scope limits.

Why traditional AppSec tools miss agent runtime abuse

SAST, DAST, and WAF controls are useful for known code paths and web requests, but agentic systems behave dynamically and may create new execution paths at runtime. A coding assistant opening a socket, launching a shell, or moving data through a context channel can look normal unless the security stack understands expected agent behaviour. That is why runtime protection, behavioural detection, and supply-chain checks now matter together. The control challenge is no longer just vulnerability management. It is ongoing governance of machine-operated actions.

Practical implication: pair code scanning with runtime policy enforcement so agent actions are monitored after deployment, not only before release.

Threat narrative

Attacker objective: The attacker wants to turn trusted AI tooling into a silent path for code execution, credential theft, and enterprise data exfiltration.

1. Entry occurs when attackers exploit exposed AI infrastructure or register a rogue local MCP server that an IDE implicitly trusts.
2. Escalation follows when malicious serialized payloads or trusted tool connections let the attacker execute code, inherit agent privileges, or bypass normal browser and app controls.
3. Impact is credential theft, data exfiltration, and compromise of developer workflows or enterprise systems through the agent runtime.

NHI Mgmt Group analysis

AI agent security is now a runtime identity problem, not just a model safety problem. The article shows that the dangerous boundary sits where agents inherit trust from tools, servers, and IDE integrations. That means governance has to cover identity, privilege, and tool scope together, not as separate controls. Practitioners should treat every agent as a governed runtime principal.

Shadow trust in MCP is the named concept security teams need to watch. It describes the hidden assumption that a connected tool is safe because it sits inside the developer workflow. In practice, that assumption collapses when a rogue or compromised MCP server can inherit agent permissions and move data invisibly. The control gap is not visibility alone. It is the lack of explicit trust validation for machine-to-machine delegation. Practitioners should enforce verified tool identity before any agent connection is allowed.

AI supply chain risk now includes the tool layer, not only the model layer. Developers increasingly install MCP servers, inference components, and agent frameworks from public sources, which means compromise can enter through package trust rather than prompt content. This broadens the security perimeter to include dependency hygiene, runtime policy, and lifecycle approval for agent plugins. Practitioners should assess agent supply chains the same way they assess software supply chains.

Least privilege for agents has become an operational control, not an architecture slogan. When an agent can query repositories, databases, and collaboration systems, its permissions define the blast radius of any compromise. Static permissions are too blunt for dynamic tasks, but unfettered access is equally unsafe. The practical answer is granular, task-scoped delegation with revocation tied to the end of the workflow. Practitioners should align agent privilege with job scope and session duration.

Traditional AppSec coverage is necessary but incomplete for agentic systems. Vulnerability scanning still matters, but it does not tell you whether an agent is using a safe tool path at runtime or whether a hidden connection is being abused. The field needs a layered model that combines detection, policy, and access governance. Practitioners should use the article as a signal to extend control ownership beyond AppSec into IAM and NHI governance.

What this signals

Shadow trust: security teams should expect AI toolchains to expand faster than their current review processes can absorb. The practical response is to treat agent integrations like privileged access paths, with ownership, approval, and revocation tied to the same governance model used for high-risk service accounts.

Runtime visibility will become a baseline requirement for AI programmes that connect agents to repositories, data stores, or collaboration systems. The article’s message is that static review is no longer enough when the dangerous behaviour happens after deployment and inside trusted workflows.

The strongest control posture will combine dependency checks, agent policy enforcement, and identity governance for machine-operated actions. That is especially relevant where an agent can act across code, data, and admin systems in a single session.

For practitioners

• Inventory every agent tool connection Map all MCP servers, inference endpoints, and agent integrations, then flag any unknown or unsanctioned connection before it can inherit production access.
• Apply explicit allowlists to agent tools Require authenticated, approved tool endpoints for each agent and block default trust in local or public MCP servers that have not passed review.
• Restrict agent permissions to task scope Use granular permissions so an agent can only reach the repositories, databases, and collaboration systems needed for the active task, then revoke access at workflow completion.
• Add runtime detection for abnormal agent behaviour Alert when an assistant opens network sockets, spawns shells, or moves data outside expected context-gathering patterns, because those actions indicate runtime abuse.
• Scan the AI supply chain before deployment Check inference frameworks, agent plugins, and MCP packages for known vulnerabilities and unsafe configuration before they reach CI/CD release gates.

Key takeaways

• ShadowMQ and MCP expose a governance gap where trusted AI runtime paths can be turned into code execution and credential theft.
• The scale of AI agent adoption is rising faster than policy, visibility, and audit controls in many environments.
• Practitioners should extend IAM, PAM, and NHI governance into tool identity, runtime policy, and agent supply-chain review.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Unsafe Deserialization: Unsafe deserialization happens when software reconstructs objects from untrusted data in a way that can trigger code execution or state corruption. In practice, the risk is not the file or message itself, but the fact that the parser is allowed to invoke behaviour while rebuilding the object.
• Tool Trust Inheritance: Tool trust inheritance is the tendency for an AI agent to extend trust from an approved interface to whatever tool or server sits behind it. That assumption becomes dangerous when a rogue integration can inherit permissions, move data, or execute actions that the original controller never intended.
• Shadow Trust: Shadow trust is an implicit trust relationship in an AI workflow that is not clearly documented, reviewed, or enforced. It often appears when an agent relies on a local plugin, public server, or internal protocol endpoint that security teams have not formally approved.

What's in the full article

AppSOC's full article covers the operational detail this post intentionally leaves for the source:

• Specific walkthrough of the ShadowMQ exploitation chain across ZeroMQ, pickle deserialization, and AI inference components
• Examples of how a rogue MCP server can inherit trust inside IDE workflows and expose credentials
• The vendor's runtime defence approach for blocking abnormal agent actions such as shell spawning and unauthorized socket use
• Implementation detail on policy enforcement for least-privilege agent tools and supply-chain scanning

👉 AppSOC's full post covers the exploitation chain, runtime defence details, and agent tool policy controls.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, workload identity, and secrets management. It helps practitioners connect access control, lifecycle governance, and runtime privilege decisions across modern identity programmes.