Security

Agents run with your CLI logins and write access to your project. VibeBoard's job is to make sure that is all they get. The full model lives in the repository, beside the code it describes: docs/security/model.md states it end to end, and docs/security/containment.md holds the reasoning behind each mechanism. In short:

Every agent runs in a Docker container. There is no fallback: without Docker the board works and no agent starts. Each project gets one box per backend, created with the project and removed when VibeBoard stops.

The box sees your project and nothing else. The project is mounted writable, so an agent can build, test and commit. .vibeboard/ and git's hooks and config are mounted read-only on top, so it cannot rewrite its own instructions, its cards or the gates it is judged by, or arrange to run code at your next commit. Nothing else on your disk is mounted at all, including VibeBoard's own credentials.

Agents change the board through the API, with a credential scoped to the one card they were given. System packages are installed for them by VibeBoard; the image has no sudo, so an agent never holds root.

The box reaches the internet, but not your network. It has to reach the model; it cannot reach your LAN or the other services on your machine. Those rules are applied from outside the box. This is not exfiltration control.

The first browser signs itself in. Before any browser is in, no agent can exist, so that first sign-in is safe. Every later browser has to be allowed from one that is already signed in. The credential is an HttpOnly cookie: it never appears in a URL, the log or your screen.

Opening it to your network is your call. VIBEBOARD_HOST=0.0.0.0 makes the board reachable from other devices, and anyone you allow in can drive agents with your CLI credentials. Do it only on a network you trust, and never on the public internet.

Found a vulnerability? Report it privately, as SECURITY.md describes, not in a public issue.