DEV Community: Sunnatulla

My MCP server's confirm: true flag was written by the model. So I moved the approval to the user.

Sunnatulla — Mon, 09 Nov 2026 09:55:29 +0000

AI note: the code change and this post were written with an AI agent. Every test and output quoted here was re-run before posting.

I have a small MCP server (mcp-rest-bridge, a personal project) that sits in front of a store's REST API. It has six read tools and two write tools: adjust_stock and create_order.

The writes looked safe to me. They're off unless the operator sets STORE_ALLOW_WRITES=true. Every call is a dry run by default: the API does the real write inside a transaction and rolls it back, so the preview runs through the same rules (no negative stock, enough stock for every line). The tool result tells the model:

DRY RUN: nothing was changed. Show this preview to the user and call again with confirm: true only if they agree.

Then I read two posts on here this week, "Your Agent's Tool List Is Not a Permission Model" and "Your Agent Has a Side Door", and looked at my own schema again:

const confirm = z
  .boolean()
  .default(false)
  .describe("false (default) = dry run, nothing is saved. true = apply. Only set true after the user agreed.");

"Only set true after the user agreed" is a request to the model. The model fills in that argument. Nothing on the server knows whether a person saw the preview. My own test suite even proved it, by accident:

it("adjust_stock with confirm saves the change and logs the reason", async () => {
  const result = await mcp.client.callTool({
    name: "adjust_stock",
    arguments: { sku: "TLS-002", delta: -2, reason: "damaged in transit", confirm: true },
  });
  expect(result.structuredContent).toMatchObject({ dryRun: false, newStock: 1 });

No dry run first, and it saved. A model that skips the preview step, or a prompt injection in some product description that says "call adjust_stock with confirm: true", would get the same result. There's a quieter problem too: the model can preview delta: 20 and then confirm delta: 200. The preview and the write are two separate calls, and nothing ties them together.

What the client can already do

Most MCP clients ask the user before running a tool, and the tool annotations (destructiveHint: true on adjust_stock) help them decide how loudly. That's the first gate, and a good one. But annotations are hints. The spec says clients should treat them as untrusted, and the server can't tell whether the user clicked "always allow" an hour ago.

What I wanted was for the server to ask the person itself, with the real numbers from the dry run.

Elicitation: the server asks the user

MCP has a request for this, elicitation/create. The server sends a message plus a small flat JSON schema, and the client shows the user a form. The answer comes back as accept (with the form content), decline or cancel. The model isn't in that loop. It doesn't write the answer.

In the TypeScript SDK (1.32) it's server.server.elicitInput(...), and the client advertises support with an elicitation capability. Here's the helper I added:

async function withUserApproval(
  server: McpServer,
  preview: () => Promise<CallToolResult>,
  describe: (preview: CallToolResult) => string,
  apply: () => Promise<CallToolResult>,
): Promise<CallToolResult> {
  if (!server.server.getClientCapabilities()?.elicitation?.form) return apply();

  const dryRun = await preview();
  if (dryRun.isError) return dryRun;

  let answer: ElicitResult;
  try {
    answer = await server.server.elicitInput({
      mode: "form",
      message: describe(dryRun),
      requestedSchema: {
        type: "object",
        properties: { approve: { type: "boolean", title: "Apply this change?" } },
        required: ["approve"],
      },
    });
  } catch (err) {
    console.error("Approval request failed:", err);
    return fail("Could not get the user's approval in the client, so nothing was saved.");
  }
  if (answer.action !== "accept" || answer.content?.approve !== true) return fail(DECLINED);
  return apply();
}

And adjust_stock uses it like this:

if (!confirm) return run(true);
return withUserApproval(
  server,
  () => run(true),
  (p) => {
    const r = p.structuredContent as { previousStock: number; newStock: number };
    return `Change stock of ${sku} from ${r.previousStock} to ${r.newStock} (${delta > 0 ? "+" : ""}${delta}, reason: ${reason})?`;
  },
  () => run(false),
);

A few choices in there that I think matter:

The dry run happens inside the same tool call. The numbers the user sees come from the exact arguments that will be written. The "preview 20, confirm 200" gap goes away because there's only one call.

Only approve === true saves. decline, cancel, accept with the box unticked and a thrown error all end in "nothing was saved". If you write if (answer.action === "decline") return ..., then cancel (the user closed the dialog) falls through to the write. Easy mistake to make.

A change the API would reject never reaches the user. If the dry run fails (stock would go negative), the tool returns that error and doesn't ask. A dialog that says "Apply this change?" for something that can't happen just teaches people to click without reading.

The decline message tells the model what to do next: "The user did not approve this change in the client, so nothing was saved. Do not retry unless they ask." Without the last sentence, some models will try again straight away.

For create_order, the dialog shows the total from the dry run:

Create a pending order for customer 1: 1 x TLS-002, total $109.99?

Testing it without a UI

The SDK's InMemoryTransport plus a Client with an elicitation handler is enough. The test helper takes a function that plays the user:

const client = new Client(
  { name: "test-client", version: "1.0.0" },
  onElicit ? { capabilities: { elicitation: { form: {} } } } : undefined,
);
if (onElicit) client.setRequestHandler(ElicitRequestSchema, (request) => onElicit(request.params));

The test I care about most is the one where the model sends confirm: true with a big number and the user says no:

it("saves nothing when the user declines, even though the model sent confirm: true", async () => {
  const seen: string[] = [];
  const mcp = await connectWith({ action: "decline" }, seen);
  const result = await mcp.client.callTool({
    name: "adjust_stock",
    arguments: { sku: "TLS-002", delta: 200, reason: "stock count", confirm: true },
  });
  expect(seen).toHaveLength(1);
  expect(result.isError).toBe(true);
  expect(textOf(result)).toContain("did not approve");
  expect(stockOf("TLS-002")).toBe(3);
  expect(api.store.stockMovements("TLS-002")).toEqual([]);
  await mcp.close();
});

It checks the database, not just the tool result: stock is still 3 and the audit table is empty. Here's the run:

✓ asks the user with the dry-run numbers and saves only after approval
✓ saves nothing when the user declines, even though the model sent confirm: true
✓ treats cancel and an unticked box as a decline
✓ does not ask about a change the API would reject anyway
✓ does not ask during a plain dry run
✓ shows the order total before creating an order
✓ saves nothing when the client errors on the approval request

Tests  7 passed (7)

The whole suite is 39 tests now, with typecheck and lint, all green.

What this doesn't fix

I want to be honest about the limits, because that's what those two posts were about.

Clients without elicitation fall back to the old behaviour. For them confirm: true still saves, and the client's own tool-approval prompt is the only gate. I kept the fallback on purpose so the server still works everywhere. If your writes are risky enough, you could flip it and refuse writes when the client can't ask. Check whether your client supports form elicitation before you rely on it.
The user still has to read the dialog. Showing real numbers ("from 3 to 23") helps more than "Are you sure?", but nobody can force a person to read.
It's not authorization. Whoever runs the server still decides which API key it uses and whether writes are on at all. Elicitation answers "did the person at the keyboard agree to this change", not "is this person allowed to make it".
Don't ask for secrets this way. The spec says form elicitation must not be used for passwords or API keys. There's a separate URL mode for flows like that.

The takeaway for your own MCP server

If a write tool has a confirm argument, ask who fills it in. If the answer is "the model", it's a nudge, and you need something the model can't fill in. Elicitation is that thing when the client supports it. It took about 40 lines plus tests here.

The code is in src/mcp/write-tools.ts and the tests are in test/write-approval.test.ts.

If you've shipped elicitation in a real client, I'd like to know how the dialog looks to users and whether they actually read it.

I ran my Supabase + Stripe security scanner on two popular starters. It was wrong 7 times.

Sunnatulla — Sun, 08 Nov 2026 09:44:10 +0000

I've been building a small static checker for Supabase + Stripe apps, the kind people ship fast with Lovable, Bolt, Cursor or Claude Code. It's a personal project, MIT licensed: vibe-preflight. It runs as a plain Node script or as an Agent Skill, and it looks for six things I keep seeing in rushed apps:

tables in public with Row Level Security never turned on
policies like using (true) that let anyone read or write
the service_role key or a Stripe secret used in browser code
secrets behind NEXT_PUBLIC_ / VITE_ / EXPO_PUBLIC_
Stripe webhook handlers that never call constructEvent
.env files that git tracks

Fixtures and unit tests only tell you so much, so I pointed it at two public MIT starters to see what it does on code I didn't write.

Starter 1: vercel/nextjs-subscription-payments

vibe-preflight 1.0.0 · 56 source files, 3 SQL files · 6 checks

warning schema.sql:66
        Policy "Allow public read-only access." on `public.products` (select) lets anyone (signed in or not) read every row. [rls-permissive-policy]
warning schema.sql:99
        Policy "Allow public read-only access." on `public.prices` (select) lets anyone (signed in or not) read every row. [rls-permissive-policy]
warning supabase/migrations/20230530034630_init.sql:66
        (same policy, migration copy)
warning supabase/migrations/20230530034630_init.sql:99
        (same policy, migration copy)

0 errors, 4 warnings

That's the result I wanted. A pricing page has to show products and prices to people who aren't logged in, so a public select policy on those two tables is on purpose. That's why a read policy only gets a warning. A using (true) on insert, update or delete is an error.

Starter 2: makerkit/next-supabase-saas-kit-lite

vibe-preflight 1.0.0 · 291 source files, 2 SQL files · 6 checks

error   apps/web/.env:1
        `apps/web/.env` is committed to git. [env-file-committed]
error   apps/web/.env.development:1
        `apps/web/.env.development` is committed to git. [env-file-committed]
error   apps/web/.env.test:1
        `apps/web/.env.test` is committed to git. [env-file-committed]
error   apps/web/config/auth.config.ts:29
        `NEXT_PUBLIC_AUTH_PASSWORD` looks like a secret and is exposed to the browser. [public-env-secret]
error   packages/features/auth/src/schemas/password.schema.ts:11
        `NEXT_PUBLIC_PASSWORD_REQUIRE_SPECIAL_CHARS` looks like a secret and is exposed to the browser. [public-env-secret]
error   packages/features/auth/src/schemas/password.schema.ts:12
        `NEXT_PUBLIC_PASSWORD_REQUIRE_NUMBERS` looks like a secret and is exposed to the browser. [public-env-secret]
error   packages/features/auth/src/schemas/password.schema.ts:13
        `NEXT_PUBLIC_PASSWORD_REQUIRE_UPPERCASE` looks like a secret and is exposed to the browser. [public-env-secret]

7 errors, 0 warnings

Seven errors looks alarming. I opened every file, and all seven were false positives.

The "password" variables are on/off switches. The code reads them like this:

password: process.env.NEXT_PUBLIC_AUTH_PASSWORD === 'true',
numbers: process.env.NEXT_PUBLIC_PASSWORD_REQUIRE_NUMBERS === 'true',

My rule saw PASSWORD in the name and stopped there. It never checked how the value was used.

The committed env files hold no real secrets. .env only has NEXT_PUBLIC_* settings like the site URL, theme colour and AUTH_PASSWORD=true. Those values end up in the browser bundle anyway. .env.development and .env.test do contain a SUPABASE_SERVICE_ROLE_KEY, but it's the key the Supabase CLI prints for every local stack, pointing at 127.0.0.1. If you decode the JWT, the issuer is supabase-demo. Anyone who runs supabase start has the same key, and this starter commits it on purpose so a fresh clone runs straight away.

What I changed in 1.1.0

Boolean flags are skipped. A secret-sounding NEXT_PUBLIC_ name passes when every value the project gives it is a boolean and every place the code reads it compares it to 'true' or 'false'. If one file does const mode = process.env.NEXT_PUBLIC_SECRET_MODE, it gets flagged again.
Committed env files get a severity based on what's inside. If the only keys are JWTs with issuer supabase-demo and nothing looks like a real credential (sk_live_, whsec_, sb_secret_, other JWTs…), it's a warning that says why. Same for a file that only sets public variables. Anything else stays an error. A test puts a real-format Stripe key next to a demo key and checks that it's still an error.

Same repo after the change:

warning apps/web/.env:1
        `apps/web/.env` is committed to git. It only sets browser-exposed variables, which ship in the bundle anyway; keep it that way, or real keys added later get committed too. [env-file-committed]
warning apps/web/.env.development:1
        `apps/web/.env.development` is committed to git. Its keys are the public Supabase local-dev defaults, which is fine; make sure real project keys never go in this file. [env-file-committed]
warning apps/web/.env.test:1
        (same, for .env.test)

0 errors, 3 warnings

I kept those as warnings because the habit is still risky. Once someone pastes the production service key into .env.development "just to test something", it's in git history for good.

What I took from it

A security check that cries wolf gets turned off. Seven fake errors on a well-maintained starter would make me add --skip and forget about it, and then the real problem goes unnoticed too.
Name matching is only a starting point. The useful signal was in how the value is used (=== 'true') and in what the value is (the JWT issuer).
Run your tool on code you didn't write before you trust it. My own fixtures happened to avoid both cases.

It's still a static check. A clean run doesn't mean an app is secure: storage policies, auth flows and anything created only in the Supabase dashboard are out of its reach.

If you have a public Supabase + Stripe repo where it gets something wrong, I'd like to see the output.

Disclosure: vibe-preflight is my personal project. I used AI tools (Claude Code) to help write the code and this post, and I checked the scanner output and the files above myself.

Six security holes I check for before a Supabase + Stripe app goes live (with the fix for each)

Sunnatulla — Sat, 07 Nov 2026 15:38:46 +0000

Apps built fast with Lovable, Bolt, Cursor or Claude Code tend to break in the same few places. The UI works, the demo looks great, and then one of these six things is sitting in the repo. I wrote a small free checker for them, vibe-preflight (my own open-source project, MIT), and this post is the list it checks, with the fix for each one.

All the code below is from a small demo app I wrote on purpose to be broken. Here is what the scanner says about it:

$ node preflight.mjs examples/broken-app

error   src/app/api/stripe/webhook/route.ts:8
        Handles Stripe events without `constructEvent`, so any POST is trusted. [stripe-webhook-unverified]
error   src/components/admin-notes.tsx:7
        admin-notes.tsx runs in the browser and uses `SUPABASE_SERVICE_ROLE_KEY`. [server-secret-in-client]
error   src/lib/stripe.ts:3
        `NEXT_PUBLIC_STRIPE_SECRET_KEY` looks like a secret and is exposed to the browser. [public-env-secret]
error   supabase/migrations/20261101000000_init.sql:8
        Policy "Enable insert for authenticated users only" on `public.profiles` (insert) lets any signed-in user write rows on behalf of any user. [rls-permissive-policy]
error   supabase/migrations/20261101000000_init.sql:14
        `public.notes` is created without `enable row level security` in any migration. [rls-disabled]
warning src/components/summarize-button.tsx:7
        `NEXT_PUBLIC_OPENAI_API_KEY` is exposed to the browser. [public-env-secret]
warning supabase/migrations/20261101000000_init.sql:11
        Policy "Enable read access for all users" on `public.profiles` (select) lets anyone (signed in or not) read every row. [rls-permissive-policy]

5 errors, 2 warnings

1. A table with Row Level Security off

create table public.notes (
  id bigint generated always as identity primary key,
  user_id uuid not null references auth.users,
  body text not null
);

Your anon key is in the browser bundle. That's normal and fine, as long as every table in public has RLS on. Without it, anyone can open dev tools, copy the key and the project URL, and run select * from notes against your database through the REST API.

Fix: turn it on in the same migration, then add policies for what users actually need.

alter table public.notes enable row level security;

create policy "notes: read own" on public.notes
  for select to authenticated using ((select auth.uid()) = user_id);

create policy "notes: insert own" on public.notes
  for insert to authenticated with check ((select auth.uid()) = user_id);

RLS on with no policies means nobody can read anything through the API. That's a safe place to start.

2. Policies that say yes to everyone

The Supabase dashboard offers policy templates, and their names sound safe:

create policy "Enable insert for authenticated users only" on public.profiles
  for insert to authenticated with check (true);

create policy "Enable read access for all users" on public.profiles
  for select using (true);

"Authenticated users only" just means anyone who signed up, and sign-up is usually open. with check (true) lets them insert a profile row with any id, including someone else's. The read policy shows every user's profile to the whole internet.

Fix: tie each policy to the row owner.

create policy "profiles: insert own" on public.profiles
  for insert to authenticated with check ((select auth.uid()) = id);

create policy "profiles: read own" on public.profiles
  for select to authenticated using ((select auth.uid()) = id);

Public read is sometimes correct. A pricing page needs products and prices for logged-out visitors, so the checker only warns about a select using (true) and leaves the call to you. On insert, update or delete it's an error.

One more thing on this table: profiles has a plan column. Don't give users an update policy that covers it, or they can make themselves "pro" from the browser console. Let the Stripe webhook change it on the server.

3. The service_role key in browser code

This one usually starts as a "quick fix" for an RLS error:

"use client";
const supabase = createClient(process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.SUPABASE_SERVICE_ROLE_KEY!);

The service role key skips RLS completely. In Next.js this line doesn't even work at first, because variables without the NEXT_PUBLIC_ prefix are undefined in client components. So the next "fix" is to rename it NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY, and now the master key of your database is in every visitor's JS.

Fix: use the anon key with the user's session in the browser, and write the policies that make it work. If something really needs admin rights, do it in a Route Handler or Server Action, check who the user is there, and keep the client with the service key in a file that never gets imported by client code. Adding import "server-only" at the top of that file makes the build fail if someone imports it from the browser by mistake.

4. Secrets behind NEXT_PUBLIC_ (or VITE_, EXPO_PUBLIC_)

export const stripe = new Stripe(process.env.NEXT_PUBLIC_STRIPE_SECRET_KEY!);

Anything with that prefix is copied into the client bundle at build time. A Stripe secret key there means anyone can create refunds, read your customers or issue payouts with your account.

The same goes for NEXT_PUBLIC_OPENAI_API_KEY used for an "AI summarize" button. You'll find out when the bill comes. The checker only warns on that one, because some services do have keys made for the browser.

Fix: drop the prefix, use the key only in server code, and call your own API route from the browser. Then rotate the key. If it was ever in a deployed bundle, assume someone has it.

5. A Stripe webhook that trusts any POST

export async function POST(request: Request) {
  const event = await request.json();
  if (event.type === "checkout.session.completed") {
    await admin.from("profiles").update({ plan: "pro" }).eq("id", event.data.object.client_reference_id);
  }
  return Response.json({ received: true });
}

The webhook URL is not a secret. Anyone can send this endpoint a JSON body that says checkout.session.completed with their own user id and get the paid plan for free.

Fix: read the raw body, verify the signature, and answer 400 when it fails.

export async function POST(request: Request) {
  const body = await request.text();
  const signature = request.headers.get("stripe-signature");
  if (!signature) return new Response("Missing signature", { status: 400 });

  let event;
  try {
    event = stripe.webhooks.constructEvent(body, signature, process.env.STRIPE_WEBHOOK_SECRET!);
  } catch {
    return new Response("Invalid signature", { status: 400 });
  }
  // handle event.type here
  return Response.json({ received: true });
}

Use request.text() and not request.json(). The signature is computed over the exact bytes Stripe sent, and parsing then re-serializing the JSON breaks it. On Deno or edge runtimes it's await stripe.webhooks.constructEventAsync(...).

6. A .env file tracked by git

.gitignore only stops files that aren't tracked yet. If .env was committed once, before the ignore rule existed, git keeps tracking it and every later change goes into history.

Fix:

git rm --cached .env
echo ".env*" >> .gitignore
echo "!.env.example" >> .gitignore

Then rotate every key that was in it, because the old commits still have it. Removing the file from history (git filter-repo) only helps if nobody cloned or forked it yet.

Not every committed env file is a problem. Some starters commit .env.development with the default keys the Supabase CLI prints for a local stack. Those are the same for everyone who runs supabase start, so the checker only warns about them.

What I saw on real repos

Before writing this I ran the checker (1.1.2) on public MIT-licensed Next.js + Supabase + Stripe starters. Here is the full output for two of them, the official Vercel subscription starter and a popular community starter built on the same schema:

$ node preflight.mjs nextjs-subscription-payments
vibe-preflight 1.1.2 · 56 source files, 3 SQL files · 6 checks

warning schema.sql:66
        Policy "Allow public read-only access." on `public.products` (select) lets anyone (signed in or not) read every row. [rls-permissive-policy]
warning schema.sql:99
        Policy "Allow public read-only access." on `public.prices` (select) lets anyone (signed in or not) read every row. [rls-permissive-policy]
warning supabase/migrations/20230530034630_init.sql:66
        (same policy, migration copy)
warning supabase/migrations/20230530034630_init.sql:99
        (same policy, migration copy)

0 errors, 4 warnings

$ node preflight.mjs next-supabase-stripe-starter
vibe-preflight 1.1.2 · 57 source files, 2 SQL files · 6 checks

warning supabase/migrations/20240115041359_init.sql:66
        Policy "Allow public read-only access." on `public.products` (select) lets anyone (signed in or not) read every row. [rls-permissive-policy]
warning supabase/migrations/20240115041359_init.sql:99
        Policy "Allow public read-only access." on `public.prices` (select) lets anyone (signed in or not) read every row. [rls-permissive-policy]

0 errors, 2 warnings

Zero errors on both. The only warnings are the public read on products and prices, which a pricing page needs (hole 2 above, the case where using (true) is fine). Both starters turn RLS on for every table, keep the service key in server code and verify webhook signatures with constructEvent.

That makes sense, starters get many eyes. The problems above show up later, in the app someone builds on top of a starter while chasing an error message at 2am. To check that the scanner would notice, I copied one starter, removed the constructEvent call and added a table without RLS. Both were caught as errors.

The real repos were also useful for showing me where the checker was wrong. Another starter's CORS helper lists stripe-signature in Access-Control-Allow-Headers, and the checker took that file for a webhook handler with no verification. It now only counts a file that actually reads the header. I'd rather fix a false alarm than have people turn a check off.

Try it

git clone https://github.com/atokim4/vibe-preflight
node vibe-preflight/skills/vibe-preflight/scripts/preflight.mjs path/to/your-app --explain

It's one Node 20+ file with no dependencies, and it can also be installed as a Claude Code skill (instructions in the README). It's a static check, so a clean run doesn't mean an app is secure. Storage bucket policies, auth settings and anything you only changed in the Supabase dashboard are out of its reach.

If it gets something wrong on your repo, open an issue with the output. Both false alarms I fixed so far came from running it on code I didn't write.

If you want more than six checks, I also sell a paid kit built around the same idea: a 21-check scanner plus Claude Code / Cursor rules and a pre-launch checklist for this stack (Vibe App Production Kit, $29). The free checker above works on its own, you don't need the kit.

Disclosure: vibe-preflight is my own free tool and the kit is my own paid product. This post was drafted with AI tools (Claude) from the project's real output: every command shown was actually run, and the output is copied as is.