Let business teams build with AI safely

Windmill lets business teams build scripts, flows and apps with AI, on the same platform and in the same workspaces as the engineers who run production. Engineers keep control of what ships: the AI builds in an isolated copy, a reviewer deploys, and the code runs on workers you chose for it.

This page combines the guardrails Windmill already has into one setup for AI-assisted building, often called vibe coding. Each guardrail is documented on its own page, linked below. For an overview, see the build with AI page. For the general progression from a shared workspace to multi-environment promotion, see collaboration and deployment stages.

Guardrail	What it stops	Edition
Workspace roles	Authoring more than a team needs	Overriding the default roles on every edition, custom roles on Enterprise Edition
Folders and scoped AI context	The AI reaching resources, skills and MCP servers a team should not use	All editions
Forks and review	Unreviewed changes reaching the shared workspace	Forks on all self-hosted editions, protection rulesets on Enterprise Edition
Dev and prod workspaces	Builders holding prod credentials or editing prod	Dev workspaces on all self-hosted editions, locking prod on Enterprise Edition
Dedicated workers	Unreviewed code running next to production jobs	Tags on all editions, worker group features on Enterprise Edition
A separate instance	Any shared control plane with production	Enterprise Edition
Audit logs	Changes nobody can trace	Full audit logs on Enterprise Edition

You don't need all of them. Most teams start with roles, forks and review, then add dedicated workers or a separate instance when the code built by business teams touches sensitive systems.

Choose what each team can author

A workspace role is a set of capabilities, and two of them suit business teams:

Members who assemble what engineers built get Compose for flows and apps, without Write code. They build flows only from deployed workspace scripts and flows, with no inline code and no Hub scripts, and their full-code apps call existing workspace runnables and always deploy with sandbox isolation.
Members who write code with AI get Write code, and rely on the guardrails below instead of on the role. AI sessions require Write code: members without it keep the AI chat side panel.

A role restricts authoring, not access to data: what a member can read and use is set by folders and groups. A role that can author, at the Compose or Full level, consumes a full seat.

Scope what the AI can reach

The AI acts with the permissions of the person using it, so scoping a team scopes its AI. Give each team a folder and grant its group access only to the resources and variables it needs.

The AI's context follows the same model:

Skills and MCP connections saved in a folder are available to everyone who can read that folder, and nobody else.
Workspace instructions, editable only by admins, are sent with every session in the workspace, for example to point the AI at the team's approved scripts and conventions.

A member with read access to a variable can read its value, secrets included, through the API, whatever their role. Keep prod credentials out of the folders business teams can read, and give them their own values in a dev workspace.

Build in a fork, deploy after review

An AI session runs in a workspace or in a workspace fork, an isolated copy of the workspace. Creating a fork per session keeps every experiment out of the shared workspace until someone reviews it.

To make review mandatory, add a protection ruleset that enables Disable direct deployment on the shared workspace, with a group of engineers on its bypass list. Changes made in a fork then reach the shared workspace only when one of them reviews the diff on the Compare & Deploy page and deploys it. CI tests run automatically when the tested script or flow is deployed.

A fork is a full copy of its parent, variables and secrets included. If business teams should not hold prod credentials, have them build in a dev workspace instead.

Promote between environments

A dev workspace is a persistent fork paired with a prod workspace, with its own resource and variable values. Business teams build in dev, against dev databases and accounts, and prod can be locked so changes only reach it through promotion.

Promotion is never automatic: a member who can deploy to prod reviews the diff and deploys it from Compare & Deploy, or the change goes through a pull request with Promote to prod via Git. Resources and variables marked workspace-specific keep their value in each environment, so promoting code never overwrites a prod credential. When deploying, run on behalf of decides which user the item executes as in prod, for example a service account rather than the person who built it.

Run their jobs on separate workers

Worker groups decide where code runs, and can sit on different machines, clusters and networks. Route the jobs of business teams to their own workers:

Restrict a tag to specific workspaces, so only the dev workspace can use the workers that reach dev systems, and prod-only workers stay out of reach. A fork inherits a scoped tag only when you opt in with *.
Use $workspace in a tag, so the same script runs on normal-dev workers in the dev workspace and on normal-prod workers once promoted. A dev workspace resolves $workspace to itself, so it can have its own workers.
Send all fork jobs to a dedicated fork worker pool with the -fork tag suffix.

For code that has not been reviewed yet, add process isolation on those workers, or run them as agent workers without direct database access.

Keep builders on a separate instance

For the strictest separation, business teams build on their own Windmill instance, with its own database, workers and settings, and engineers promote reviewed changes to the production instance. Deploying to a workspace on another instance from the deploy drawer runs as the deployer's own account on the prod instance, so its permissions, protection rules and audit logs apply. The Git promotion workflow works across instances too.

Audit what was built and deployed

Every action with side effects is recorded in the audit logs with the user who performed it, including deployments. Each script, flow and app keeps its version history, so a promoted change can be compared or rolled back. On self-hosted Enterprise Edition, audit logs are kept for 365 days by default and can be forwarded to a SIEM.

Example setup

A team of analysts building internal tools with AI, next to a platform team that runs production:

Workspace ops is prod. A protection ruleset disables direct deployment, with the platform team on the bypass list.
Dev workspace ops-dev is paired with it, with dev database credentials marked workspace-specific.
Analysts have a role with Write code in ops-dev, and an operator role in ops.
Scripts are tagged normal-$workspace: jobs run on normal-ops-dev workers in a network that only reaches dev systems, and on normal-ops workers once promoted.
Analysts build in AI sessions, one fork of ops-dev per session, and deploy into ops-dev when it works.
The platform team reviews the diff from ops-dev to ops in Compare & Deploy and deploys it.