Agent-initiated AI relay channels expose a new identity risk

At a glance

What this is: This is Panther's analysis of an npm package that turns local AI CLI access into a persistent operator-controlled relay channel, with plaintext account-key transfer and environment inheritance as the key risks.

Why it matters: It matters because borrowed compute can blur the line between a convenience wrapper and an identity boundary, exposing secrets, transcripts, and control paths that IAM and AI governance teams may not be watching.

Context

Borrowed AI compute is what happens when a local machine runs an externally controlled AI workflow that can relay prompts, outputs, and context between the user and a remote operator. In this case, the security problem is not simply that an npm package exists, but that it creates a persistent control path into local AI CLIs and treats that path as routine software plumbing.

For IAM and NHI programmes, the issue is boundary definition. The package moves account keys, prompt content, and execution context across a remote channel while also inheriting the local process environment, which means credential exposure and command delegation appear together. That combination turns a simple connector into an identity-governance problem.

The article leaves open whether the activity is covert malware or an aggressive gray-market proxy, but the operational risk is the same. If software can relay instructions into a local AI runtime and collect responses with no clear trust boundary, then the programme needs to classify that relay as a governed identity path rather than a benign integration.

Key questions

Q: What breaks when local AI tools are linked to a remote operator relay?

A: The boundary between a local assistant and a controlled execution path breaks down. Once prompts, outputs, and account binding flow through an operator-managed relay, the tool is no longer isolated to the user's environment. That creates a governance problem around delegation, credential exposure, and visibility into who can shape the session.

Q: Why do borrowed AI compute channels increase identity risk?

A: They increase risk because the channel binds a local runtime to a remote controller while often carrying authentication material, prompts, and outputs across the same path. That collapses the separation between access, execution, and data handling. The result is a broader blast radius than a normal plugin or integration.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: Should organisations treat local AI CLI connectors like privileged access?

A: Yes, when the connector can relay prompts, control command execution, or inherit sensitive environment variables. At that point it is performing delegated access into an execution context, not just passing data. Governance should reflect the same caution used for other high-trust access paths.

Technical breakdown

How the relay channel turns local AI CLI access into remote control

The package establishes a WebSocket channel between the user's machine and an operator-controlled service, then uses that channel to pass prompts into locally installed AI CLIs and stream the results back. Because the operator can drive the prompt flow, the local CLI is no longer acting as a closed user-side assistant. It becomes a delegated execution surface whose behaviour is shaped by remote instructions. The technical risk is not just network transport. It is the combination of persistent connectivity, server-driven prompt injection, and bidirectional response handling through a single control plane.

Practical implication: treat any remote prompt relay into local AI tooling as a delegated execution path that requires explicit governance and monitoring.

Why plaintext account-key transfer matters in borrowed compute flows

The accountKey is transmitted over an unencrypted ws:// connection, which means the identifier and associated session traffic are exposed to interception on the network path. In identity terms, that key functions as the enrollment and correlation token tying a local machine to the operator's platform. Once that token is visible, the channel can be replayed, observed, or abused depending on the surrounding implementation. The issue is not abstract confidentiality. It is that the identifier establishing control over the AI relay is moved in cleartext before any meaningful assurance boundary exists.

Practical implication: require encrypted transport and token handling discipline before any software is allowed to bind local AI tooling to a remote control plane.

Why full process environment inheritance expands the blast radius

The connector invokes local commands through child processes that inherit the user's full process.env, which means any secrets already present in the environment can be reachable by the relayed commands. That matters because AI CLI workloads often coexist with cloud credentials, API keys, and other operational secrets on the same host. When the relay channel can influence command execution, environment inheritance becomes a privilege expansion mechanism rather than a convenience detail. The technical failure is not only access to the CLI. It is access to the surrounding execution context that the CLI can observe and use.

Practical implication: isolate AI runtime execution from sensitive environment variables before allowing any remote-controlled workflow to touch local processes.

Threat narrative

Attacker objective: The apparent objective is durable operator control over borrowed AI compute and the data exposed through that compute path, including prompts, transcripts, and environment-held secrets.

1. Entry occurs when the user installs the npm package and links a local AI CLI through the accountKey enrollment flow.
2. Credential exposure follows when the package sends the accountKey to the operator over plaintext WebSocket traffic and discloses which local CLIs are installed.
3. Escalation happens when the operator can feed prompts into local commands through execFile while the child process inherits the full process environment.
4. Impact is the operator's ability to relay instructions, observe responses, and potentially reach secrets or transcripts tied to the local AI session.

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.
• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.

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

Borrowed compute becomes an identity boundary the moment remote instruction can shape local AI execution. This package is not just a connector, because it turns local AI CLI use into an operator-governed relay path with persistent reach into the host. That means the trust decision sits at the boundary between local runtime, remote control, and the credentials already present on the machine. Practitioners should stop treating borrowed compute as a convenience layer and start treating it as governed identity infrastructure.

Access review assumptions fail when the control path is built around sessions, not durable accounts. The accountKey in this pattern is used to bind a machine to a remote platform, but the real privilege is the ability to steer local execution and observe outputs in real time. Access review processes were designed for stable entitlements that can be certified after the fact. When the actor is a relay channel that can self-heal and persist across restarts, the governance question shifts from review to issuance and containment.

Credential exposure here is not a side effect, it is the operating model. The package inherits the full environment of the child process, so secrets sitting in developer shells become available to whatever the operator can prompt through the relay. That creates a new class of identity risk where the privileged object is not the AI model, but the execution envelope around it. Identity teams need to recognise this as a borrowed-compute blast-radius problem, not a conventional software installation issue.

Persistent self-healing channels create what we call borrowed compute trust debt. The connection re-establishes itself every few seconds and preserves state across restarts, which means the user may believe they have a temporary tool link while the operator holds a durable control path. That design makes governance harder because the visible session and the effective authority are not the same thing. The implication is that AI agent governance must account for hidden persistence, not just interactive use.

OWASP-NHI and Zero Trust thinking both apply, but neither is sufficient if the operator can silently shape the runtime. The core problem is delegated execution without a stable trust boundary, which means environment inheritance, prompt relay, and transcript visibility all become part of the identity model. This is exactly where NHI programme design has to expand beyond secret hygiene into runtime delegation governance. Practitioners should treat the relay itself as the subject of control.

What this signals

Borrowed compute should be classified as a governed identity path, not a convenience integration. When local AI tooling can be driven by a remote operator and can inherit the user's execution context, the real control point moves from the model to the relay. That is where access, credential exposure, and session persistence need to be designed and monitored as one problem.

Borrowed compute trust debt: persistent remote channels into local AI runtimes create hidden authority that survives beyond the visible session. The practical signal for practitioners is that offboarding, token handling, and environment isolation have to be designed for delegation paths that can reconnect and re-register themselves.

AI CLI relay channels expose a new boundary for Zero Trust thinking. Zero Trust is not only about verifying users and devices at the edge, but also about verifying whether a local tool should be allowed to receive remote instructions at all. If the runtime can be steered and observed externally, the boundary has already shifted.

For practitioners

• Inventory remote AI relays Identify npm packages, browser extensions, and local tooling that create operator-controlled channels into AI CLIs or agent runtimes, then classify them as identity-bearing integrations rather than ordinary utilities.
• Block plaintext enrollment channels Require encrypted transport and authenticated session binding for any workflow that passes account keys, tokens, or relay identifiers between local tools and remote platforms.
• Separate AI runtime from sensitive env vars Run AI CLI workloads in constrained shells or containers that do not inherit cloud credentials, API keys, or other high-value environment variables by default.
• Treat self-healing relays as persistent access Review any channel that automatically reconnects or preserves identity across restarts as durable access, then define offboarding that includes process termination and state removal.
• Monitor prompt relay and transcript leakage Add detection for outbound prompt forwarding, operator-controlled command invocation, and transcript exfiltration from local AI sessions that are supposed to remain user-side.

Key takeaways

• Borrowed AI compute becomes an identity issue when a remote operator can steer local execution and observe responses through a persistent relay channel.
• The strongest evidence in this case is the combination of plaintext account-key transfer, remote prompt relay, and full process-environment inheritance.
• Practitioners should govern AI relay channels as privileged delegated access paths, not as low-risk productivity add-ons.

Key terms

• Borrowed Compute: Borrowed compute is local or hosted execution capacity that is temporarily directed by another party or platform. In identity terms, the important question is who can steer the workload, what data the runtime can see, and whether the control path is governed as delegated access rather than simple software use.
• Relay Channel: A relay channel is a control path that forwards prompts, commands, or data between a local runtime and a remote operator. For AI tools, it becomes security-relevant when the channel can persist, rebind after restart, or carry credentials and transcripts across trust boundaries.
• Execution Envelope: An execution envelope is the surrounding runtime context that a process inherits when it runs, including environment variables, filesystem access, and inherited permissions. In this article's context, the envelope matters because AI CLI delegation can expose secrets that were never intended for the remote operator.
• Session Binding: A control that ties an authenticated session to the device, connection, or risk context that created it. When applied well, it makes stolen cookies harder to reuse from an untrusted endpoint or a different network context.

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.