Security

Security model

Weaver runs agents against your code. The architecture is built to keep that safe. This page describes what we commit to — not the specific tools we currently use to deliver it. Implementations evolve; the commitments don't.

Structural permission gates on destructive operations

Every destructive tool call — running a shell command, writing a file, creating a commit, opening a PR — passes through a permission prompt before the operation executes. The gate is structural, not decorative: a prompt-injected agent that calls a destructive tool directly still round-trips through the prompt first. There is no "trust mode" that bypasses it. The desktop side auto-denies after a short window if no decision arrives.

Sandboxed execution

Agents execute against a sandbox interface, not against your machine directly. Today that sandbox runs on your Mac, with the agent proxying tool calls over an authenticated channel; in the cloud lane it will run inside an isolated VM per run. The interface is the same; only the substrate changes. Chat-style agents — the in-product clarification dialogue, the comment-reply assistant — never compose the sandbox interface at all. Their tool surface is read-only on your spec; they cannot reach shell, file system, or git.

Least-privilege secrets, no long-lived keys

Secrets are scoped per service and per environment. The deployment pipeline can reference a secret by name, but cannot read its value; only runtime services hold accessor permissions, and only on the specific secrets they need. Secret rotation propagates without a restart. There are no long-lived service-account keys checked into repositories or CI; every deploy authenticates through short-lived, repository- and branch-scoped federation.

Authenticated boundaries, end to end

Every internal endpoint requires authentication; no service is publicly reachable except through the global edge. Internal control paths (collab handshake, agent run handshake, internal RPC) live on private network segments and never appear in any public URL map. Cross-service tokens are bound to specific runs, specific users, and specific time windows; their reuse outside that binding is rejected.

Audit posture

Every privileged operation is logged with the actor, the resource, and the outcome. Agent execution traces are stored alongside the spec they ran from, so you can replay why a destructive operation ran and who authorized it. We treat the audit log as a feature of the product, not a compliance afterthought.

What we don't do

  • We do not train models on your workspace content.
  • We do not store API keys for the LLM provider on the desktop side; the agent loop holds them server-side and the desktop never sees them.
  • No service is publicly reachable except through the edge. Everything behind it is closed to the public internet — no open admin surfaces, no anonymous access.
  • We do not silently fail closed on missing config. Required dependencies missing → the service refuses to start. Loud over silent.

A formal security audit is on the roadmap before the cloud lane ships broadly. For specific questions, vulnerability disclosure, or to dig into how a particular control is implemented today, email harry@triverge.dev.