Skip to content
Orcho Docs

Security and privacy

Decision lens

Orcho is local-first in its run state and artifacts, but worker runtimes may still receive prompts, source context, task details, and tool output. Evaluate security by tracing that data flow, not by assuming the word “local” means nothing leaves the machine.

localprovidersecretsartifactsboundary
Leader viewProject tuning
trace data flowconfigure project policyinspect artifacts

Local-first boundary

Section titled “Local-first boundary”

Orcho keeps its control state local to the workspace by default:

  • project checkout paths;
  • workspace run state;
  • run directories and generated artifacts;
  • output.log, events.jsonl, meta.json, metrics.json, evidence.json;
  • local project tuning such as .orcho/multiagent/plugin.py;
  • prompt overrides and skills that are present on disk.

That local run state is valuable because it can be inspected later without replaying a private agent session.

Worker runtime boundary

Section titled “Worker runtime boundary”

Worker runtimes are the provider boundary.

When a phase invokes a worker runtime, the runtime may receive:

  • the task text;
  • rendered prompt parts;
  • relevant source snippets;
  • diffs or plan artifacts;
  • tool output selected during the phase;
  • project and workspace context included by configuration.

This is the security question to answer for every project:

What information can appear in the rendered prompt or tool output sent to the
worker runtime provider?

Read Runtime adapters for the worker boundary and Prompt engine for how prompt parts are composed.

Secrets posture

Section titled “Secrets posture”

Orcho should not be used as a reason to relax secret hygiene.

Project policy should keep secrets out of the surfaces a worker runtime can read:

  • do not commit secrets to the repository;
  • avoid task text that includes private credentials or tokens;
  • keep generated logs and fixtures free of secrets;
  • tune project instructions so workers avoid secret-bearing files unless the task explicitly requires them;
  • review artifacts before sharing them outside the trusted environment.

Project tuning can help by naming sensitive paths, verification expectations, and review focus. It is still the operator’s responsibility to decide what a runtime is allowed to see.

Artifact retention

Section titled “Artifact retention”

Evidence is useful because it persists. That also means artifacts can contain operationally sensitive information:

  • task text;
  • file paths;
  • snippets from tool output;
  • review findings;
  • diffs;
  • command output;
  • cost and usage summaries.

Keep run directories in the same trust boundary as the project they describe. When sharing evidence, prefer a sanitized excerpt over a raw run directory.

Use Evidence bundle for the artifact model and Events for the durable event stream.

Current boundary

Section titled “Current boundary”

This page describes the local docs-site security posture for evaluating Orcho. Do not read it as a promise of central organization controls.

Current boundaries to evaluate explicitly:

  • no central RBAC model is documented here;
  • no central audit platform is documented here;
  • Orcho records local artifacts, but artifact retention policy is still a project/workspace decision;
  • worker runtime provider behavior depends on the provider and adapter you use;
  • project verification and security review remain project responsibilities.

That boundary is honest and useful: Orcho improves observability and control of agent delivery, but it does not remove the need to classify data, choose providers carefully, and review what leaves the machine.

Section titled “Related”