C ยท Control

Remote access

Letting people work without the data going with them. Contractors, consultants, cross-border travel, and the alternatives to a VPN and a jump box.

View as Markdown

Remote access is the question of how a person outside the building reaches the systems inside it. It sits in Control because the interesting decision is not connectivity, it is what is allowed to move.

Two requirements arrive together in almost every regulated organization, and they look like a contradiction:

Our data and our code never leave the perimeter.

Our engineers, our analysts, and our consultants all work remotely.

They are only contradictory if the work happens on the endpoint.

Move the workspace, not the data

The traditional answer is a VPN: put the laptop on the network and let it fetch what it needs. That makes the endpoint a copy of everything it touches. The repository is cloned, the extract is downloaded, the model output is cached, and the perimeter now includes a device in an airport.

The alternative is to invert it. The workspace runs inside the boundary. The editor, the terminal, the notebook, and the agent execute there, next to the data. What crosses the wire is a rendered session. The laptop becomes a viewport.

That inversion changes several answers at once:

  • “Does data leave?” becomes an architectural fact rather than a policy people have to remember. Nothing syncs because nothing is synced.
  • A lost or stolen laptop is a revoked session, not an incident with a disclosure timeline.
  • Onboarding a contractor is granting a workspace, not shipping a machine and waiting.
  • Offboarding is deleting the workspace, which is verifiable, rather than trusting that someone deleted their local clone.

It is not free. The session has to be responsive enough that people choose it, which is the whole game and is covered below.

The controls that actually matter

Once the workspace is inside, the boundary moves to the session itself. Four settings do most of the work:

Clipboard and file transfer. The most common exfiltration path is copy and paste. Decide per role, not globally: an engineer probably needs paste in, and rarely needs bulk copy out.

Egress from the workspace. A workspace with unrestricted outbound access can push data anywhere, and so can an agent running inside it. Allow-list the destinations that the work actually needs. See runtime.

Session recording, deliberately scoped. Recording every keystroke of every employee is a surveillance decision with its own consequences. Recording privileged sessions, or third-party sessions, is a normal control. Decide which you mean, write down why, and tell people.

Idle and absolute timeouts. A workspace left open is a standing credential inside your boundary.

Beyond a jump box

The reason this fails in practice is rarely security. It is that the sanctioned path is worse than working locally, so people route around it, and the way they route around it is copying the repository to the laptop “just for today”.

A remote path is only a control if people actually use it. That sets a usability bar, not a checkbox:

  • The editor people already use, not a browser-based approximation of it.
  • A real terminal, with their shell and their tooling.
  • The agent tooling, running next to the data rather than on the laptop. This one is increasingly the deciding factor: agents want long-running execution, filesystem access, and credentials, all of which you would rather keep inside. See tooling.
  • Latency people stop noticing. Place workspaces near the person, not only near the data, when the data does not require otherwise.
  • Persistence. Close the lid, open it in a hotel, and the session is where you left it.

If the honest answer is “we have SSH and a VPN”, assume the code is on the laptops.

Consultants and contractors

External people are where shared credentials appear, and shared credentials destroy the access record.

The shape that works:

  1. Federate, do not create accounts. The consultant authenticates against their own employer’s identity provider. Your directory never holds them, so there is nothing to forget to delete.
  2. Map to a scoped role at your ingress, narrow to the engagement.
  3. Expire the grant on the statement of work date, not on a review cycle. Time-bound by default is the single highest-value control here.
  4. One identity per human. “The contractor account” is not an answer to “who opened that record”.
  5. Give them a workspace, not a network. Then the question “what did they access” has an answer that does not depend on network forensics.

The test is specific: can you say which named consultant opened which record on a given day, and did their access stop when the engagement did? If either answer is no, you have connectivity rather than oversight.

Crossing a border

Two problems that get conflated, with different answers.

The device problem. A laptop can be inspected, imaged, or seized at a border, and in several jurisdictions without cause. The mitigation is not encryption theatre, it is that the laptop holds nothing: if the workspace lives inside the boundary, an inspected machine yields a browser and a session that can be revoked from the other side of the world.

The access problem. The same person, in a different country, may be subject to different rules about what they may reach. That makes location an input to authorization rather than a property of the network they connected from. Practically: decide which roles are location-sensitive, decide what happens when someone appears from an unexpected jurisdiction, and make the answer something other than an alert nobody reads.

Both are much cheaper to decide before the trip. The version where a policy gets written at an airport is expensive for everyone.

Cross-border data governance

When the person is in one jurisdiction and the data is in another, split the question:

Where is it processed? A placement decision, enforced by the runtime and the routing layer. A request tagged for one region must not be served by a model or a workspace in another. That is a control, not a convention, and it is the difference between residency and a diagram of residency.

Who may reach it? An authorization decision that takes the person’s current location as an input, alongside their role.

What is the record? The access log plus the trace. That is also precisely what a regulator asks for, so the same work serves both purposes. See compliance.

Sovereignty is the same argument at platform scale: it is demonstrable or it is marketing. See portability.

Questions to ask your vendor, or your own team

  • If a laptop were seized at a border tomorrow, what would be on it?
  • Can an engineer do a full day’s work without cloning a repository locally? Would they choose to?
  • Which named consultant accessed what, last Tuesday? Can you answer without asking anyone?
  • When an engagement ends, what removes the access, and is it a date or a review?
  • What can a remote workspace reach on the outbound network?
  • Is the person’s location an input to authorization, or only to a log line?
  • Where is a request tagged for one region actually processed, and what enforces that?