Using the CSA Secure Vibe Coding Guide to Set System Boundaries

What the CSA Secure Vibe Coding Guide actually covers

Vibe coding, as the guide defines it, is an AI-assisted programming approach where users describe their software requirements in natural language, and a large language model generates the corresponding code. The guide organizes its advice into eight sections rather than one unified checklist.

Application security covers encryption, CI/CD scanning, and least privilege, stated plainly as grant users only the necessary permissions to perform their tasks, don't give everyone admin access. API security covers HTTPS, authentication, and rate limiting. GitHub security covers two-factor authentication, dependency management, and access control. Database security covers parameterized queries, encryption, and limiting database permissions to necessary operations only, with regular audits to revoke what is unused.

The sixth section maps onto the OWASP Top 10 for LLM Applications, the seventh focuses on cloud deployment with Vercel named specifically, and the eighth, the human factor, is about hiring the right expertise and continuous learning rather than a technical control at all. The guide's own closing line is that security is not a one-time fix; it's an ongoing process.

• Published April 9, 2025, by Ken Huang, a CSA Fellow.
• Eight sections: fundamentals, AppSec, API, GitHub, database, OWASP LLM Top 10, cloud deployment, human factor.
• Mostly application security hygiene, written for teams shipping AI-generated code.

The guide's one sentence about sandboxing

Searching the full text for sandbox, isolated environment, boundary, or container turns up exactly one direct hit. Under LLM04, data and model poisoning, the guide's mitigation reads mitigate by implementing sandboxing and anomaly detection. It does not say which sandbox, how to configure one, or what counts as contained.

The closer match to what most people mean by system boundaries is LLM06, excessive agency, where the guide recommends minimizing extensions, limiting permissions, and requiring human approval for high-impact actions. That is a real, specific instruction, it is just a policy statement rather than a how-to.

If you came to this page wanting the guide's own steps for containing an agent at the operating system level, there are not many to follow. What it is actually asking for, least privilege plus a contained execution environment, has to be built with separate tools, which is what the rest of this page does.

• Sandboxing appears once, as a one-line mitigation under LLM04.
• Excessive agency (LLM06) asks for limited permissions and human approval on high-impact actions.
• Neither section tells you which tool to use or how to configure it.

The write boundary: confine the agent to the project

The least privilege principle the guide states for user permissions applies just as directly to an agent's write access. On macOS, both Claude Code and Codex CLI build their sandboxes on Seatbelt, the framework behind the operating system's own App Sandbox, and both confine writes to the project folder and a temp directory once their sandbox is turned on.

Claude Code's is off by default; you turn it on with /sandbox. Codex CLI picks one of three modes up front: read-only, workspace-write, or danger-full-access. If your agent has neither, sandbox-exec, the command line tool macOS ships with, lets you apply the same kind of profile to any command, though Apple's own man page has marked it deprecated since OS X 10.12 and it still works on current releases.

A dedicated guide on this site walks through all four approaches in more depth than fits here.

• Claude Code: /sandbox, off by default, Seatbelt-based.
• Codex CLI: read-only, workspace-write, or danger-full-access, chosen up front.
• sandbox-exec: apply a Seatbelt profile to any command, deprecated label, still functional.

The read boundary: keep credential files out of view

This is the part the least privilege line is actually pointing at, and it is easy to get wrong because turning on a sandbox feels like it should cover reads too. It often does not. Claude Code's own documentation states that, inside its sandbox, reads reach most of the machine by default, including credential files such as ~/.ssh and ~/.aws/credentials. What the sandbox fences by default is writes and network, not reads.

Closing that gap takes an explicit deny rule, such as Claude Code's filesystem.denyRead setting, or a credentials rule that scrubs environment variables before a sandboxed command inherits them. The guide's least privilege instruction does not happen automatically just because a sandbox exists.

This is the single most overlooked gap in a secure vibe coding setup: people turn on a sandbox, assume their SSH keys are now invisible to the agent, and never check.

• A sandbox being on does not mean credential files are hidden by default.
• Check your specific tool's read-deny or credential-scrubbing setting explicitly.
• Test it: ask the agent to cat a file under ~/.ssh and confirm it is actually blocked.

The permission boundary: human approval for high-impact actions

LLM06's require human approval for high-impact actions maps directly onto the approval mechanisms different tools ship. Claude Code's regular permissions mode prompts before a command runs; Cursor offers a dial from a full prompt to zero prompts; cloud-hosted agents like GitHub Copilot's coding agent gate at a pull request instead, because the work never touches your machine in the first place.

None of these are named in the CSA guide. The guide states the requirement; which mechanism satisfies it is a choice you make per tool.

A full comparison of how these approval mechanisms actually differ is covered in a separate guide rather than repeated here.

• LLM06 asks for human approval on high-impact actions; it does not specify the mechanism.
• Local tools: a permission prompt or a dial. Cloud agents: a pull request gate.
• Pick the mechanism that matches where the agent actually runs.

What the guide leaves to code scanning, not sandboxing

A boundary around execution does not catch a vulnerability the agent wrote into the code itself, which is a different layer the CSA guide's AppSec and database sections are really aimed at. Snyk Code is a static analysis tool built for exactly that: it scans code, including code an AI agent wrote, for known vulnerability patterns, and runs in the IDE, in pull requests, and in CI. Snyk's own newer platform, Evo, is positioned specifically for agentic development, covering what an agent connects to and what it generates.

None of that is a sandbox, and it does not stop an agent from running a command. It is a second door that closes a different kind of risk than a filesystem boundary does.

An enterprise working through this guide's checklist needs both: a boundary that contains what the agent can touch while it works, and a scanner that checks what it produced before it ships.

• Snyk Code: scans AI-generated code for known vulnerabilities, in the IDE, PRs, and CI.
• It complements a sandbox; it does not replace one.
• Pair a write/read boundary with a scanner in the merge path.

Where Forkbench fits

Forkbench is a desktop app that runs coding agents in real terminals on a Mac. A Thread can be locked to its folders using the macOS kernel sandbox, so ~/.ssh, other repositories, and Documents stay shut, which is a direct answer to the read boundary the CSA guide's least privilege line asks for, and it works with any agent you run in its terminals, including ones with no sandbox of their own.

Its Vault keeps secrets in the Keychain and lets a command use one by name without the value reaching the prompt or the transcript, which answers a chunk of the guide's AppSec concern about hardcoded secrets.

The limits are the same ones stated everywhere on this site: the folder lock is opt-in and does not restrict the network, and an unpinned Vault key can still be read by the program that was run with it. Forkbench does not claim compliance with the CSA guide; it independently covers some of what the guide gestures at.

• Folder lock: opt-in, macOS kernel sandbox, closes the read gap the guide's least privilege line asks for.
• Vault: secrets stay in the Keychain, used by name.
• Network traffic is untouched by either control, and a key handed to a running program stays readable by that program.

A boundary checklist mapped to the guide's own sections

Working through the CSA guide's own structure, with the tooling it leaves out filled in, looks like this.

None of this makes a team compliant with anything; the guide itself is not a compliance standard, it is a published set of recommendations. It is a reasonable starting checklist for a team that wants to take vibe coding security seriously rather than guess at it.

• Fundamentals and AppSec: no hardcoded secrets, inputs validated, a vault instead of a .env file.
• LLM04 and LLM06: a write and read boundary around the agent, plus a human approval step for risky actions.
• AppSec and database sections: a scanner such as Snyk Code in the pull request path.
• Human factor: someone on the team actually owns this list and revisits it, since the guide calls security an ongoing process, not a one-time fix.