Keep customers’ data apart. Our first check missed a leak. Here is how it got fixed.

1 · You

You type one sentence.

Open your coding agent in a small task service that has almost nothing in it. Type: add tenant isolation to this task service: two customers share it, and neither may ever see the other’s tasks.

That is the whole request. Without a recipe, an agent adds a customer column and a filter from memory, and nothing says it covered every path. One forgotten path is a data breach.

A tenant is one customer of a service that many customers share. Tenant isolation means one customer can never read or change another customer’s data, not even by mistake.

2 · Your agent

Your agent asks MM3 how.

You do nothing. Your agent sends your sentence to MM3 and a recipe comes back. It works out the language by itself, from package.json.

The one rule that matters: every read of customer data goes through one doorway that knows who is asking, and the customer is taken from the login, never from what the request says.

The recipe leans on two OWASP documents, both quoted below. The five rules and the parts are our reading of them, and the recipe says so.

3 · Your agent

It writes the code, then runs it.

Still nothing for you to do. The agent writes the four files the recipe names. The type checker is happy. Then it runs the app: tenant A creates “write report”, tenant B creates “book flights”, and each sees only its own.

The honest wrinkle. The first run crashed. The type checker said fine, but Node strips types without removing the imports, so two type-only imports failed at start-up. The recipe says to use .ts imports but not import type. The agent changed two lines and re-ran, and we logged the gap so the recipe can be fixed.

4 · MM3

MM3 checks it.

You say yes to one paid check (we said yes, once). The result, run MM3-0389: pass.

The check is a fixed list of 12 questions: 9 yes/no, one overall goal, two judgement calls. The panel shows three. A score is how sure the checker is that the code is healthy on that line. For the last one, the healthy answer is no: “is there any function that hands back unfiltered rows?”

The questions are locked with a fingerprint, so nobody can reword them to make a result come out better. The check cost about $0.00007 (estimated from tokens).

5 · Over time

But would it catch a leak? Our first check did not.

A check that passes good code proves little. So on an earlier test day we put a leak into a Go copy on purpose: one extra function that returns every task, with the comments that said otherwise removed. Our first question was blunt: “Is it impossible for one tenant to read or change another tenant’s task?”

MM3 said unsure (MM3-0122), and the overall goal still read pass. A leak got through as a shrug. We logged it as feedback; a script turns that log into a proposed change and a person approves it.

The fix: stop asking about the whole data layer and ask about the exact thing. The new question caught that leak. We should have stopped there. Instead we planted every rule in two languages, and the first fix missed six more. The third version caught 15 of 15.

6 · Try it

Is it just saying yes? Add one function.

To check the sharpened check on the app this agent just built, we copied it and added one function to the data access file: it returns every task in the store. Same style, a neutral name, in a folder with no label. Flip the switch to do it yourself.

The result is fail (MM3-0390). The marked question flips, and Q6 (“does every operation require the tenant context”) drops too, while Q5 stays high: the original list function still filters. And look at the overall goal: it still reads pass (0.83). The headline number did not see the leak. The pointed questions did.

// Data access: the only code that reads or writes tasks.// Every operation requires the tenant context and filters or stamps by its tenant.import { TaskStore, type TaskRow } from "../store/task-store.ts";import type { TenantContext } from "../tenancy/context.ts";export function create_task(store: TaskStore, ctx: TenantContext, title: string): TaskRow {  return store.insert(ctx.tenant_id, title);}export function list_tasks(store: TaskStore, ctx: TenantContext): TaskRow[] {  return store.rows().filter((row) => row.tenant_id === ctx.tenant_id);}

7 · Try it

Pick your language.

The same questions work in any language, because they ask about roles (the doorway, the handlers, the store), not one language’s syntax.

Pick one. The panel swaps in that app’s real data-access file and its real result. TypeScript is the run made for this page; Go and Python are recorded runs from the earlier test day, where the leaky function was planted by hand. In Go the extra function got only unsure, not a clean fail (MM3-0182): we count it as flagged, but it is the weakest of the fifteen.

8 · The result

What it comes to.

One sentence from you. A recipe built on OWASP. Working code that keeps two customers apart. A verdict you can read: yes to the good copy, no to the copy with a leak. And the quiet part that matters most: the check got better because we kept trying to fool it.