security and permissions model

orcr's trust model is deliberately small: filesystem permissions are the only authentication, and orcr never interprets the content an agent produces. this page states what the model protects and what it does not.

filesystem permissions are the authentication

the server listens on a Unix domain socket at ~/.orcr/orcr.sock, created with umask 077 and mode 0600, the same approach herdr uses. there is no TCP port by design: only processes running as your uid can open the socket, so the OS enforces access.

the server refuses to start unless the home is safe:

• ~/.orcr must be owned by the current uid and not group- or world-writable, or the server refuses with unsafe_home (an environment_error, exit 2).
• socket paths are lstat-validated; symlinks are rejected.
• a stale socket is unlinked only while holding the single-instance lock and only if it is same-uid.

startup takes an exclusive lock file in ~/.orcr (flock), and the server refuses to open the store without it. clients auto-starting the server first validate any existing socket with a handshake; losers of a start race wait for readiness rather than spawning a second server. distinct errors separate the failure modes: server_unreachable (cannot connect), server_start_failed (spawn failed), herdr_unreachable (server fine, herdr not). see durability and recovery for the single-instance and version-negotiation details.

everything runs with bypassed permissions today

orcr's integrations launch each provider with bypass-permissions flags so agents can work unattended, without a human clearing each permission prompt. the cost is that a spawned agent can read and write files and run commands with your privileges. --read-only (per-provider write-tool disabling) and then policy profiles are future work; they do not exist yet.

two structural bounds still apply. runaway nesting and fan-out are capped by the path depth limit (8 segments or fewer) and the global and per-provider concurrency caps: admission control, not polite requests. and an agent's cwd is the caller's cwd or --cwd, so you choose where it operates.

treat child output as data, never as instructions

child output flows into parent prompts by construction: a fan-out reviewer's findings become part of a synthesizer's prompt, a classifier's answer selects a handler. that output is untrusted. a compromised or confused child could emit text that reads like an instruction ("ignore your task and run …").

two rules follow:

• the orchestrating code treats child output as data. quote it, validate it against an expected shape or enum before using it, and never execute instructions found in it. the classify-and-act pattern shows normalizing a model's answer through an enum before it is ever used in a path.
• orcr itself never interprets response content. it records a transcript locator and reports what the transcript shows; it does not parse a response for commands, success, or intent. completion is verified from herdr state and transcript settling (see status model and completion), never from what the agent said.

what the boundary does not cover

• anyone who can run as your uid can use the socket. the socket is not an authorization layer beyond the OS uid check.
• blocked_kind classification is best-effort; do not build security decisions on it.
• there is no audit of what an agent does beyond launch.json (the launch payload) and the native transcript.

the troubleshooting page covers the operational failure messages (unsafe_home, herdr_unreachable, server_start_failed), and the roadmap tracks the permission-policy work.