High-risk domains in agent skills create hidden control gaps

At a glance

What this is: This analysis shows how agent skills, MCP servers and plugins can embed high-risk domains that quietly drive malware delivery, miner installation and data leakage.

Why it matters: It matters because identity teams now have to govern external dependencies inside agent workflows, not just credentials and prompts, if they want to prevent trust from collapsing at execution time.

By the numbers:

• The article says 121 agent components still use a high-risk domain for real.
• Finance skills make up 43% of the skills that use a high-risk domain, against 6% of all skills.

Context

Agentic ecosystems fail when a workflow treats an external URL as trusted just because it appears inside a skill, MCP configuration or plugin manifest. The real governance gap is dependency trust, not only identity trust, because the component can still fetch code, send telemetry or persist execution through a domain that has already become malicious.

In this case, the security question is whether the runtime environment can distinguish a legitimate dependency from a poisoned one before an agent executes it. That matters for non-human identity governance because the agent is often acting through credentials and network access that were never meant to be delegated to an unknown third party.

The article's examples show that the same pattern can hide inside documentation, installers and updates, which makes static review alone insufficient. MCP security guide helps frame why tool and endpoint trust must be evaluated together.

Key questions

Q: What breaks when an agent skill trusts a domain that later becomes malicious?

A: The trust model breaks because the agent executes a live dependency, not a static reference. If the domain can change ownership, payload or reputation after publication, the workflow can turn safe-looking instructions into code download, telemetry leakage or persistence without any change to the prompt. Governance has to follow the dependency, not just the agent.

Q: Why do high-risk domains in MCP and skill workflows create more than malware risk?

A: They create an access governance problem because the domain can control what code runs, what data leaves the host and whether the session leaves behind persistent state. That means the control failure sits at the trust boundary between the agent and the external endpoint, not only in the malware that arrives.

Q: How should security teams detect risky agent dependencies before they execute?

A: Use pre-execution checks against threat feeds, protective DNS and blocklists, then review the installer's actual network destinations and persistence behaviour. If a component contacts a raw IP, a recently registered host or a known malicious domain, it should fail closed before the agent runs it.

Q: What should teams do first when an agent workflow has already loaded a suspicious skill?

A: Contain the host state first. Check for installed services, scheduled persistence, unusual outbound connections and any machine identifiers already exposed, then revoke the workflow dependency and remove the component from approved use. That sequence matters because the risk may continue after the original session ends.

Technical breakdown

How agent instructions become a trust boundary

In these ecosystems, a skill or plugin is not just content. It is an instruction set that can tell an agent to install packages, call endpoints, or start background processes. That makes the URL inside the component part of the access path, because the agent will often execute it without human inspection once the workflow starts. The risk is not limited to code execution. A malicious or repurposed domain can also collect machine metadata, persist a service, or redirect traffic through infrastructure that security tools have not classified yet. That is why URL reputation must be treated as an identity-adjacent control, not a simple network filter.

Practical implication: Treat every external domain in an agent workflow as a governed dependency that must be approved before execution.

Why background services change the containment problem

A miner or stealer that installs itself as a service shifts the problem from one execution event to persistent runtime exposure. Once a background unit is created, the component can continue to contact infrastructure after the original agent session ends, which means containment must include host-level state, not just prompt review or session termination. The article also shows that plain HTTP and direct IP connections can bypass DNS-based controls, so a blocked domain name does not guarantee blocked traffic. For practitioners, persistence is the key technical distinction because it outlives the agent action that created it.

Practical implication: Inspect for persistence mechanisms such as LaunchAgents and systemd user units whenever an agent runs untrusted installation steps.

Why reputation checks need to happen before the agent runs

The article's method shows why post-execution hunting is too late. If a domain is already known to threat feeds, malware filters or resolver blocklists, the control has to stop the workflow before the agent reads the instruction, not after telemetry shows the connection. This is especially important in MCP and skill ecosystems, where a URL can be a live dependency, a placeholder, or an attacker-owned host depending on when it was registered and what it serves. The technical lesson is that trust is temporal, not static. A domain that was acceptable last week may be hostile today.

Practical implication: Gate agent execution on preflight domain reputation checks and revalidate approved endpoints on a schedule.

Threat narrative

Attacker objective: The objective is to turn the agent's execution environment into a persistent, revenue-generating or controllable host while leaking machine identifiers to attacker infrastructure.

1. Entry occurs when an agent loads a skill or plugin that embeds a domain-controlled installer or update URL.
2. Credential or host data is exposed when the component sends machine metadata such as hostname and MAC address to external infrastructure.
3. Escalation and persistence happen when the installer creates a background service or repeated execution path on the host.
4. Impact is continued command-and-control contact, miner activity, and exposure of the workstation underneath the agent.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• JetBrains Marketplace AI Plugin Campaign: 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Domain trust has become an identity control, not just a network control: In agent ecosystems, the URL inside a skill or plugin can determine what code runs, what data leaves the host and whether persistence is created. That means the security boundary is no longer the prompt alone. It is the dependency graph attached to the agent's execution path, and that boundary has to be governed before runtime, not investigated afterward.

The named concept here is dependency trust debt: teams accumulate risk every time an agent relies on an external domain whose reputation, ownership or payload can change without notice. The article shows that some domains were malicious from registration, while others became risky later. That makes the assumption of stable trust false, and practitioners should treat every approved domain as a revocable security dependency rather than a permanent allowlist entry.

MCP and skill governance must extend beyond secrets to endpoints: most identity programmes already understand that credentials need lifecycle controls, but agent tools also depend on remote hosts, package registries and download URLs. When those endpoints are poisoned, the agent becomes an execution bridge to infrastructure that was never part of the intended trust model. MCP security guide is the right starting point because the control problem is no longer only authorisation, it is tool and endpoint provenance.

Host compromise under an agent workflow is an identity failure, not just malware execution: when a skill can install a service, collect hardware identifiers and continue calling back after the session, the organisation has granted durable machine access through a delegated workflow. That is a lifecycle failure for the non-human identity underpinning the action, because the risk survives the original approval event and keeps operating until the host state is explicitly examined and removed.

Finance is overrepresented because high-velocity workflows amplify trust shortcuts: the article's distribution suggests that fast-moving, API-heavy, automation-friendly environments are more likely to adopt components whose dependencies are poorly scrutinised. That does not make finance unique, but it does show where governance pressure is highest. Practitioners should treat any workflow that optimises for speed as a candidate for hidden dependency risk, especially when the agent can execute code directly.

From our research library:

• 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.
• Read next: MCP Security Guide

What this signals

Dependency trust debt: agent programmes now accumulate risk in external domains the same way human IAM programmes once accumulated risk in orphaned access. The control objective is no longer only who can authenticate. It is also which third-party endpoints an agent can trust before it executes a line of code or starts a service.

Teams should expect more pressure to govern agent dependencies as a lifecycle problem. That means approvals, revocation and periodic revalidation for domains, installers and update endpoints, especially where a skill can persist beyond the original session and where DNS filtering cannot see the actual destination.

The practical signal is simple: if your agent platform cannot tell you which domains are in play, which ones are blocked and which ones were approved for runtime use, the programme is already behind the risk.

For practitioners

• Audit every external domain in agent workflows Inventory the domains referenced in skills, MCP configs and plugins, then classify them as allowed, unknown or prohibited before any agent executes them.
• Preflight reputation checks before execution Check each referenced domain against protective DNS, threat feeds and malware filters before the component is loaded, not after the agent has connected.
• Block persistence from agent-installed tools Look for LaunchAgents, systemd user units and similar persistence mechanisms whenever a skill or installer changes host state.
• Treat IP-only callbacks as high risk Monitor outbound traffic for direct IP connections because DNS filtering will not stop a component that bypasses named domains.
• Revalidate approved agent dependencies on a schedule Recheck domains that were previously approved because reputation and ownership can change after an agent component has been published.

Key takeaways

• Agent skills and plugins can smuggle in high-risk domains that control code execution, telemetry and persistence.
• The evidence in this article shows that domain reputation and lifecycle governance are now part of identity security for agents and workloads.
• Practitioners should verify dependencies before execution, not after the host has already contacted suspicious infrastructure.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · Threat Modelling AI Agents

Key terms

• Agent Dependency Graph: An agent dependency graph is a structured map of everything an AI agent relies on to function, including models, APIs, databases, sub-agents, and business applications. It gives security teams a way to see both technical connectivity and identity relationships in one view.
• Integration Trust Debt: The accumulated risk created by long-lived, over-scoped, or forgotten SaaS connections that remain active after their original purpose fades. The debt grows when teams treat integration setup as a one-time task instead of a lifecycle-managed identity relationship.
• Persistent Host State: Persistent host state is any service, scheduled task or startup mechanism that keeps running after the original user or agent session ends. For identity teams, it matters because a non-human workflow can leave behind durable access and ongoing network activity that outlives the approved action.
• Pre-execution Reputation Check: A pre-execution reputation check is a control that evaluates a domain or download target before an agent is allowed to use it. It is more effective than post-event detection because it stops execution at the trust boundary, where the agent is about to consume an unverified dependency.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.