Developer data protection
Locate Remote SSH and container controls
Map where the files, extensions, terminal tools and model requests actually run before reusing an AI security result from a local workspace. A local editor window can operate on a remote host or inside a container. Controls applied to the laptop, remote filesystem and container are different boundaries, and their coverage must be verified for the selected client and task.
For Engineering platform and endpoint IT
Locate the data, process and control together.
Synthetic location markers and unexecuted checks. No SSH connection or container is created.01
Start with the location of each component
Record the user interface, repository, workspace extensions, terminal process and model-request path separately. An editor being visible on a managed laptop does not show where its commands execute or which filesystem they can read. Use non-secret location labels and responsible owners in the worksheet.
Visual Studio Code’s Remote SSH documentation provides a concrete example: it can operate directly on a remote filesystem and run commands and extensions on the remote machine without source code being present locally. Other coding clients and extensions need their own current documentation and observations.
Source context: Visual Studio Code: Remote SSH
02
Review the container boundary as well as the host
VS Code documents that development-container workspaces may be mounted, copied or cloned into the container, and that extensions can run there with access to its tools and filesystem. A container may itself run on a remote SSH host. Record these layers instead of treating “in a container” as a complete security description.
Identify which files are mounted, which credentials the runtime can access and who administers the host and container. This guide does not require changing mounts or opening new remote access. The exercise can use already approved isolated environments with only the supplied synthetic markers.
Source context: Visual Studio Code: Developing inside a container · Visual Studio Code: Remote SSH
03
Place the intended control on the correct path
For each operation, identify where an access rule is enforced and where a submission could be observed. A local filesystem restriction is not evidence of a restriction on a remote host. A browser prompt test does not establish control of an extension or terminal executing elsewhere.
GitHub’s content-exclusion documentation identifies remote-filesystem and symlink limitations. Cursor practitioners have also asked configuration-specific questions about dev-container and sandbox interactions. Use these as reasons to record the exact editor, mode and location, not as proof that every remote workflow is uncontrolled.
| Component | Location to record | Control question |
|---|---|---|
| Editor interface | Local device or browser | Which account and client are in use? |
| Repository | Local, remote or container filesystem | Which identity can read the files? |
| Tool/extension process | Actual execution host | Which permissions and network path apply? |
| Model request | Actual originating component | Which supported data policy can evaluate it? |
Source context: GitHub: Copilot content exclusion · Cursor community: dev-container sandbox question
04
Use location-labelled synthetic observations
The pack contains different markers for local, remote and container fixture locations. If a reviewer is authorised to use existing isolated environments, place the intended marker in each approved location and record which one the selected tool returns. Do not copy real repositories, private keys or credentials into the exercise.
A result should name the component and location tested, not just say “the agent read it.” Record whether the operation was unavailable, denied, prompted or returned a marker. Keep the expected boundary separate from observation, and do not relax a restriction to make every location accessible.
05
Approve the actual execution arrangement
The approval should describe the permitted client, repository location, host/container arrangement and task. Assign responsibility for each boundary. If the runtime or repository moves, revisit the affected rows rather than assuming the same controls follow the window.
Remote development and vendor-hosted cloud agents are different patterns. Use the cloud-access guide when a provider creates a hosted checkout. This page covers the locality of Remote SSH and container-based work and does not imply that Aona governs every remote process from a laptop installation.
Put it into practice
Remote development location and control map
Locate the editor, repository and tool process before interpreting an AI control result.
Synthetic location markers and unexecuted checks. No SSH connection or container is created.
Local interface
The editor appears on the employee’s device
This alone does not locate execution
Remote host or container
Workspace files and tools may be located here
Verify identity, mounts and permissions
Model request
Trace the component that submits context
Evaluate the supported path separately
| Location | Synthetic marker | Observed component |
|---|---|---|
| Local test folder | SYNTHETIC_D19_LOCAL | Untested |
| Approved remote fixture | SYNTHETIC_D19_REMOTE | Untested |
| Approved container fixture | SYNTHETIC_D19_CONTAINER | Untested |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
README.mdInspect
# Remote development locality review
This pack contains only synthetic marker text and a worksheet. It creates no SSH connection, container, mount, credential or network request.
Use existing organisation-approved isolated locations only. Place the appropriate marker file in each permitted fixture location, then record which component and location an authorised manual test actually used. Do not copy real repositories or private keys. If a location is unavailable or not approved, mark it NOT APPLICABLE.
An editor window, a file path and a running process are separate observations. Record all three before interpreting a control result.
## Guide and sources
Canonical guide: https://aona.ai/resources/guides/ai-coding-remote-ssh-devcontainers/
Source review: 2026-09-21
- Visual Studio Code: Remote SSH: https://code.visualstudio.com/docs/remote/ssh
- Visual Studio Code: Developing inside a container: https://code.visualstudio.com/docs/devcontainers/containers
- GitHub: Copilot content exclusion: https://docs.github.com/en/copilot/concepts/context/content-exclusion
- Cursor community: dev-container sandbox question: https://forum.cursor.com/t/clarification-request-how-does-cursorignore-interact-with-auto-run-in-sandbox-inside-a-dev-container/159139
local-marker.txtInspect
SYNTHETIC_D19_LOCAL
remote-marker.txtInspect
SYNTHETIC_D19_REMOTE
container-marker.txtInspect
SYNTHETIC_D19_CONTAINER
location-matrix.csvInspect
client_version,component,data_location,execution_location,identity_or_owner,expected_control,observed_marker_or_decision,evidence
RECORD,editor interface,RECORD,RECORD,ASSIGN,DEFINE,UNTESTED,
RECORD,repository read,RECORD,RECORD,ASSIGN,DEFINE,UNTESTED,
RECORD,terminal tool,RECORD,RECORD,ASSIGN,DEFINE,UNTESTED,
RECORD,workspace extension,RECORD,RECORD,ASSIGN,DEFINE,UNTESTED,
RECORD,model request,RECORD,RECORD,ASSIGN,DEFINE,UNTESTED,
approval.mdInspect
# Execution arrangement decision
Client/version and mode: ____________________
Local interface/device owner: ____________________
Repository location: ____________________
Remote host/container owner: ____________________
Tool execution and request path: ____________________
Supported controls and evidence: ____________________
Unresolved location/control question: ____________________
Decision: NOT YET REVIEWED
Recheck when host, mount, client, mode or repository location changes.
Before you proceed
Keep these distinctions clear
- Using the editor window as location evidence
- Locate the actual filesystem and process, particularly with Remote SSH and nested containers.
- Assuming a laptop endpoint governs every remote process
- Review installation and supported control placement for the actual execution and submission path.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate supported employee endpoint prompt and file paths where its client is installed and the route is supported.
No uniform Remote SSH, container, remote-filesystem or vendor-cloud enforcement is implied. A local installation is not proof of control over a remote runtime.
Bring the location map and an approved synthetic operation to a scoped deployment/coverage review.
Review your use caseFAQ
Questions for this decision
If the editor runs on my laptop, do its tools run there too?
Does a dev container automatically provide the intended AI data boundary?
Can we reuse a local Copilot exclusion result on a remote filesystem?
Do these files create a test server or container?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- Visual Studio Code: Remote SSH
Documents remote filesystem access and execution, including remote containers.
vendor · checked 2026-09-21 - Visual Studio Code: Developing inside a container
Documents mounted/copied workspaces and extensions running inside containers.
vendor · checked 2026-09-21 - GitHub: Copilot content exclusion
Identifies remote-filesystem and symlink limitations.
vendor · checked 2026-09-21 - Cursor community: dev-container sandbox question
A dated practitioner question motivating location/mode-specific review, not a current universal flaw.
practitioner · checked 2026-09-21