Security
Isolation model, what briq can see, abuse policy and responsible disclosure.
Isolation
- One microVM per briq. Briqs run as Firecracker microVMs, not as containers on a shared kernel. Two customers never share a machine.
- One private network per team. Each team gets its own private network. Briqs resolve each other inside the team; nothing resolves across teams.
- Optional per-stack isolation (Pro): a stack can get its own app and network, for running untrusted code next to your services without a route between them.
- Private by default. No inbound traffic reaches a briq unless you call
briq_expose. - Egress: allow-all with rate limits in v0; per-key
allow,denyorallowlistenforced by a per-stack egress proxy in v1. SMTP ports 25, 465 and 587 are blocked at the proxy from v1 and documented as blocked from v0.
Where the data physically sits, who the sub-processors are, and what briq does and does not claim about the GDPR: data protection.
What briq can see
briq stores what it needs to run and bill your briqs, and nothing it does not:
| Stored | Not stored |
|---|---|
| Image references, digests, ports, sizes, TTLs | Your image contents |
| Env keys and non-secret values | Values marked { secret }: generated, injected once, masked in status, logs and audit |
| Audit rows: key id, action, target, duration, cost delta | stdout and stderr of briq_exec, beyond the response to you |
Log lines while the briq exists, for briq_logs | Logs after destroy |
| Volume contents while the volume exists | Volume contents after destroy |
API keys are stored as SHA-256 hashes with a lookup prefix. Dashboard sessions use Better Auth (magic link and GitHub OAuth). Operators can access provider consoles and machine metadata to run the service; access is logged.
Guardrails against runaway agents
- Policy checks (concurrency, size, registry, TTL, daily cap) run before any provider call.
- The reconciler enforces
stopsAt, destroys orphan machines and stops briqs past their key's cap every 30 seconds. - Provider calls run in background jobs, so an HTTP timeout never leaks a machine.
- Rate limits per key on create and exec.
- A team-level kill switch for admins.
Abuse policy
briq is for running software an agent or a developer is working on. It is not for crypto mining, sending unsolicited mail, scanning or attacking networks, hosting content that is illegal in the EU, or evading the isolation of another tenant. To that end:
- An image denylist of known miners and a CPU-profile heuristic (sustained 100% CPU with no network I/O for more than 20 minutes) flag briqs for review.
- Public exposure and sizes above
smallrequire a card on file. - Takedowns follow the runbook in
docs/runbooks/abuse.md; report abuse to abuse@briq.run.
Responsible disclosure
If you find a vulnerability in briq, email security@briq.run. Include steps to reproduce and, if relevant, the team or briq ids involved. We acknowledge reports within two business days, keep you informed while we fix the issue, and credit you if you want. Please do not access other customers' data or run denial-of-service tests against the platform.