You built it with AI. Is it safe? Check it, and keep the proof.

AI writes the app in an afternoon. Nobody checks what it actually shipped. The builder, often not a career programmer, gets a working demo and a summary that says everything is fine. What the summary cannot tell them: whether a key got committed, whether errors are being swallowed silently, whether there are any tests at all. Zambo is the verifiable work layer for AI, and the instruments for this problem are its audits: provibe_audit scans a public repository for the signals AI-written code leaves, ghost_audit_site audits the live site, and every audit returns a verifiable receipt, so "I checked it" becomes a record anyone can recompute.

Worked example: one live audit, checked the way a skeptic checks it

On October 16, 2026, provibe_audit ran against a public repository of 319 files (github/gitignore, a small stand-in any reader can open). The findings, in the audit's own counts: suspected secret leaks 0, empty catch blocks 0, asynchronous calls without error handling 0, type-checker escapes 0, placeholder shortcuts 0, and one finding a demo would never mention: no test files found. The audit scored the run 87 on its result badge, and the full report sits at the audit result page. The proof it ran: receipt 86075ecf-408a-47e8-9ab4-c94b672e2b80, and the public verify endpoint reports it verified, with the commitment, canonical payload, provenance binding, and metadata binding checks all passing.

Read the example at the right weight. Zero findings on the checked signals is evidence about those signals on that day, and the missing tests are the kind of fact the receipt makes impossible to smooth over later: it is in the saved result, and the saved result is what the receipt commits to. An audit whose findings you can recompute is worth more than a greener summary you cannot.

Hold one yourself: the live demo runs one real call and hands you its verifiable receipt, no signup.

Published October 16, 2026. Updated October 17, 2026. Written against AER-1, IETF Internet-Draft revision 23: draft-zambo-aer1-23. AER-1 is an IETF Internet-Draft, not a finalized standard.

Is my vibe-coded app safe?

The short answer. Safe is not one question; it is a list of checkable ones. Is anything secret sitting in the code? Do failures get caught, or do they vanish? Is there a test suite at all? Does the deployed site match what the code promises? Zambo runs those checks two ways: provibe_audit against the repository, and ghost_audit_site against the live site, each returning findings plus a verifiable receipt. You read the findings, fix what they name, and rerun. The receipt is what turns the loop into evidence: dated, saved, and recomputable by anyone you show it to.

Scope, stated once and applied everywhere on this page: a verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was correct, and an audit result is a saved result: the receipt proves the audit record is the one the run produced, not that the app passed anything beyond the checks the audit actually ran.

What goes wrong in AI-built code

  • Secrets in the open. A key or token pasted during a session ends up in a committed file, because the AI was optimizing for "it runs" and the builder never saw the file it landed in.
  • Errors that vanish. Empty catch blocks and calls with no error handling make the demo smooth and production silent: the failure happens, nothing records it, and the first report is a confused user.
  • No tests. The code was never asked to prove anything, so nothing in the repo can catch the next change breaking the one feature that matters.
  • Checker escapes. Type and lint suppressions sprinkled wherever the checker complained, each one a small decision to stop checking, made by the tool instead of the owner.
  • A site that drifted from its code. What is deployed is an older build, a different configuration, or a page outside tools cannot read the way the builder assumes they can.

None of these need a security team to find. They need one pass that looks for them by name and writes down what it found, which is the audit's whole job. The neighboring problem, an agent whose own work you cannot audit after the fact, is covered in Audit your agent.

Run the audit

  1. Connect your AI. Add https://zambo.dev/mcp (no key) to ChatGPT, Claude, Grok, Cursor, VS Code, or any MCP client.
  2. Audit the code. Ask for provibe_audit on your repository and read the findings by name: which signals fired, how many, and where. Fix what it names, in the open, and keep the before receipt.
  3. Audit the site. Run ghost_audit_site on the deployed address, follow it with ghost_audit_status, and read the report the run produces. Code and deployment are different facts; check both.
  4. Rerun and compare. The second audit is the evidence the fixes landed. Two receipts, before and after, say more than any summary of either.

Audits are calls like any other: free to try, with a Day Pass ($0.99 for 24 hours) lifting free limits and the Zambo Pass at $29/month or $290/year ($19/month for $ZAMBO holders) covering ongoing work. ProvibeCode audits carry no separate price. For the general pattern of checking work an AI produced, see AI agent record verification.

What an audit does not prove

It does not prove the app is safe. An audit checks the signals it knows how to check, on the day it ran, against the code and the site as they stood. It cannot prove the business logic is right, that a dependency will stay clean, or that tomorrow's deploy keeps today's findings fixed. That is not a weakness of the receipt; it is the honest shape of every inspection, and the receipt's job is narrower and more useful: the findings you were shown are the findings the run produced, unchanged, dated, and recomputable by the client, partner, or future you who asks whether anyone ever actually looked. Looking, on the record, beats reassurance, off it.

Questions, answered

How do I check if my vibe-coded app is secure?

Audit the code and the live site, and keep the receipts. Through Zambo, provibe_audit scans a public repository for the signals AI-written code tends to leave: suspected secret leaks, error handling that swallows failures, missing tests, placeholder shortcuts. ghost_audit_site audits the running site itself. Each audit returns its findings plus a verifiable receipt, so the check is a record with a date and a result, not a claim you make later. A clean audit is evidence about what was checked, not proof the app is safe; anything serious still earns a human review.

What does provibe_audit look for?

The working signals of AI-built code: suspected secrets committed to the repo, empty or missing error handling around calls that can fail, type and lint escapes used to silence the checker, test files present or absent, environment files committed, and similar tells. It reports counts and locations rather than a vibe of its own, and the whole audit is returned with a verifiable receipt (the worked example on this page is a real one, checked against the public verify endpoint).

What does ghost_audit_site check?

The live site rather than the code: ghost_audit_site requests your running site the way outside tools and AI crawlers see it and reports what it finds, with ghost_audit_status and ghost_audit_report following the run to its report. It answers the second half of the vibe-coded question: the code is one thing, what is actually deployed and reachable is another. Like every Zambo call, the audit returns a verifiable receipt.

Can I show a client or a partner that the audit actually ran?

Yes. The audit returns a verifiable receipt with a public link, and anyone can recompute its checks at the public verify endpoint without an account and without asking you. If the audit was one step in a larger delivery, hand the whole job over as one record: the hub guide on proof of delivery for AI work shows a client opening a handover, verifying every step in their browser, and accepting or flagging it.

Does a clean audit mean my app is safe?

No. An audit checks the signals it knows how to check and reports what it found on the day it ran. It does not prove the code is correct, the logic is sound, or the next deploy is clean, and a receipt over the audit proves the saved result was not changed since it was saved, not that the result was right. Treat a clean audit the way you would treat a passed inspection: real evidence about specific checks, and a reason to keep checking, not a reason to stop.

Related