---
title: "Execution and Trust Boundaries"
type: synthesis
tags: [ssh, remote, security, isolation, execution-state]
created: 2026-09-09
updated: 2026-09-09
sources: ["raw/github_doc-docs-reference-ssh-execution-boundary-md.md", "raw/github_doc-docs-reference-agent-skill-sharing-threat-model-md.md", "raw/web_community-ways-to-run-orca-orca-docs.md", "raw/web_community-ssh-worktrees-orca-docs.md", "raw/web_community-remote-orca-servers-orca-docs.md", "raw/web_community-browser-use-profiles-orca-docs.md"]
confidence: medium
---

# Execution and Trust Boundaries

Orca runs agents across four places — the local desktop, SSH targets, Remote
Orca Servers, and cloud VMs — and the interesting questions are not about
features but about **where work actually executes, what the UI is entitled to
claim about it, and which boundaries are isolation rather than security**. Those
answers are scattered across a user docs site and an internal reference; this
page puts them together.

## The rule that governs remote work

The SSH execution boundary reference states it directly:

> **The execution host owns everything that touches execution** — tools,
> credentials, identity, environment, processes, and artifacts. The client owns
> the UI, transport, and Orca control-plane state, but is not authoritative for
> execution state.

It draws two consequences it calls non-negotiable:

1. **No silent substitution.** "An operation on a remote `repoPath` must never
   fall back to running on the client. A missing SSH provider is not permission
   to answer locally — a local run can answer for the _wrong repository_."
2. **No asserting what you cannot observe.** "Loss of contact is not evidence of
   `exited`. Report `unverifiable`, never `exited`."

**Analysis:** these two rules are why a disconnected remote session shows an
ambiguous state rather than a clean "stopped". That is the system being honest,
not a bug — and an agent reading Orca's state should treat it that way.

## The three-value vocabulary, and why it must not be collapsed

The reference fixes the vocabulary as **`live` / `unverifiable` / `exited`** and
says: "Do not introduce synonyms, and never collapse `unverifiable` into either
neighbour. `exited` requires positive evidence of absence from the host that
owns the process; a transport failure can only ever produce `unverifiable`."

| Verdict | What it means | What it does **not** mean |
|---|---|---|
| `live` | the owning host confirms the process is running | — |
| `unverifiable` | contact was lost; nothing can be concluded | not "probably dead" |
| `exited` | positive evidence of absence, from the owning host | never inferred from a dropped connection |

**Analysis:** the practical failure this prevents is a retry storm or a
duplicate run started because a network blip was read as termination. Anything
automating on top of Orca should branch on all three states, not two.

## Isolation is not the same as security

Three separate boundaries appear across these sources, and they are different
in kind:

- **Worktrees** isolate *work* — each agent gets its own checkout so parallel
  agents do not collide in one working tree. Nothing in these sources presents a
  worktree as a security or permission boundary between agents.
- **The execution host** is the real authority boundary: credentials, tools and
  identity belong to whichever host runs the work, which is why a remote
  operation must never silently answer locally.
- **Shared skills carry code.** The skill-sharing threat model is blunt: "A
  skill is code from its author." It also records that a private share is
  *unlisted*, not access-controlled — "an unpredictable active share ID is a
  bearer credential" — and that "V1 is not end-to-end encrypted from Orca Cloud
  operators."

**Analysis:** an unlisted share link is a secret in the same sense a password
is; anyone holding it can resolve the share. That is a deliberate V1 design
recorded in a document which states of itself that it "does not constitute
security approval". Treat installing a shared skill as running someone else's
code, because that is what the threat model says it is.

## Where to draw your own line

Synthesised from the pages above rather than prescribed by any of them:

1. **Decide what the execution host is before you decide anything else.** It
   determines which credentials and tools are in play; nothing about the UI
   changes that.
2. **Do not let automation treat `unverifiable` as terminal.** Reconnect and
   ask the owning host; the vocabulary exists precisely so you can wait.
3. **Vet a skill's author the way you would vet a dependency**, and treat share
   IDs as secrets rather than as URLs to paste around.
4. **Keep browser profiles in mind as a separate credential surface** — profiles
   hold real logins, and browser automation acting on them is acting as you.

## Related

- [ways to run](../concepts/ways-to-run.md)
- [SSH worktrees](../concepts/ssh-worktrees.md)
- [remote servers](../concepts/remote-servers.md)
- [skills and MCP](../concepts/skills-and-mcp.md)
- [worktrees](../concepts/worktrees.md)

## Sources

- `raw/github_doc-docs-reference-ssh-execution-boundary-md.md`
- `raw/github_doc-docs-reference-agent-skill-sharing-threat-model-md.md`
- `raw/web_community-ways-to-run-orca-orca-docs.md`
- `raw/web_community-ssh-worktrees-orca-docs.md`
- `raw/web_community-remote-orca-servers-orca-docs.md`
- `raw/web_community-browser-use-profiles-orca-docs.md`