Run Claude Code in an isolated VM that opens PRs
One annoying thing having a guard model is ensuring its FP rate is low enough to not be a headache, and its FN rate low enough to be worthwhile to use. Task: One annoying thing having a guard model is ensuring its FP rate is low enough to not be a headache, and its FN rate low enough to be worthwhile to use. Likely also means you’ll need to either use a frontier-close model, further increasing costs as well as round-trip time.Or maybe some system 1 model?For my setup, i have claude code in its own VM, whose VLAN is heavily restricted outside of the internet, my forgejo instance, infisical for secrets, and one way SSH from my machine to the VM.All secrets are shared via infisical secrets store, so the actual secrets are never shown to the agent. Dev mode can be used for running the system locally during development, and those secrets may be seen in some cases. The foregjo user the agent has access to can only create issues and PRs. Manual merge required, after which a CI pipeline handles the packaging and “production” deployment of the app to my app server VM.I think a setup like that (or discouraging these agents access to the same computer people keep their finances/health data etc) should be discussed/championed more.My work encourages just running the harness on their system (which I get for practical reasons among others), to which I then put my work laptop on its own VLAN.Overkill, for sure. But to me the risk of personal data exfiltration is far too high with these vibe coded harnesses and models which are more and more opaque.; tools: Claude Code. Human role: The original post does not say how a person stayed involved.; limitations: This architecture requires significant infrastructure overhead, including separate VMs, VLAN configuration, and secret management tools. The author notes that guard models may increase costs and latency. Integration uncertainty exists regarding how well this setup scales for larger teams or complex dependencies. Human approval is mandatory for every deployment..
Tools
Published on Agent Work Atlas:
Overview
One annoying thing having a guard model is ensuring its FP rate is low enough to not be a headache, and its FN rate low enough to be worthwhile to use.
Workflow
One annoying thing having a guard model is ensuring its FP rate is low enough to not be a headache, and its FN rate low enough to be worthwhile to use. Likely also means you’ll need to either use a frontier-close model, further increasing costs as well as round-trip time.Or maybe some system 1 model?For my setup, i have claude code in its own VM, whose VLAN is heavily restricted outside of the internet, my forgejo instance, infisical for secrets, and one way SSH from my machine to the VM.All secrets are shared via infisical secrets store, so the actual secrets are never shown to the agent. Dev mode can be used for running the system locally during development, and those secrets may be seen in some cases. The foregjo user the agent has access to can only create issues and PRs. Manual merge required, after which a CI pipeline handles the packaging and “production” deployment of the app to my app server VM.I think a setup like that (or discouraging these agents access to the same computer people keep their finances/health data etc) should be discussed/championed more.My work encourages just running the harness on their system (which I get for practical reasons among others), to which I then put my work laptop on its own VLAN.Overkill, for sure. But to me the risk of personal data exfiltration is far too high with these vibe coded harnesses and models which are more and more opaque.
Reported result
The source does not report specific measured outcomes, such as error rates or time savings. It describes the setup as a risk mitigation strategy against data exfiltration from opaque AI models. A measurable acceptance check would be verifying that no secrets appear in agent logs and that unauthorized merges are blocked by the CI pipeline.
Human role
The original post does not say how a person stayed involved.
Limitations
This architecture requires significant infrastructure overhead, including separate VMs, VLAN configuration, and secret management tools. The author notes that guard models may increase costs and latency. Integration uncertainty exists regarding how well this setup scales for larger teams or complex dependencies. Human approval is mandatory for every deployment.
Try it
I need to set up a secure development environment for an AI coding agent. Please configure a new VM with a restricted VLAN that only allows outbound traffic to the internet, my internal Forgejo instance, and Infisical. Install Claude Code on this VM. Set up Infisical to inject secrets into the environment without exposing them to the agent's context. Create a Forgejo user with permissions limited to creating issues and pull requests only. Configure the CI pipeline to require manual approval before merging any PRs. Before applying this to the main project, run a dry test: ask the agent to create a simple 'Hello World' PR. Verify that the PR is created, that no secrets are visible in the agent's output, and that the merge requires my manual confirmation. If any step fails or secrets are leaked, stop and report the error. Do not proceed to real code changes until I confirm the dry run was successful.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.