3.7 Remote access, dispatch and SSH
Mobile-to-desktop bridges, remote dispatch, and SSH can let remote triggers drive local tools and files, expanding the attack surface.
Last reviewed: August 18, 2026
Remote access, dispatch and SSH: what security teams need to know
Remote access features let work start from a phone, browser, cloud queue, or SSH session and continue on another machine. That can help developers, but it also creates an access chain that spans identities and devices.
The risk is inherited context. A remote trigger may reuse local credentials, project trust, paired devices, or workspace settings that the remote user does not see in full.
Common remote access, dispatch and SSH security failures
A stale paired device can trigger work on a managed laptop.
SSH sessions run with broad filesystem and credential access.
A mobile dispatch starts a task in the wrong project context.
Remote runs bypass the approval expectations of local sessions.
Logs show local execution but not the remote trigger source.
Remote access, dispatch and SSH security controls checklist
Inventory remote-trigger paths, including mobile, browser, SSH, CI, and cloud queues.
Require device review and stale pairing cleanup.
Log trigger source, target device, project, user, and credential context.
Restrict remote runs that can reach production systems.
Require stronger approval for remote writes and credential access.
Anthropic
Overview
For Claude Code, the remote-access question is mostly a credential question. Credential precedence runs through cloud provider credentials, bearer token, API key, apiKeyHelper, OAuth token, and subscription OAuth credentials, so a dispatched or CI-triggered session inherits whichever of those resolves on the target machine, an inheritance the remote user never sees. Cloud execution is the cleaner remote path: isolated VMs with scoped credentials, configurable network controls, and audit logging.
Managed settings can pin configuration on managed machines so a remote trigger cannot arrive into a looser policy than an interactive session would get. Cowork is now a separate remote path: sessions run on Anthropic's servers and can be steered from web, desktop, or mobile, but they reach local folders, browsers, and apps only through an online Claude Desktop host and its existing permissions. Managed Agents move the whole environment into Anthropic-managed or self-hosted sandboxes.
Anthropic documentation
Applicable Harmonic guides for Anthropic
OpenAI
Overview
Codex remote connections are the concrete SSH surface in the ChatGPT desktop app. The app discovers hosts from ~/.ssh/config, requires Codex installed and authenticated on the remote host, and starts the remote app server over SSH. A remote project thread then runs commands, reads files, and writes changes on the remote host's filesystem and shell, so the remote machine's sandbox and approval posture is what contains it. Use SSH port forwarding with localhost listeners and never expose an unauthenticated app-server listener to shared or public networks.
Beyond SSH, Codex cloud dispatch and the app's local, worktree, and cloud modes are remote-trigger paths with different inheritance, and Workspace Agents let external systems trigger published ChatGPT agents using access tokens that are distinct from platform and Compliance API credentials; inventory those tokens as non-human identities (see 1.5). Managed configuration keeps remote-reachable machines from drifting to permissive defaults.
OpenAI documentation
Applicable Harmonic guides for OpenAI
Frequently asked questions about remote access, dispatch and SSH
What is remote dispatch for AI agents?
It is starting or steering agent work from a different device or context than where the work executes: phone to desktop, browser to cloud queue, laptop to an SSH host. The security property that matters is inheritance, because the run executes with the target environment's credentials, project trust, and settings, which the person triggering it may never see.
Why is SSH risky for AI agents?
An SSH session typically carries privileged shell and file access, and an agent operating through it inherits that full reach; Codex remote connections, for example, run commands and write files on the remote host's filesystem. The remote host's sandbox and approval settings become the effective policy, so a hardened laptop dispatching to a permissive server gets the server's posture. Follow the vendor guidance: port-forward over SSH with localhost listeners and never expose an unauthenticated agent listener to a shared network.
What are stale paired devices?
They are device or host entries that still permit remote triggering after the user, device, or role has changed: an old laptop in a device list, or a forgotten host in ~/.ssh/config that a remote-connection feature rediscovers. Where the product has a connections screen, such as Codex hosts under Settings > Connections, make reviewing and disabling entries part of access review.
What should remote access logs include?
The trigger source (device, surface, user), target machine, project context, credential type that authenticated the run, command class, approvals granted, and outcome. The pairing of trigger source with target matters most, because local execution logs alone make remote-triggered work look like the machine owner's own activity.
Should remote writes be blocked?
Block by default for hosts that can reach production systems or sensitive data, and allow only reviewed workflows with a named owner and logging. A useful floor: remote-triggered sessions should never run under a weaker approval policy than an interactive session on the same machine, enforced with managed configuration rather than convention.
Applicable regulations and frameworks
G.1 Map your controls to NIST AI RMF and CSF 2.0
This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.
G.3 DORA and AI resilience in financial services
Conditional: for a DORA-regulated workflow, this supports ICT containment, resilience, continuity, and recovery.
G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.
Related handbook guidance
Was this helpful?