Secure AI-generated apps
Run AI-generated internal apps safely
Code written by a coding agent is not uniquely dangerous. But it is written fast, by people who are not always engineers, and deployed without the review a production service gets. The risks are predictable, so the defaults can be too.
Where AI-built internal apps go wrong
Most incidents with quickly built internal tools are not clever attacks. They come from a handful of gaps that show up again and again.
| Risk | How it happens | On Brod |
|---|---|---|
| No sign-in | The app works, so it gets a public URL "just for now", and the URL is shared in chat. | A new app is private to its owner and admins. Sign-in is checked before any request reaches it. |
| A home-made login | The agent writes a login form with a hard-coded user list, or session handling with gaps. | The app never handles sign-in. It reads the signed-in person and role from Brod. |
| Keys in the code | An API key is pasted into the source, ends up in git history, or ships to the browser. | Secrets are set separately, encrypted, and read by server code as env.NAME. Nobody can read them back. |
| Shared database credentials | Several tools point at one database with one powerful login. | Each app has its own database and files. One app cannot reach another's data. |
| Too open, too long | Access was widened for a demo and never narrowed again. Leavers keep access. | Widening access needs a person to confirm, and is logged. Removing someone from the workspace removes them from every app. |
| A bad edit goes live | The next AI change breaks the app or drops a check, straight in production. | When an agent updates a live app, the new version goes to staging first. Every version is kept, and rollback is immediate. |
| Nobody can see what happened | No logs, so errors and odd access go unnoticed. | Deploys, access changes, refusals and recent requests with errors are logged per app. |
The principle: keep security out of the generated code
You can ask a coding agent to add authentication, encrypt secrets and write access checks, and to get each of them right every time it edits the app. It is safer to make those things the platform's job, so that a regeneration, a refactor or a hurried change cannot remove them.
The app code decides
What a person can do inside the app (for example, only approvers can approve).
Brod decides
Who reaches the app at all, who they are, and where the credentials live.
Agents are a new kind of user
When an agent deploys for you, it holds a credential that can change running software. Brod treats that credential differently from a person.
- Made by a person. Tokens are made by a person, can expire, and can be revoked from the workspace's connections page.
- Some actions need a person. An agent can deploy, fix, roll back and narrow access, but not widen access, invite people, or delete apps without a person confirming.
- Secrets are write-only. Agents can store secrets but not read them.
A short checklist for any AI-built internal app
The guide to securing a vibe-coded app walks through each step with examples.
Decide who should open it
Name the people or group. Start narrower than you think.
Remove every secret from the code
Search for keys and tokens, rotate any that were committed, and store them as secrets.
Give the app roles
Most tools need at least two: people who look and people who change things.
Check writes on the server
Hiding a button is not access control. The server code should check the role before changing data, and check the
Originheader onPOST.Keep a way back
Know how to return to the last good version before you deploy the next one. On Brod, rollback restores the code, not the data, and staging uses the live database, so be careful with changes that rewrite data.
Where this stops
Brod is built for internal apps written by trusted people and their agents. It is not a sandbox for hostile code, and it does not review what your app does once someone is allowed in. Read what Brod does not protect against before you rely on it.
Keep reading
- SecurityHow Brod protects AI-generated internal apps: access checked before every request, private by default, human confirmation for sharing, encrypted secrets, per-app data, and what it does not protect against.
- Secure a vibe-coded appA checklist for securing an app built with an AI coding agent: secrets, sign-in, access, roles, staging, logs, outbound hosts, and what is still left to you.
- Auth for AI-generated appsAdd sign-in to an app your AI agent built without letting it write a login. Brod checks sign-in at the gateway and hands the app who is visiting and their role.
- Vibe-coded appYou vibe-coded a tool and want your team to use it. What happens when it goes online with Brod, what is safe by default, and what is still yours to check.