Remote access

Remote access is the question of how a person outside the building reaches the systems inside it. Control determines what data may move during that access.

A regulated organization may keep data and code inside a perimeter while staff and consultants work remotely. A remote workspace can satisfy both requirements by running the work inside that boundary.

Keep the workspace with the data

The traditional answer is a VPN: put the laptop on the network and let it fetch what it needs. The endpoint receives repository clones, data extracts, and cached model output. The perimeter now includes a device in an airport.

A workspace inside the boundary runs development tools and agents next to the data. Only the rendered session crosses the network, and the laptop does not receive a local copy of the files.

This design prevents automatic file synchronization to the endpoint. A lost laptop can be handled by revoking its session. Contractors can receive a workspace grant, and offboarding can remove that workspace without relying on deletion of local clones. The remote session still has to be responsive enough for daily work.

Session controls

Once the workspace is inside, the session becomes the main access boundary. Set clipboard and file-transfer permissions by role. An engineer may need to paste material into a session without receiving bulk copy-out access.

Restrict outbound access from the workspace to the destinations required for the work. The same restriction applies to agents running there. See runtime.

Scope session recording to a defined need. Recording privileged or third-party sessions can support review, while recording every employee keystroke creates a broader workforce monitoring issue. Document the purpose and tell affected users.

Set idle and absolute timeouts so an abandoned workspace does not remain an active credential inside the boundary.

Workspace usability

People will copy repositories to local machines when the remote path is materially worse than local work. The sanctioned workspace therefore needs to support normal engineering tasks:

• Support the editors and terminal environments people already use.
• Run agent tooling near the data so long-running execution, filesystem access, and credentials stay inside the boundary.
• Place workspaces near users when data-location requirements allow it.
• Preserve sessions when a device disconnects.

An SSH endpoint and VPN alone do not show that code remains off employee laptops.

Consultants and contractors

Shared credentials for consultants remove individual attribution. Federate each consultant through the employer's identity provider, map the identity to a role scoped to the engagement, and expire the grant on the statement of work date. Give each person a separate identity and a workspace with limited application access. Do not grant broad network access.

The access record should identify the consultant, the records opened on a given day, and the date the grant ended.

Crossing a border

A laptop may be inspected or imaged at a border, and it may be seized. Keeping code and data in the remote workspace limits what the device holds and allows the organization to revoke the session remotely.

A person's location may also change what they are allowed to access. Define which roles are location-sensitive and what the system does when access originates from an unexpected jurisdiction. Decide these rules before travel begins.

Cross-border data governance

Processing location is a placement decision enforced by the runtime and routing layer. A request tagged for one region must use a model and workspace approved for that region.

Authorization should take the person's current location into account alongside their role. The access log and trace provide the record for review. See compliance.

Sovereignty claims also need evidence that workloads remain in the required placement. See portability.