Agent-initiated AI relay channels expose a new identity risk

At a glance

What this is: Panther found an npm package that connected local AI CLI tools to an operator-controlled relay, turning a convenience wrapper into a persistent remote-control path with plaintext credential exposure.

Why it matters: IAM and security teams need to treat agent relays as identity and execution boundaries, because they can expose secrets, expand tool access, and bypass normal oversight across NHI and emerging autonomous workflows.

By the numbers:

• The platform showed 3 connected agents and 336.2k accumulated tokens of relayed AI compute at the time of capture.
• The package iterated across four versions in roughly 33 hours.

👉 Read Panther's analysis of Lend Me Your Claude: The Cost of Borrowed AI Compute

Context

The primary identity issue here is not just malware detection, but who can control an AI execution path once a local CLI is connected to a remote operator. In identity terms, the package turns a developer workstation into a non-human identity relay, with the operator able to send prompts, read outputs, and inherit environment variables that often contain secrets.

For NHI and agentic AI programmes, the important question is whether a tool is only orchestrating prompts or is actually granting remote execution authority. That distinction matters because a relay that can enumerate local tools, pass through process.env, and persist its connection behaves more like an identity bridge than a normal productivity extension. The evidence in this case points to a governance gap that many teams are not modelling explicitly.

Key questions

Q: What breaks when a local AI CLI is remotely steered through a relay package?

A: The normal user-to-tool relationship breaks, because the operator can inject prompts, read outputs, and persist the connection outside the user's direct control. At that point, the package is no longer just a convenience layer. It is a delegated execution path that needs the same scrutiny as any other privileged non-human identity.

Q: Why do AI coding environments create more secret exposure risk than standard developer tools?

A: They can inspect repository context, read dotfiles, and infer where credentials are stored, then act on that information through commands or file changes. That means secrets can be exposed both by reading them and by persisting changes that keep access alive. Teams should assume workstation-local state is part of the secret attack surface.

Q: What do teams get wrong about securing AI tool connectors?

A: Teams often assume that authentication alone is enough, but authenticated access can still be too broad or too fast for safe governance. The common failure is allowing AI systems to inherit the same trust as a human operator without adding limits on rate, data class, connector provenance, and downstream action authority.

Q: Who is accountable when an AI relay package exposes prompts or credentials?

A: Accountability sits with the team that approved the tooling, the environment owner that allowed sensitive secrets to be present, and the operator that controlled the relay if it was outside the intended trust boundary. Governance frameworks should assign responsibility before the tool is installed, not after data is exposed.

Technical breakdown

How remote AI relay channels turn local CLIs into controllable execution paths

The package establishes a persistent WebSocket channel between the local machine and an operator-controlled server. On connection, it sends an account key, discovers installed AI CLIs, and then relays prompts into those tools through child-process execution. That architecture matters because the operator is not merely requesting a service from the client. The operator is steering a local execution surface that can invoke commands, return output, and maintain state across reconnects. In identity terms, the relay creates a delegated execution path with very weak user visibility.

Practical implication: Treat any remote AI relay that can drive local CLI execution as a privileged execution boundary, not a harmless integration.

Why process environment inheritance is the real secret exposure issue

When a child process inherits the user's full environment, anything stored in process.env becomes reachable to the executed command. That includes cloud credentials, API keys, and service tokens that are often assumed to be local-only. The technical problem is not limited to the relay itself. It is the combination of remote prompting plus inherited execution context. Even if the operator never explicitly asks for secrets, the environment is already present at execution time, so the boundary between prompt handling and credential access disappears.

Practical implication: Assume any remotely steered CLI with inherited environment access can reach secrets unless the execution context is explicitly constrained.

Why self-healing persistence changes the governance model

The package re-establishes the connection every few seconds and stores a state file so the same logical identity survives restarts. That means the operator relationship is not a one-time interaction but a durable enrollment. For identity governance, durability is the important feature. A connection that can survive process drops, reconnect automatically, and preserve identity on disk behaves like an unmanaged service relationship with no standard offboarding point. This is where conventional software inventory falls short, because the identity persists after the initial install moment.

Practical implication: Track persistent AI relay identities as governed entities with explicit enrollment and offboarding rather than as temporary tooling sessions.

Threat narrative

Attacker objective: The operator aims to monetise or control borrowed AI compute while gaining access to the user's prompts, transcripts, and any secrets available in the local execution context.

1. Entry occurred when a user was instructed to run a single npx command that enrolled the local machine into the operator's relay service.
2. Credential access followed when the package transmitted the account key over an unencrypted WebSocket and inherited the full process environment for downstream execution.
3. Escalation occurred when the operator could relay arbitrary prompts into local AI CLIs, maintain a self-healing channel, and preserve the same logical identity across restarts.
4. Impact was the operator's ability to control local AI tooling, observe transcripts, and potentially reach API keys and cloud credentials exposed in the execution environment.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Borrowed AI compute becomes an identity problem the moment the operator can steer local execution. This case is not just about suspicious package behaviour. It shows that the real control boundary sits between prompt delegation and command execution, and that boundary is often invisible in developer tooling. Once the operator can relay tasks into local CLIs, the identity model has already shifted from user-owned tooling to externally governed execution.

Full environment inheritance is a standing credential exposure window, not a minor implementation detail. The package's use of child_process with inherited process.env means secrets can travel into remotely steered commands without a separate exfiltration step. That is a governance failure because the execution context was never isolated from the identity context. The practical conclusion is that secret exposure is built into the trust model whenever remote prompting and inherited environments are combined.

Persistent agent relays create unmanaged non-human identities that survive beyond the installation moment. The self-healing WebSocket and state file make the connection durable, which means the operator relationship behaves like an enrolled service identity without lifecycle controls. That should force teams to rethink where identity inventory starts and ends, because a package can create a long-lived operational identity even when no formal provisioning event exists.

Runtime prompt injection through operator-controlled group memory creates an upstream governance gap. The package allows silent context to be prepended to every prompt, which means the operator can alter task intent without user visibility. That is not ordinary automation. It is a delegated instruction channel whose authorization state is opaque to the person running the CLI, and practitioners should treat that as a trust-boundary violation.

Identity blast radius expands when AI tools are enrolled through informal installer flows rather than governed access policy. The combination of account key enrollment, remote prompt relay, and CLI inventory disclosure creates a broad attack surface across the developer workstation, the AI toolchain, and any linked secrets. The implication for NHI governance is clear: identity control has to start before the prompt is accepted and continue after the process is running.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap is why teams should also review the Ultimate Guide to NHIs for lifecycle, rotation, and offboarding controls.

What this signals

Operator-controlled AI relays should now be treated as governed identities, not just packaging choices. The practical issue is whether a tool can persist, reconnect, and steer local execution without a human review point. In environments where AI tooling already touches secrets, the control question is how quickly a suspicious connector can be identified and removed before it becomes a standing access path.

Identity blast radius is the better planning lens than simple malware detection. A package can evade static scanning and still create a durable execution channel that reaches prompts, transcripts, and environment variables. Teams that already use NIST SP 800-53 Rev 5 Security and Privacy Controls should map these pathways to access control, auditability, and system integrity requirements rather than relying only on code-scan verdicts.

The next governance step is to separate experimentation from credential-bearing environments. When AI tooling can inherit production secrets, the issue is not whether the package looks malicious at first glance, but whether the surrounding workspace is safe enough for an externally steered process to exist at all.

For practitioners

• Inventory every remote AI relay path Identify packages and wrappers that connect local AI CLIs to external servers, then classify them as governed execution channels rather than ordinary developer tools. Flag any solution that enumerates installed agents or maintains a persistent operator connection.
• Isolate AI CLI execution from inherited environments Run remote-steered AI tooling in constrained contexts where process.env does not expose production API keys, cloud credentials, or service tokens. If isolation is not possible, block the tool from environments that contain sensitive secrets.
• Require explicit enrollment and offboarding for agent relays Maintain an owner, purpose, and removal process for every AI relay or connector that can persist state on disk or reconnect automatically. Remove it through process termination, package uninstallation, and state-file cleanup when the relationship ends.
• Detect plaintext WebSocket control channels in AI tooling Monitor for ws:// connections used by AI-related packages, especially when the traffic carries account keys, prompt content, or task output. Treat unencrypted control channels as exposure points for both credential theft and prompt interception.

Key takeaways

• Remote AI relay packages turn local CLIs into externally governed execution paths, which changes the identity risk from tooling convenience to access control.
• Plaintext control channels, inherited environments, and persistent reconnect logic together create a durable path to prompts, transcripts, and secrets.
• Teams should govern AI connectors as lifecycle-managed identities with explicit enrollment, containment, and offboarding requirements.

Key terms

• Agent Relay: An agent relay is a software path that forwards prompts or commands between a local AI tool and a remote operator. In identity terms, it becomes sensitive when the relay can steer execution, carry secrets, or persist beyond a single task session.
• Execution boundary: The point at which an authorised task turns into a real system change, such as writing data, deleting records, spending money, or invoking a downstream tool. In AI governance, controlling the execution boundary matters more than simply approving access, because harm occurs when actions are allowed to complete unchecked.
• Standing access path: A standing access path is a persistent way into a system that remains usable without a fresh authorisation event. For non-human identities, it often appears as a service credential, admin channel, or embedded secret that survives long after the original operational need has changed.

What's in the full article

Panther's full blog post covers the operational detail this post intentionally leaves for the source:

• Version-by-version package timeline showing when the remote-control logic appeared and how it changed over four releases
• Live indicators from the operator control panel, including connected agents and accumulated relayed compute
• Technical behavior of the WebSocket channel, including the account key flow and the self-healing reconnect logic
• Observed implementation details around execFile inheritance, state-file persistence, and local CLI enumeration

👉 Panther's full post covers the package behavior, operator control flow, and detection evidence in detail.

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 identity controls across human, machine, and AI-driven environments, it is worth exploring.