The problem
The production lockdown keeps AI agents from changing a client org's production environment on their own, in my work at a Salesforce consultancy.
How it works
Agents work quickly in sandboxes, deploying metadata, loading data and running scripts. The same commands pointed at production could break a live business process, and a single confused agent or a mistyped target would be enough. Relying on the agent to be careful was not acceptable.
Production is closed by default. Guards sit in front of every command that can write to an org. When the target is production, the command is blocked, the agent prepares the change and stops, and a person has to review it and click to let it run. Reads stay open, so agents can still inspect production. A test suite tries the known ways past the guards, such as aliases, different command forms and indirect calls, and runs whenever the guards change, so a fix in one place does not open a hole in another.
- Production writes blocked by default
- A human click to go ahead
- Guards covered by tests
Outcome
The guards are live. By default the agent has to wait, and the waiting is enforced in code.
Stack
- salesforce
- production-safety
- human-in-the-loop
- claude-code-hooks
- deploy-guards
Code
github.com/HenryLop/prod-lockdown-guards
Transcript
Agents cannot change a client's production without a human click. At a Salesforce consultancy, agents deploy to sandboxes all day. Production is different: one wrong deploy can stop a client's business. So guards block every write to production by default, and the agent stops and waits for a person to click. Tests try to get past the guards on every change, so they stay closed.
How this was made
Voiceover is text-to-speech (Microsoft Edge neural voice). Background art is AI-generated (Gemini). Titles and captions are set in code, not generated. The build itself was made with Claude Code.