Trust
Security model
What each tool protects, what it does not yet, and how to use BricoWerx safely today.
A tool that writes source files into your repository is privileged by nature. This page says what each part of BricoWerx protects, and, just as plainly, what it doesn’t protect yet. We would rather name a gap than imply a protection we haven’t shipped. Each gap is removed from the list when its fix lands.
What is protected today
CLI and Vault
- No secrets in the Vault.
capturerefuses a directory that contains credential files (.env,*.pem,.npmrcand similar). There is no override, and-ydoesn’t skip the check. - Immutable versions. A stored version is never overwritten, and every change is a git commit you can audit.
- Confirmation before changes. Commands that write or delete ask first.
- Upgrades keep your edits.
upgradeskips bricks you have changed, and backs them up before overwriting when you pass--force. - Verified installs. The install script and the npm package check the binary against the release’s SHA-256 checksums.
Builder
- Model-written code is statically checked before it runs: no imports, network, process access, timers,
eval, clock or randomness. - Tests run in a child process with no API keys in its environment and a hard timeout.
- Bricks are built outside the app and installed only after every gate passes. Existing bricks are never overwritten.
- Model keys stay on the server. Access is invite-only, with rate limits and request validation.
Scanner
- No access to any site at install. Access is granted per tab or per site, when you ask for a scan.
- Body values are discarded in the page, not masked. Credential headers, cookies, query values and URL credentials never leave the page.
- Nothing is sent anywhere until you click Build.
Known limitations
| Limitation | Impact | What to do today |
|---|---|---|
brico add doesn’t confine file paths | A malicious manifest could name a path outside the install directory | Only add bricks from Vaults you control or authors you trust |
brico remove deletes the whole install directory | Files you added inside it are deleted too | Commit before removing |
| The Worker’s local bridge is unauthenticated | Any local process can queue jobs against your Mistral key | Run the Worker only on your own machine, only while you use it |
| The Worker may connect as the database owner | Row-level security is bypassed | Use a least-privileged role, on a database you own |
| Generated bricks aren’t flagged at install | Machine-written code can be installed without a prompt | Check a brick’s origin before adding it |
| Vault content isn’t hashed or signed | Tampering with a Vault can’t be detected | Keep Vault repositories private and trusted |
Machine-generated code
Bricks from the Builder and the Worker are written partly by language models. They are typechecked and tested before they are installed, but passing tests is not a security review. Read generated code before you ship it.
Third-party data transfer
Two features send data to model providers. The Builder sends your interview answers and the prompts for each function to the free-tier providers you configure. The Worker sends implementation prompts, built from scanner evidence that has already had its values removed, to Mistral. The CLI, the Vault and the terminal UI send nothing anywhere, except git pushes and pulls you start yourself.