Remote ops · cross-org

Bring in outside help without opening your network.

When a vendor, contractor, or remote teammate — or their agent — needs to debug your closed environment, you shouldn't have to paste logs into a pastebin or punch a VPN hole. OpenScope lets you delegate a narrowed slice of your own actions over an outbound-only tunnel: they run the verbs you sanctioned, as you, for a few minutes, through a relay that can't read a thing.

The problem

Today, cross-org debugging means Shadow IT.

External agents and contractors can't reach your internal network, so to unblock the work, teams fall back on two high-risk habits — and both trade safety for speed.

The static data leak

To give an outside agent context, developers paste raw logs, schemas, and stack traces — with tokens and keys baked in — into Gists and pastebins. Sensitive data sits at rest on the public web, indexed and cached.

The ambient shell leak

To allow live work, IT provisions a temporary VPN or SSH credential that pierces the perimeter. The outsider — or their agent — inherits a full shell and broad, ambient authority: cat, rm -rf, lateral movement.

Slow and dangerous

Both paths need a firewall change or an approval, and neither is scoped to the task at hand. The fast way to unblock the work is also the dangerous one.

How it works

One command, an outbound tunnel, a blind relay.

You delegate a subset of your own verbs. Your daemon dials out to a relay it doesn't trust; the recipient connects from outside and gets exactly the actions you sanctioned — nothing else, and not a byte of raw access.

Whiteboard sketch contrasting insecure cross-org debugging — pasted logs and a VPN shell — with the OpenScope remote-ops flow over an outbound tunnel to a blind reflector
Conceptual overview · insecure cross-org debugging vs. the OpenScope remote-ops flow
Step 1

Open a session

openscope share open delegates a narrowed slice of your own surface — specific verbs, with parameters pinned to the task.

Step 2

The daemon dials out

It opens an outbound-only connection to the relay. No inbound ports, no firewall changes, nothing exposed at your network edge.

Step 3

The recipient connects

They run openscope-reflect-client with the handle, confirm your daemon fingerprint out of band, and see only the sanctioned verbs.

Step 4

Runs as you, then tears down

Each call executes under your identity and policy, every one logged. The session self-destructs at the TTL — 30 minutes, hard cap.

Capability passport

A passport only narrows what you already have.

It is an ephemeral, signed delegation — a strict subset of your existing, root-owned grant. It can remove verbs and pin parameters; it can never widen your authority. That's the structural guarantee that makes handing it to an outsider safe.

Narrowed by construction

A passport is derived from your live capability surface, then attenuated: pin parameters (service=web), drop every verb you didn't name. It can only remove from what you already hold — never add.

Run as you

Every reflected call executes under your principal, through the same default-deny policy chokepoint. The authority lives in the daemon's session, not in the bytes the recipient holds — even a buggy passport can't exceed your standing grant.

Bound to a recipient

The session is sealed to the recipient's registered key (--to <alias>), so only they can connect. Need an out-of-band handoff instead? --bearer issues an unbound handle you convey yourself.

The bounds

What the outsider can't do — and what the relay can't see.

The capability surface is the only thing exposed. Everything underneath it stays out of reach, and the relay in the middle is blind by design.

  • No shell. They call named verbs — ssh.tail_logs, restart_service — never a terminal. There is no raw command path to reach for.
  • No ingress. The tunnel is outbound from your network. There is no open port, and no firewall change, for anyone to reach in through.
  • No raw files or secrets. The agent is structurally blinded from cat, grep, and key material — data-loss prevention by construction, not by a scanner trying to catch every pattern.
  • No lateral movement. The session rides an encapsulated pipe straight to the daemon. The outsider never sits on your subnet and can't discover neighboring services.
The blind relay

The relay is a blind byte-pump. It pairs the two legs by an unguessable rendezvous id and forwards opaque, end-to-end-encrypted frames between them. It never holds the channel keys, so it can't read — or archive — what flows through. Frames live in memory and are dropped as they're delivered, so there's nothing at rest on third-party infrastructure.

Your daemon authenticates to it with a deployment token; the recipient authenticates by possessing the handle and a secret sealed to their own key. Self-host the relay, or point at a hosted one — either way it sees only ciphertext.

Quick start

Delegate a scoped session.

You issue the session from inside the closed network; the recipient connects from anywhere with the handle you hand them.

You, inside the network
openscope share open \
  --agent you \
  --verb ssh.tail_logs:service=web \
  --verb ssh.restart_service:service=web \
  --to vendor-b --ttl 30m

# share list / share extend / share revoke manage live sessions
The recipient, outside
openscope-reflect-client --passport <handle>

Replace the pastebin and the VPN hole with one scoped session.

If your team brings in outside help to debug closed environments, OpenScope gives them the exact actions they need — run as you, logged, and gone in 30 minutes — without ever exposing a shell or your network.

How does an outside engineer touch your prod today, and who would know?