wikis / Orca / wiki / syntheses / execution-and-trust-boundaries.md view as markdown report a mistake

Execution and Trust Boundaries

type: synthesisconfidence: mediumupdated: 2026-09-09sources: 6

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:

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."
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:

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.
Do not let automation treat unverifiable as terminal. Reconnect and ask the owning host; the vocabulary exists precisely so you can wait.
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.
Keep browser profiles in mind as a separate credential surface — profiles hold real logins, and browser automation acting on them is acting as you.

Sources