> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.7-remote-access-dispatch-and-ssh.md). # 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* {% hint style="info" %} Remote triggers can drive local tools and files. Review them like privileged access, not like notifications. {% endhint %} ## 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 * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## 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 * [Remote connections (Codex)](https://developers.openai.com/codex/remote-connections) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Workspace Agents](https://developers.openai.com/workspace-agents) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## 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 | Governance page | Relationship to this article | | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- | | 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 * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy.md) * [3.3 Network egress control](/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control.md) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity.md) * [3.8 File and filesystem access controls](/handbook/3.-runtime-sandbox-and-autonomy/3.8-file-and-filesystem-access-controls.md) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.7-remote-access-dispatch-and-ssh.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.