DEV Community: SPOE

Is AI-generated code safe to ship? What to check, and what a second AI catches

SPOE — Wed, 14 Oct 2026 22:18:13 +0000

Originally published on the SPOE blog.

AI-written code usually works. Whether it is safe is a different question, and the answer depends less on the model than on what checks the code before it reaches your users.

The good news: the mistakes are predictable. The same handful turn up again and again, and most can be caught without you reading a line of code.

The mistakes that matter

A secret in the code. An API key, a database password or a payment key pasted straight into a file. Once that file is in a public repository or shipped to a browser, anyone can use the key. This is the most common and the most expensive.

Database queries built from text. When the code glues what a user typed into a database query instead of passing it separately, a crafted input can read or delete data that is not theirs. The fix is boring and standard: parameterised queries.

Routes that change data without asking who you are. A page or endpoint that deletes a record or changes a price, open to anyone who finds the address.

Raw HTML from users. Showing something a visitor typed as HTML lets them run their own script in other people's browsers.

Cookies accepted from any site. A loose setting that lets another website act as your signed-in user.

Pages search engines cannot read. Not a security hole, but an AI-built site often ships without a title, a description or a sitemap, and then nobody finds it.

Why the same AI should not check its own work

Ask the model that wrote the code whether it is safe, and it tends to agree with itself: it shares the blind spots that produced the mistake. A reviewer from a different model family reads the change fresh, with different habits and different training. It is the same reason a writer does not proofread their own book.

What SPOE does

A second AI reviews every change. Every change the builder makes is reviewed by a model from a different family before it reaches your project. If the review finds something serious, the change waits for you in a side-by-side diff instead of going in, and one click sends the findings back to be fixed. A review that times out or fails is never treated as a pass.

Check before you ship, free. The Check button runs a scan with no AI and no credits: keys in the code, SQL built from text, raw HTML, cookies accepted from any site, routes that change data without sign-in, and what search engines will miss. A critical finding holds a publish until you decide, and that decision is recorded. The same check ships inside every export as check.mjs, so you can run it on your own machine, or in your own CI, for as long as the app lives.

Secrets stay out of the code. Keys you add go into the project's vault, sealed, and reach your app's server as environment variables. The builder is told the names of your keys, never their values.

Every change is a version. If something slips through, you roll back in one click.

What is still your job

No checker finds everything. Before you put real customers' data in an app, built by AI or by people:

Click through every page signed out, and try to reach what you should not.
Try the forms with nonsense, very long text and odd characters.
Look at what the Check finds and fix the critical ones.
Keep keys in the vault, never in a message to the builder.
Have someone technical read the parts that handle money or personal data.

AI makes building fast. Checks are what make it safe to ship. Start free and run the Check on your first build, or read how SPOE compares with other builders.

The one test that proves no user can see another user's data

SPOE — Tue, 13 Oct 2026 04:46:08 +0000

Every multi-tenant app has the same nightmare bug: a route that forgets to check who owns the thing it returns. One missing where owner_id = ? and user B can read user A's projects by changing an id in the URL.

Code review doesn't reliably catch it. Neither do the tests most of us write, because we test the routes we remember, and the leaky one is always the route we forgot.

So I stopped writing per-route authorisation tests and wrote one test that walks every route the API has.

The idea

Collect every route the server registers, automatically.
Make two accounts. Alice creates real data: a project, a file, a secret, an API key.
For every route that takes an id, call it as Mallory using Alice's ids.
Every single one must answer 404 (not 403, which confirms the thing exists). With no session at all, every one must answer 401.
The only exceptions are routes that show something an owner chose to publish, and each exception is written down with its reason.

A route added next month that forgets the owner check fails this test on day one, without anyone remembering to test it.

Collecting the routes

In Fastify there is a hook for exactly this. Register it before your routes:

const routeList: { method: string; url: string }[] = [];
app.addHook('onRoute', (r) => {
  for (const m of [r.method].flat()) {
    if (m !== 'HEAD' && m !== 'OPTIONS') routeList.push({ method: m, url: r.url });
  }
});
app.decorate('routeList', routeList);

In Express 4 you can walk app._router.stack; most frameworks have an equivalent.

The test

const SHARED: Record<string, string> = {
  'GET /showcase/:id': 'an app its owner shared publicly',
  'GET /shared-chats/:slug': 'a chat its owner published with a link',
};

const withIds = routes.filter((r) => /:|\*/.test(r.url));

// Alice's real ids wherever a route names one of hers.
const fill = (url: string) => url
  .replace(/^\/projects\/:id/, `/projects/${project.id}`)
  .replace(':gid', generation.id)
  .replace(':name', 'ALICE_KEY')
  .replace(/:id/g, randomUUID())
  .replace('*', 'web/secret.ts');

const leaks: string[] = [];
for (const r of withIds) {
  const id = `${r.method} ${r.url}`;
  if (SHARED[id]) continue;
  const url = fill(r.url);
  const res = await app.inject({ method: r.method, url, cookies: mallory.jar, payload: plausibleBody(r.method) });
  if (res.statusCode !== 404) leaks.push(`${id} as another account: ${res.statusCode}`);
  if (res.body.includes('alice only')) leaks.push(`${id} showed Alice's data`);
  const anon = await app.inject({ method: r.method, url, payload: plausibleBody(r.method) });
  if (anon.statusCode !== 401) leaks.push(`${id} with no session: ${anon.statusCode}`);
}
expect(leaks).toEqual([]);

Two details matter more than they look.

Send a plausible body. If a route validates the body before it checks ownership, an empty body gets a 400 and the test learns nothing about the owner check. Give every request a body that would pass validation, so the 404 you get back is the owner check speaking.

Collect leaks, then assert once. A list of every failing route is far more useful than the first failure. On my codebase the list was empty, which brings me to the part most people skip.

Prove the test can fail

An empty list is only good news if the test can actually catch a leak. So I broke one route on purpose: I removed the owner check from the route that lists a project's secrets, and ran the test again.

- "GET /projects/:id/secrets as another account: 200 {"secrets":[{"name":"ALICE_KEY"...

It failed, naming the route and showing the leaked secret names. I put the check back. Now I trust the green.

The lists of "mine"

Routes without an id leak too: /me/projects, /me/exports, /me/api-keys. A second test signs in as Mallory and checks that none of those responses contain Alice's ids, email or names anywhere in the JSON.

What it costs

76 routes with ids, two requests each, about 400 ms with Fastify's inject. It runs with the rest of the test suite before every commit.

I built this for spoe.ai, an AI app builder where people prompt full-stack apps and export the code. When an AI writes a lot of your routes, "we'll remember to test authorisation" stops being a plan. A test that walks every route does not need anyone to remember.

If your app has more than one user, steal the idea. It's an afternoon of work and it closes the most common serious bug in multi-tenant software.

Every change our AI app builder makes gets a second model’s review. A timeout is never a pass.

SPOE — Sat, 10 Oct 2026 10:13:58 +0000

I'm building SPOE, an AI app builder. You describe an app, a model writes it into a real Next.js, Fastify and Postgres project, and you can export the whole thing. Last time I wrote about how every export is signed. This post is about the other half: nothing the builder writes reaches your project until a second model has read it.

Why a second model, and why a different family

A model reviewing its own output tends to like it. Two sizes of the same model family share training data, so they tend to share blind spots too. So the rule is that the reviewer must come from a different model family than the writer.

That rule lives in code, not in a doc. The server reads the family off each model's id (Qwen, GLM, Llama, DeepSeek, Mistral and so on). If it can't tell, the operator has to state it. If the writer and the reviewer turn out to be the same family, the server refuses to start:

if (g === r) throw new Error(
  `Reviewer and generator are both "${g}" family. The security review must use a different model family.`
);

If you pick your own model for building, the reviewer is chosen from a different family than that one too. Both run on Venice's private, zero-retention inference.

What the reviewer sees

It gets two things: the original request and the proposed diff. Its instructions open with "You are a security reviewer. You did not write this code."

It looks for, roughly in this order:

Critical: injection, auth that can be bypassed, secrets in code, arbitrary file access, one user reaching another user's data. Also any import of an SPOE package, because the export has to run without us.
High: missing validation at the edges, weak crypto or password storage, SSRF, path traversal, XSS.
Medium: missing rate limits on auth, error messages that leak, insecure defaults.

It answers in JSON at temperature 0: a verdict, and findings that each name a file, a line, the problem and the fix.

Don't trust the model's own summary

A model will happily list a critical finding and then write "verdict": "pass" underneath it. So the verdict is worked out again on our side, from the findings:

const verdict = findings.some((f) => sev(f) === 'critical') ? 'block'
  : parsed.verdict === 'pass' && findings.some((f) => ['high', 'medium'].includes(sev(f))) ? 'warn'
  : parsed.verdict;

A critical finding blocks the change, whatever the reviewer wrote. A blocked change can't be approved at all. You regenerate, and the findings go back to the writer word for word as a checklist.

A timeout is never a pass

This is the rule I care about most. When a review errors, times out or returns something that doesn't parse, the easy move is to let the change through. SPOE doesn't. A network or provider hiccup gets one retry. After that, the change comes back marked as not reviewed, with a note in plain words saying exactly that. Approving it takes an explicit "I know this is unreviewed", and that approval goes into the audit log.

Fast, without skipping the check

At first, every change waited for a human in a diff view. Safe, and slow. Now, with auto-apply on (the default), a change the review passes goes in by itself, as a version you can undo in one click.

Four kinds of change never apply themselves: a blocked one, an unreviewed one, one with a high or critical finding, and one whose files you edited by hand since it was written. Those wait in the diff view for you. A manual edit is never silently overwritten.

Where it falls short

A second model is not a security audit. It catches common, obvious mistakes. It will miss subtle logic bugs, and it can be wrong in both directions.
It reads the diff and the request, not the whole running system.
Calibration never ends. A reviewer that calls everything critical gets ignored, so its instructions spell out what critical means: a human must not merge this, full stop. A missing rate limit is not that.
Two families can still share blind spots. Different beats same. It is not a guarantee.

Try it, and tell me where it breaks

SPOE is at spoe.ai. You get 50 free credits to start, a build costs roughly 10 to 30, and your first payment of any size unlocks export for good.

I'd like to hear where you think this review would fail. What would you want it to catch that it doesn't?

We sign every export our AI app builder produces. Here's how it works

SPOE — Sat, 10 Oct 2026 01:49:26 +0000

I'm building SPOE, an AI app builder. Every tool in this space says "you own your code". I wanted to be able to prove it, so every export SPOE produces is signed. This is how that works, in enough detail that you can poke holes in it.

The problem

When an AI writes your app, two questions follow the code around. Is this exactly what I was shown? And does it quietly depend on the tool that made it? A ZIP answers neither.

What's in an export

Three files ride along with every project: PROVENANCE.json, PROVENANCE.sig and verify-provenance.mjs.

PROVENANCE.json lists every file with its SHA-256 and size, a hash over the whole tree, which models wrote and reviewed the changes (never the prompts), and the signer's public key:

{
  "spoe_provenance": "1",
  "project": { "slug": "tint-booker", "stack": { "frontend": "nextjs", "backend": "node", "database": "postgres" } },
  "version": { "number": 2 },
  "files": [{ "path": "web/app/page.tsx", "sha256": "9f2c…", "bytes": 1834 }],
  "tree_sha256": "41ad…",
  "generations": [
    { "role": "generator", "model": "…" },
    { "role": "reviewer", "model": "…" }
  ],
  "signer": { "alg": "ed25519", "key_id": "c85280961cc26721", "public_key_pem": "-----BEGIN PUBLIC KEY-----…" }
}

The signature in PROVENANCE.sig is Ed25519 over a canonical form of that JSON: keys sorted recursively, no whitespace. The tree hash is SHA-256 over the sorted lines path\0sha256\n, so the order files happen to be zipped in never matters. The key id is the first 16 hex characters of the SHA-256 of the public key's DER encoding.

Verifying it

The verifier is about 40 lines of plain Node 18+, with no packages and no network:

$ node verify-provenance.mjs
OK   signature valid (key_id c85280961cc26721)
OK   30 files match manifest
VERIFIED - exported 2026-10-09T01:24:13Z from project tint-booker v2

It checks that the key id matches the embedded key, that the signature is valid, that every listed file is on disk with the right hash, and the tree hash. It exits 1 if anything is off.

A valid signature only tells you the files match a key. To know who signed it, compare the key id with the keys spoe.ai publishes at spoe.ai/api/signing-keys. The page at spoe.ai/verify does all of this in your browser without uploading the ZIP, and also lists any file in the ZIP that the manifest doesn't know about. The offline script now does that same check too.

"Runs without us" is a test, not a promise

Before an export is signed, a lint refuses it if anything ties it back to SPOE: an import of an SPOE package, a dependency on one, code reading SPOE_* environment variables, a call to SPOE's API, or one of our internal folders. No warnings, no override.

And CI does the whole thing on every commit: export the scaffold, unzip it into an empty directory, verify the signature, docker compose up, hit the health check. If that fails, nothing ships.

The other half: a second model

Every change the builder makes is reviewed by a second model from a different model family before it lands. A critical finding blocks the change whatever the reviewer's own verdict says, and a review that times out or errors is never treated as a pass: it waits for a human.

What it doesn't prove

A signature proves integrity and origin, not quality. It can't tell you the code is free of bugs or safe to run; the review and your own eyes are for that. It also says nothing about the prompts, which are deliberately left out of the manifest.

Try it, and tell me what's wrong with it

SPOE is at spoe.ai. It's free to start (50 credits on sign-up and a daily top-up), runs on Venice's private models, and your first payment of any size unlocks export for good.

I'd especially like critique of the manifest format and the verifier. What would you need to see before you trusted an export from a tool like this?