API keys and secrets in AI-built apps: what a native wrapper does not hide, and how to review any agent's code

// WRONG: service_role key in the browser. Bypasses every RLS policy.
const admin = createClient(SUPABASE_URL, import.meta.env.VITE_SUPABASE_SERVICE_ROLE_KEY);

// WRONG: Stripe secret key in a fetch from the client
await fetch("https://api.stripe.com/v1/checkout/sessions", {
  method: "POST",
  headers: { Authorization: "Bearer " + import.meta.env.VITE_STRIPE_SECRET_KEY }
});

// WRONG: sending pushes from the browser with the OneSignal App API key
await fetch("https://api.onesignal.com/notifications", {
  method: "POST",
  headers: { Authorization: "Key " + ONESIGNAL_APP_API_KEY, "Content-Type": "application/json" },
  body: JSON.stringify({ app_id: ONESIGNAL_APP_ID, contents: { en: "Hi" } })
});

// RIGHT: the client calls your endpoint with the user's session token
const res = await fetch("/api/checkout", {
  method: "POST",
  headers: { Authorization: "Bearer " + session.access_token, "Content-Type": "application/json" },
  body: JSON.stringify({ priceId: "price_basic_monthly" })
});

// RIGHT: on the server (API route, Supabase Edge Function, Cloud Function)
// 1. verify the session token and derive the user id from it, never from the body
// 2. read STRIPE_SECRET_KEY / ONESIGNAL_APP_API_KEY / SUPABASE_SECRET_KEY from server env
// 3. call the provider, return only what the client needs

-- Supabase SQL: enable RLS and let users see and change only their own row
alter table public.profiles enable row level security;

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

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

-- Firestore rules, same idea:
-- match /profiles/{uid} {
--   allow read, write: if request.auth != null && request.auth.uid == uid;
-- }

# 1. Build the production bundle
npm run build

# 2. Search shipped files for secret-looking strings
grep -rEn "sk_live_|sk_test_|rk_live_|whsec_|sb_secret_|os_v2_app_|BEGIN (RSA )?PRIVATE KEY|AIza[0-9A-Za-z_-]{35}" dist/ .next/static/ build/ 2>/dev/null

# 3. Legacy Supabase keys are JWTs: decode each one and look at "role"
#    "anon" is expected, "service_role" means a secret key shipped
grep -rhoE "eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+" dist/ 2>/dev/null | sort -u | while read -r t; do
  echo "$t" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null; echo
done

# 4. Native projects and git history
grep -rEn "sk_live_|sb_secret_|os_v2_app_|service_role" ios/ android/ 2>/dev/null
git log -p --all | grep -En "sk_live_|sb_secret_|os_v2_app_|SERVICE_ROLE" | head -20