# 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.

Source: https://brocs.fyi/control/remote-access/
Part of the surface: C · Control. Keep a hand on the wheel.
Framework: BROCS (Build, Run, Observe, Control, Secure), brocs.fyi. CC BY 4.0, attribute to brocs.fyi.

---

## The Control surface

- Configuration: declarative, versioned, reviewed, reversible
- Ingress: one front door for internal AI apps
- Identity: SSO by default, external access without VPN sprawl
- Storage and backups: retention, lifecycle, restore drills
- Routing: model and provider routing, pinning, failover
- Remote access: work reaches the data instead of the data reaching the laptop


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](/run/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](/build/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.


### How zero trust thinks about this

The zero trust position is that network location grants nothing, and every request is
authenticated and authorized on its own. A VPN is the purest violation of that idea: it
converts an authentication event into a network position that then implies authorization
for everything reachable. Identity-aware access to individual applications and workspaces
is the same idea applied to remote work, and it is why "are they on the VPN" stops being
a meaningful question.


## 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](/control/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](/observe/traces/). That is also
precisely what a regulator asks for, so the same work serves both purposes. See
[compliance](/secure/compliance/).

Sovereignty is the same argument at platform scale: it is demonstrable or it is
marketing. See [portability](/run/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?