Vibe coding security: the checks between a prototype and production

Vibe coding security comes from checks that the author of the code did not write and the agent cannot change. The Cloud Security Alliance's guide says that "AI-generated code isn't inherently secure". OWASP asks teams to verify AI output "independently of whether the AI followed its instructions". SHIP runs these checks today on every mission. Keys stay outside the agent's sandbox, your CI and a Reviewer gate each change, and QA tests it on a preview. A workspace where product and design teams vibe code with SHIP is in early access.

Know the risks the security guides name

Two guides that rank for this question agree on the main risks. The Cloud Security Alliance's Secure Vibe Coding Guide, written by Ken Huang and published on April 9, 2025, starts with the person. It says vibe coding often means that you accept code you do not fully understand. Its checklist then says: "Never embed API keys, secrets, database passwords, or other sensitive information directly in your code". It also asks you to validate every input, restrict CORS and have human reviewers read critical code.

OWASP SAMM's guidance on AI-assisted development starts with the organization. It lists these risks for a team that lets AI write code:

• Source code, secrets or personal data that reach AI providers.
• Insecure or unmaintainable generated code.
• Dependencies an AI tool suggests that do not exist, or that are malicious. OWASP notes that "AI tools may suggest packages that do not exist", and attackers then publish packages under those names.
• Agents with excessive privileges on repositories, pipelines or environments.
• Prompt injection, which OWASP defines as "instructions hidden in content that AI tools read, such as issues, documentation, dependencies, or web pages."

OWASP also names a risk that grows with speed. In its words: "When the rate of change grows faster than the organization's ability to verify it, risk accumulates silently". Vibe coding raises the rate of change, so the checks must run on every change without a person in each loop.

Map each risk to a check before production

Each risk above has a check that sits between the generated change and production. The table lists them, and the last column says what SHIP runs today, from the SHIP docs.

SHIP has no security scanner of its own. A security review on every pull request is in early access. Today, your CI runs the scanners you already trust, and SHIP treats a failed check like any other failed gate.

Keep secrets out of the agent's reach

OWASP's advice on secrets is direct: "Handle AI tools as a potential attacker". It also says that "AI tools must never have access to secrets other than development-grade secrets, whether through code, configuration files, environment variables, or prompts".

SHIP applies that rule to the keys an agent needs to work. Each agent's container starts with a placeholder instead of the real key. When the agent calls its model provider, SHIP adds the real credential to the outbound request, outside the container (LLM credentials). The key is never in the container's environment or on its filesystem. If SHIP does not replace the placeholder, the provider rejects the call, so the design fails closed.

The same rule covers the tools an agent calls. A remote MCP server gets its credential outside the sandbox, as MCP servers for coding agents explains. Each sandbox also gets a scoped, single-use callback token, and SHIP keeps the real keys (SHIP docs).

A hardcoded secret in the generated code is a different problem, because the agent writes it into the diff. Run a secret scan in CI so that the gate catches it. Then add a line to .ship/agents/reviewer.md that tells the Reviewer to block any credential in the diff (Agent prompts).

Gate every change with checks the agent cannot edit

OWASP warns that "tampered instructions silently weaken every change an AI tool produces". The fix is to read the rules from a branch the change cannot edit. SHIP reads the Reviewer's and QA's instructions from your main branch, never from the branch of the pull request. So a pull request cannot change the rules for its own review (Agent prompts).

The same applies to the other settings a change could try to weaken:

• SHIP reads the retry limits from ship.yml on main (Retry limits).
• SHIP reads the sandbox definition from your default branch, so a pull request cannot change the sandbox that reviews or tests it (Sandboxes).
• SHIP checks every change before the commit exists. It blocks a change under .github/workflows/ that you did not ask for (Connect GitHub).

Your CI is the first gate. When it fails, the Builder gets the failure back and works on a fix. Then the Reviewer compares the diff with the plan and reports the findings that block the change and the ones that do not. Add your team's security rules to .ship/agents/reviewer.md, for example a rule that every new dependency needs a reason in the pull request.

Test the live app before anyone merges

A diff can pass review and still fail on a live app. SHIP asks your own delivery pipeline to deploy each pull request to a preview, with the secrets your pipeline already has. SHIP never holds a credential for your cloud account (Deployments).

QA then tests the acceptance criteria against that preview and collects proof of what it checked. QA holds a read-only token, so it cannot push. With no preview configured, QA builds and serves the app in its own sandbox and tests it there.

If a gate fails, the feedback goes back to the Builder and the mission continues. A stage that finishes leaves a record, and its sandbox no longer exists (Human in the loop).

Decide who merges and when a run stops

The Cloud Security Alliance's guide asks for human reviewers on critical code. OWASP adds: "Whoever accepts AI output remains accountable for it". In SHIP, the pull request waits for a person by default. Auto-merge is off unless you turn it on for a project or a mission.

Checkpoints add more places for a person to decide. A checkpoint on the Planner holds the mission after the plan, and a checkpoint on the Reviewer holds it after the review:

agents:
  planner:
    checkpoint: true
  reviewer:
    checkpoint: true

Limits stop a run that nobody watches. A single mission stops at $5 by default. A mission also pauses at 2 credits, or 6 agent-hours, until a member of your organization approves more (LLM credentials). After two rounds where a gate fails the same way, the mission shows Needs attention and the pull request stays open (Retry limits).

SHIP records every agent run. Before an agent reports back, SHIP stores its full session, the assembled prompt, the token usage and the cost, per mission and per stage.

Open vibe coding to people outside engineering

OWASP tells teams to give developers approved AI tools early, so that fewer people use tools nobody approved. The same logic applies to product and design teams who already vibe code. A prototype that goes through your review and deploy pipeline is easier to trust than one built outside it.

Today, a teammate outside engineering can write the idea as an issue in Linear or GitHub Issues and assign it to SHIP. Every check on this page then runs on the prototype, and engineering merges the prototypes it wants to keep. A workspace where people outside engineering describe and change prototypes directly is in early access, on the governed prototyping page.