Security
What the POC does and doesn't protect against
An honest list of the protections in version 0.2 and the gaps you should know about before you rely on it.
Agent Office v0.2 is a proof of concept. This page tells you plainly what it protects and what it doesn't, so you can decide what to trust it with.
Protected in v0.2#
- Agents can't grant themselves powers. Policy changes need a merge by the
approversteam on the policy repo, and capability windows need a human's approval. - Agents are separated from the office. Each runs as its own OS user and can't read the office's database, secrets or transcripts.
- Agents are separated from each other, on disk and on the forge.
- Agents can't rewrite their own instructions.
CLAUDE.mdand.office/**are protected in each vault. - No long-lived forge credential enters a run. Forge tokens are minted per run and always revoked, and no token goes on a command line.
- Network egress is allowlisted by Claude Code's sandbox (strict allowlist).
- Every state change is ledgered by the office, hash-chained and anchored to the policy repo every hour by default.
- Humans see only what their role allows, in the web UI and through MCP alike.
Not protected in v0.2#
| Gap | What it means for you |
|---|---|
| The office host is fully trusted. | Root on the machine, or control of the office's OS user, means control of everything: secrets, ledger and agents. Harden and patch the host like any server holding admin credentials. |
| The ledger proves integrity, not completeness. | The chain shows nothing logged was altered. It can't show that something was never logged. The anchors are committed by the office's own forge admin account, so someone who controls both the office and the forge could rewrite both. |
| The office's admin account can merge policy. | The office's forge admin is in the approvers team (it commits rendered CLAUDE.md files and ledger anchors). Whoever holds its token, which is the office host, could merge policy changes. |
policy_roles aren't enforced. | hiring_approvers, access_approvers and budget_approvers in access.yaml are validated and shown in diffs, but merge rights come only from the forge's approvers team. Any member can merge any policy PR. |
| Prompt injection within granted powers. | If an agent may mail anyone and open PRs on a repo, a malicious mail can steer it to do exactly those things. Capabilities limit what's possible. They don't judge intent. Grant narrowly. |
| Allowed destinations are still destinations. | An agent can write anything to places it's allowed to write: its vault, mail, PRs, and hosts on its egress list. Keep net.egress short. |
| The model provider sees the work. | Prompts, files the agent reads and tool results go to the model API under your key and that provider's terms. |
| Budgets are approximate. | Spend is recorded from the cost Claude Code reports when a run ends. With hard_stop: true each run is capped at the remaining budget (--max-budget-usd), but concurrent runs of one agent each get the same remainder, so the day can end over usd_per_day. With hard_stop: false runs continue past the budget, flagged. |
| Ending a window early doesn't stop a run already going. | End now on Needs you closes an approved window at once for the agent MCP and for every new run, but a run that started while the window was open keeps the settings it was compiled with until it ends. Approve short windows, and stop the run too if it matters. |
forge.write relies on branch protection. | Agents may run git as a whole. The deny rules for pushing to main are a speed bump; what refuses the push is branch protection on the repo. officectl init protects the policy, office and handbook repos. Any other repo you grant forge.write on must have main protected by you, or the agent can push to it. |
| Chat is private from other people, not from leads. | Another person can't open your thread, but a chat run is a run: people with run.transcript.read on the agent (lead and up) can read its prompt, which carries the conversation, and see its live text. Don't paste secrets into chat. |
| Isolation depends on Claude Code's sandbox and OS users. | There is no VM per run. A kernel or sandbox escape would defeat ring 3. Rings 1 and 2 still hold on the forge. |
| Development mode isn't isolated. | host.os_users: false runs agents as the office's own user. The desk says "Not isolated (dev mode)". Don't use it with real data or credentials. |
| The model credential is long-lived. | Every run receives the office's model credential (or the agent's own key) in its environment for the length of the run. Use a per-agent API key from a Console workspace with a spend limit to contain it. |
| Single-factor sign-in. | Local passwords only. SSO through OIDC is Roadmap. |
| Only the office MCP server. | Agents can't use your company's other MCP servers (Linear, Sentry and so on). An office gateway that would proxy them under the same policy is Roadmap. |
| No per-run secret placeholder swap. | Model and forge credentials reach the harness as environment variables (handed over on stdin, never in argv) for the run's duration. An egress proxy that swaps placeholder tokens is Roadmap. |
| GitHub isn't supported. | The GitHub adapter is a Stub. Offices run on Gitea. |
What we recommend for a trial#
- Use a dedicated VM or Mac that runs nothing else important.
- Give agents test repos and test data first. Start with the founding agents and narrow capabilities.
- Use Anthropic API keys from a Console workspace with a spend limit, as well as per-agent budgets in the office. See Model credentials.
- Run
officectl verify --liveafter install and after every upgrade, and keep the output. - Set up backups and back up the forge separately.