Voss
Security

Agent power needs visible boundaries.

Voss treats repository automation as a security-sensitive workflow. The harness gives one agent scoped access, explicit modes, and local auth — and the orchestration layer extends the same boundaries to a whole team, where budget and scope are enforced, not trusted.

Current posture.

Permission modes are explicit

`plan`, `edit`, and `auto` make the agent's authority visible. The default path favors inspection before mutation.

Writes are scoped to the project

Harness tools operate from the current working directory and keep file operations inside the project boundary.

Shell access is gated

Shell execution is treated as a separate permission surface instead of being bundled into ordinary file edits.

Auth stays local

Claude Code, Codex, and provider API keys are read from local auth stores or environment variables. Voss does not add a hosted credential service.

Orchestration cage

Autonomy with hard limits.

When Voss runs a team, the Engineering Manager is a constrained tech lead. These invariants are enforced by the runtime — they do not depend on the model behaving.

The EM cannot invent roles outside the declared roster
Workers cannot write outside their assigned scope
Budget cannot be oversold — it is a security boundary
Agents cannot mark their own work Done
Done requires independent reviewer evidence
Ceiling, confidence threshold, and roster are immutable mid-run