Security model
Brod runs apps that people in your organisation, or their agents, wrote. It decides who may open each app, signs people in once for all of them, and keeps one app's data apart from another's. This page explains how, and is plain about the limits.
This is a summary for people choosing where to run AI-built internal apps. The full model, written for engineers, is docs/security.md in the open-source repository, and the code is there to check it against.
Every request to an app goes through Brod's gateway first. The gateway works out who the visitor is, checks the app's access mode and grants, and only then forwards the request. An app with a bug in its own permission logic, or no permission logic at all, is still behind that check.
Each app has one of six access modes:
| Mode | Who can open the app |
|---|---|
private | The app's owner and workspace admins. The default for a new app. |
people | Only the people, groups and email domains granted a role in the app. |
workspace | Everyone in the workspace (guests only if granted). |
password | Anyone with the address and the app's password, without an account. |
signed_in | Anyone signed in to Brod, in any workspace. On brod.sh, that means anyone with a brod.sh account. |
public | Anyone, without signing in. |
People sign in once per workspace, with an emailed link or Google. Apps never see a password and never handle the sign-in flow. When a signed-in person opens an app, the app gets its own session for its own host, so one app cannot read another's session.
The gateway removes any identity headers a visitor sends and adds its own, signed by Brod, before forwarding the request. App code reads the visitor's email, name, role and groups from /_brod/me in the browser, or from those headers on the server, and can trust them.
On HTTPS, every Brod cookie is __Host--prefixed, Secure, HttpOnly and SameSite=Lax.
| What | How it is kept |
|---|---|
| App secrets (API keys and the like) | AES-256-GCM under a key derived with HKDF and bound to the app. Write-only through the API: an agent can set a secret, but never read one back. |
| Agent tokens, OAuth tokens, sessions, sign-in links | Only a SHA-256 hash of a 24-byte random value is stored. |
| App passwords | Argon2id with a per-password salt. |
Because the app reads secrets as env.NAME at runtime, the key does not need to be in the code the agent writes, in the repository, or in the browser.
Apps are served from *.brod.sh app hosts, a different domain from the platform's own pages, so an app cannot read the platform's cookies.
Each app with server code has its own SQLite database, key-value store and file storage. An app has no way to address another app's data.
Server code runs in workerd, each app in its own V8 isolate.
Apps list the outside hosts their server code calls in brod.json. The operator can log or refuse calls to anything else.
Bundles are checked for size, file count and path traversal, and files are served with a type from their extension and X-Content-Type-Options: nosniff.
Sign-in links, deploys, API and MCP calls and app passwords are rate limited per person, address or app.
Tokens are made by a person on the workspace's connections page, can be given an expiry, and can be revoked at any time. Agents can also connect with OAuth 2.1, where the person picks the workspace in the browser.
Brod assumes the people who deploy apps are trusted members of the team. It is not a sandbox for hostile code. Specifically:
brod.sh site for browser purposes, so SameSite=Lax does not stop a page in one app posting a form to another. Apps that change data on POST should check the Origin header.frame-ancestors policy by default. Apps that need clickjacking protection should send their own.Brod does not yet offer company sign-in (SAML or OIDC), SCIM, or blocking paths by role. Those are on the roadmap, not in the product.
Brod is open source under AGPL-3.0, so the gateway, runtime and storage code can be read and audited. Vulnerabilities can be reported privately through GitHub as described in SECURITY.md.
No. Widening an app's access returns a confirmation link, and nothing changes until a person opens it and confirms. The change is recorded in the app's log.
No. Secrets are write-only through the API and MCP tools. Only the app's server code can read them, as environment values.
Not yet. People sign in with an emailed link or Google. Company sign-in with SAML or OIDC is on the roadmap.
No. Each app has its own database and file storage, and its server code runs in its own isolate. Apps cannot address each other's data.