Trust and guarantees

We make three commitments about how Havby agents operate:

• You decide what each agent can access, at which level, and which actions need a person.

• Agents cannot reach Havby's internal systems or platform credentials.

• Agents cannot spend beyond the budget ceilings set for your organization.

The second and third are each enforced by more than one independent layer, so a fault in one layer does not remove the protection. The source references below point to the files in Havby's codebase that implement each layer.

Each agent works only with the access you grant it, at the level you set for each account. You can change either at any time, and the change applies from the agent's next action.

Access levels

• No access. The agent cannot see the account.

• Can read. Reads and searches. Changes nothing.

• Can edit. Drafts and edits. Nothing goes out, and nothing is deleted.

• Can act with your OK. Also sends, pays, shares and deletes, after you OK each one.

• Can act on its own. Sends, pays, shares and deletes without asking. You get a receipt for each.

Access

• Per connection. Access is granted to each team per connection, at No access, Can read, Can edit, Can act with your OK, or Can act on its own, and an agent can carry its own setting on top. An agent granted read access is not given a means to write. At Can act on its own an agent can send, delete and publish without asking you.

• Nothing connected by default. A new workspace can do nothing until you connect a service. Disconnecting a service stops the agents that use it.

Actions that always need a person

Actions that cannot be reversed, such as sending money, deleting an account or signing a document, require your OK from a person in your workspace, unless the account is set to Can act on its own.

Work happens in the open

• In channels. Agents work in your workspace's channels and on the cards of your board. They post progress, questions and disagreements as they go, so you can follow the work as it happens and step in at any point.

• Receipts. Every action is recorded with who did it, when, why, what changed and who approved it. Receipts are kept for two years and cannot be edited by anyone, including Havby.

Code written by an agent runs in an isolated sandbox that cannot read the credentials held by Havby's workers or reach Havby's internal network.

How it is enforced

• Empty environment. The sandbox is built from a small, explicit allowlist of environment variables and never inherits the worker's environment. Tests assert this for every launch mode (apply, inspect, execute, skill-execute and task-tools), and a CI boundary check verifies it statically.

  apps/agent-worker/src/sandbox.test.ts · scripts/check-boundaries.sh · docs/product/agents.md

• Network isolation. A Kubernetes NetworkPolicy denies each task any route to internal cluster services, databases and private Google Cloud resources, and blocks the cloud metadata endpoint.

  deploy/charts/agent-worker/templates/networkpolicy.yaml

• No database access from the dispatcher. The worker that hands tasks to a sandbox holds no database connection. Memory and task data reach Postgres only through the control plane. A CI boundary check enforces this.

  scripts/check-boundaries.sh

• Hardened container. Each sandbox runs with a read-only root filesystem and all Linux capabilities dropped, inside the gVisor runtime, which adds kernel-level isolation beyond standard container namespaces.

Spending is limited by four nested budgets: organization, workspace, team and task. The organization ceiling cannot be raised by anything below it.

How it is enforced

• Checks at three control points. Budgets are checked before a worker begins spending on a claimed task, when a task is created, and before every connector tool call. A task cannot be created if its budget is already exhausted.

  packages/budgets/src/index.ts · apps/agent-worker/src/work.ts · apps/api/src/tasks/routes.ts · apps/connector-broker/src/dispatch.ts

• Metered reconciliation. Model usage is metered and reconciled against the same budgets after each call. This cannot stop a call already in progress, but it stops the next task or tool call once a budget is spent.

  apps/api/src/usage/routes.ts

• Provider-level cap. Each organization's model provider key carries its own credit cap, enforced by the provider. A fault or bypass in Havby's budget code still meets a hard limit outside Havby.

Testing

• Both layers were chaos-tested on August 30, 2026. With the organization budget deliberately removed, a concurrent runaway loop ran against the live provider until OpenRouter's key limit refused it. Spend reached 1¢ against a 1¢ cap. With the application ceiling active, the worst-case concurrent overshoot measured 6¢ against a theoretical bound of 8¢.

  docs/plans/2026-08-30-2100-budget-chaos-results.md

If you believe any of these controls can be bypassed, contact security@havby.com.