# Security

State on 2026-11-10 (phases 0–2). Every control listed here exists in the code and names the test that exercises it; the "Known gaps" section is the honest remainder.

# Threat model

Agent OS runs model-driven tool calls on a personal Mac that also holds other projects, credentials and a cluster. One owner (a single administrator account). What we defend against:

1. The agent itself — a model that is wrong, manipulated by content it reads (prompt injection in a repository, a tool output, later a web page), or simply over-eager: it may try to read secrets, write outside its project, exfiltrate data, push code, burn money, or loop forever.
2. The Internet — anyone reaching https://agent.spboucher.ai: credential guessing, session theft, CSRF, XSS through model / tool output rendered in the console, WebSocket hijacking.
3. Crashes and restarts — a worker killed mid-step must not repeat an external effect, lose an approval, or leave a mission in a state nobody can explain.

Out of scope today: a malicious local user on the node, a compromised provider, a compromised dependency, physical access.

# Controls implemented — and the test covering each

# Agent containment

# Durable execution

# Console and API

# Known gaps

• Seatbelt read exposure. The sandbox is deny-default for writes; reads are allowed except an explicit deny list. Anything readable by the worker's OS user that is not on the list (other home sub-directories, /Users/Shared, mounted volumes, files sitting directly in ~) can be read by a shell command. AOS_SANDBOX_EXTRA_DENY_READ must be maintained by hand for each node (production sets ~/apps, ~/backups, ~/Desktop, ~/Documents, ~/Downloads, ~/dispatch, ~/srv). Plain files directly inside an ancestor directory of the workspace stay readable. The file tools (read_file, search) are confined to the workspace; this gap is the shell's.
• network: open has no egress proxy. Outbound traffic is unrestricted (inbound and localhost are blocked): a manipulated agent can send workspace content anywhere once the owner approved a network command. The mitigation today is the approval (once per command prefix when remembered) and the default none. No domain allowlist, no traffic log.
• No dedicated OS user. The worker runs as the node's main user; containment relies entirely on Seatbelt and the tools' path checks. sandbox-exec is deprecated by Apple (still functional on macOS 27; the self-test fails closed if it stops enforcing).
• Shell re-execution window. With network: none a shell step is classed idempotent_write: a step interrupted by a crash is executed again from the start. A command that is not idempotent inside the workspace (appending to a file, a half-applied migration script) runs twice partially. With network: open the owner is asked instead.
• Git tools outside the sandbox. git_status / git_diff / git_commit / git_push run git directly with a hardened config, not under Seatbelt. A repository's own config cannot add hooks or an external protocol, but git is a large surface.
• No compaction. At ~70 % of the context window the agent is told to wrap up; at ~90 % the run ends partial. Long missions must be split.
• Single agent only. No sub-agents, so no isolation between a planner and workers handling untrusted content; all tool output enters the one context.
• Prompt injection is mitigated, not solved. The system prompt tells the agent to treat file and tool content as untrusted data, and the policy is outside the model, but a repository file can still talk the agent into a bad allowed action (e.g. a destructive edit inside the workspace). The mission branch + commits are the undo.
• policy.decision events are not replayable over REST. They are persisted and pushed live, but a page reload does not fetch old ones: after a reload the timeline shows approvals (from the journaled wait steps) and marks refused tool calls as "not executed" without the reason.
• Refused tool calls have no journal step (invalid input, policy deny): they exist only in the model's transcript, which is not readable from the console.
• Mission status during an outage. With no live worker a mission still reads "running" until a worker claims it; only the System page says the worker is down.
• Single administrator, no roles; no IP allowlist in front of the login page; passkeys optional.
• No retention / GC for events, steps, artifacts and audit rows; backups contain the journal (objectives, tool outputs) encrypted with a passphrase stored on the same node.
• Not exercised in production yet: mld deployment, the tunnel route, PM2 kill_timeout, backup.sh / restore.sh against the real database (docs/deployment.md).