# Security

URL: https://briq.cloud/docs/security

> Isolation model, what briq can see, abuse policy and responsible disclosure.

## Isolation

* **One microVM per briq.** Firecracker microVMs, not containers on a shared kernel. Two customers
  never share a machine.
* **One private network per team.** Nothing resolves across teams.
* **Private by default.** No inbound traffic reaches a briq until you publish it (`expose` on
  `briq_run`, or `briq_expose`).
* **Databases from outside over TLS only.** A TCP endpoint takes TLS 1.2 or later and refuses
  plaintext. Its password is the gate: recipes generate about 140 bits, the edge refuses a
  Postgres, Redis or MongoDB that lets anyone in, limits connections, and locks out an address
  after 10 failed logins.
* **Egress is open**, except outbound mail (SMTP ports 25, 465, 587), which the
  [abuse policy](#abuse-policy) forbids.

Where data sits and who the sub-processors are: [data protection](https://briq.cloud/legal/data-protection).

## What briq stores

| Stored                                                                                                                                | Not stored                                                                   |
| ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Image references, ports, sizes, lifetimes                                                                                             | Your image contents                                                          |
| Env values; secrets encrypted, and masked in status, logs and audit                                                                   | `briq_exec` output, beyond the response to you                               |
| Audit rows: credential, action, target, duration, client name and version; env names, files by path and size, an exec's stdin by size | Env values, file contents, stdin and passwords in commands, in the audit log |
| Logs, boot files and the briq's disk (volume and the rest) while the briq exists                                                      | Logs after destroy                                                           |
|                                                                                                                                       | Disk contents after destroy; secrets and boot files a day after it           |

API keys are stored hashed. Signed-in MCP clients get 30-day access tokens bound to
`https://api.briq.cloud/mcp` and a rotating refresh token; revoking the agent ends both at once,
since every call checks the agent is still connected. No client
gets a token without a person approving it. briq operators can access infrastructure consoles and
machine metadata to run the service; that access is logged.

## Guardrails against runaway agents

* Policy checks (concurrency, size, registry, sleep, daily cap, credits) run **before** any machine
  is created.
* Only a signed-in person creates keys or changes a policy; an agent cannot raise its own budget.
* Briqs unused for their `sleep` window go to sleep, and briqs past their agent's daily cap are
  stopped, within seconds.
* Machines are created and destroyed in the background, so a dropped connection never leaves one
  running untracked.
* Rate limits per credential on requests, creations and exec.

## Abuse policy

briq is for running software an agent or a developer is working on. Not for crypto mining, sending
unsolicited mail, scanning or attacking networks, hosting content illegal in the EU, or evading
another tenant's isolation.

Briqs that break this policy are stopped and the team is contacted; repeated or serious abuse
closes the account. Report abuse to [abuse@briq.cloud](mailto:abuse@briq.cloud).

## Responsible disclosure

Email [security@briq.cloud](mailto:security@briq.cloud) with steps to reproduce and, if relevant,
the team or briq ids. We acknowledge within two business days, keep you informed while we fix it,
and credit you if you want. Do not access other customers' data or run denial-of-service tests.