20 minutes maximum (about 16 slides, roughly a minute each), then the live attack demo. The whole talk builds to one sentence they must leave with: a public key with no row-level security is a public database. Second sentence: grant and RLS go together, always. No model versions or prices here; those live in TOOLS.md.
Analogy: authentication is showing ID at the door. Authorization is which rooms your keycard opens. Karpathy's MenuGen bug: an agent matched two accounts by email instead of a stable user ID. Sign-in was fine; authorization was wrong, and only a human who understood the app caught it.
Front-end code is a suggestion, not a lock. If the only thing stopping a user is that you didn't draw the button, you have no security. This is the whole week in one idea.
This resolves the week 5 puzzle ("keys live in .env and nowhere else"). That rule was about SECRET keys. The Supabase publishable key and project URL are meant to be seen; the database's rules protect the data, not the key's secrecy. Legacy names: anon = publishable, service_role = secret. The legacy JWT keys (eyJ...) are deprecated by the end of 2026, so we teach only the new ones. A sb_secret_ key in front-end code is a five-alarm fire. Supabase rejects a secret key used from a browser, but don't rely on that.
Draw the three states on the board. The middle one surprises people: RLS on with no policies locks everyone out, which is safe but useless. "RLS on, no policies" is the most common stall in the lab and in capstones.
Source: Supabase changelog (https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically). This applies to every project, for any table created after 30 October 2026; existing tables keep their grants. The new default is safer. But it sets a trap: see the next slide.
This is an inference from two sources in the October research report (the grants change plus UpGuard), but it's exactly the failure to rehearse. If an agent proposes a bare grant, stop it. In Studio A's worked example everyone writes the three together in one file.
Source: UpGuard (https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps). Examples: an immigration service with 884 plaintext passwords; a consulate's records on 25,000 people. Not a Supabase breach: configuration. BleepingComputer reports AI-assisted development accounts for more than 60% of new Supabase databases; UpGuard can't prove every exposed site was built with AI. This extends cases 1-2 (Lovable 2025, Moltbook) in resources/case-studies.md.
Sources: Sable Offensive Research (https://dev.to/alejandxr/lovable-bola-48-days-five-api-calls-source-code-database-credentials-of-other-peoples-projects-4ai0); Deng et al., arXiv 2606.23130 (https://arxiv.org/abs/2606.23130). Lovable first called this intended behavior for "public" projects. Discussion hook: "Your project was 'public'. What did that mean?" Ownership check = "is this row yours?", which is exactly what an RLS policy with auth.uid() answers.
Sources: The Hacker News (https://thehackernews.com/2026/09/ai-coding-agents-exposed-13000-internal.html); Information Age (https://ia.acs.org.au/article/2026/gone-in-9-seconds--ai-agent-deletes-company-database.html). PocketOS is from the week 6 set; here the point is where keys sit. Safety contract rule 9: agents don't publish without your approval. Rule 4: scoped tokens outside the project folder, backups out of the agent's reach. Secret scanners read text; they can't see what's in an image.
Sources: Socket (https://socket.dev/blog/tensorlake-compromise); Wiz (https://www.wiz.io/blog/litellm-compromised-steals-credentials); The Hacker News (https://thehackernews.com/2026/10/fake-web3-accelerator-uses-npm-packages.html); TechCrunch (https://techcrunch.com/2026/10/19/hackers-hit-ai-coding-tool-opencode-running-up-charges-on-users-ai-accounts/). Hook: "Why would malware want your .claude folder?" Extends case 7 (Nx s1ngularity). Rule 6: install only what the plan named, pin the version. Rule 4: hard spending caps.
Veracode's 2026 tests: only 15% of AI code samples defended against XSS (https://www.veracode.com/blog/spring-2026-genai-code-security/). The course's secret scan (npm run check:secrets) now reads the whole git history, not just today's files. A key found in history must be revoked and replaced; rewriting history isn't enough.
Source: Semgrep (https://semgrep.dev/blog/2026/claude-opus-5-5-susvibes-benchmark). Access control was among its weakest areas; 41% of working solutions reintroduced the original vulnerability. Safety contract rule 5 now says it in words: passing tests is not a security check.
Sources: Willison (https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/); Meta (https://ai.meta.com/blog/practical-ai-agent-security/). I'll demo a harmless version at the end of Studio B (7 minutes). The kit is there if you want to try it yourself. Rule 9: when an agent reads untrusted content, approvals stay on and no secrets are within reach; never autopilot.
The compare step is the learning: what did the AI catch that you didn't, and the reverse? The graded written review goes on Canvas; comments on the PR are ordinary code review.
Move fast to the lab. The attack page is hosted: no repo and no Codespace needed for Part 1. Everyone can do both parts even if their capstone is behind: the worked example runs on a practice branch.
Remind them: Supabase free projects pause after about a week idle; restore from the dashboard. Exit ticket at the end of Studio B: one vulnerability you fixed, and where authorization is enforced.