---
id: "question-security-auth"
type: "open-question"
source_timestamps: ["00:09:15", "00:09:30"]
tags: ["security", "authentication"]
related: ["entity-vercel", "action-deploy-vercel", "entity-supabase", "claim-free-hosting-sufficient"]
resolutionPath: "A technical tutorial detailing how to implement Supabase Auth or simple password protection within the AI-generated Vercel application."
sources: ["s21-ai-tool-memory"]
sourceVaultSlug: "s21-ai-tool-memory"
originDay: 21
---
# How Is the Vercel App Secured?

## Open Question
How is the [[entity-vercel-d21]] app secured?

## Context
The speaker describes deploying a web app to Vercel that reads from and writes to a personal [[entity-supabase-d21]] database. However, he does **not detail** how authentication or **Row Level Security (RLS)** is handled in this custom app to prevent unauthorized access to the live URL.

## Why This Matters
- A live Vercel URL is publicly reachable. Without RLS or auth, anyone who finds the URL could read/write personal data.
- The [[concept-shared-surface]] design intentionally exposes the table directly. This makes auth/RLS *more* important, not less.
- The enrichment overlay flags this as a real risk: 'Direct DB access (no sync) exposes RLS/auth flaws; Vercel apps need robust Supabase integration, unaddressed in video, risking breaches.'

## Resolution Path
A technical tutorial detailing how to implement **Supabase Auth** (or at minimum simple password protection) within the AI-generated Vercel application. RLS policies should also be configured at the Supabase layer to enforce per-user data isolation.

## Implication for the Claims
This question slightly **softens** [[claim-free-hosting-sufficient]] — 'free' does not mean 'safe by default'. Any practitioner adopting [[framework-open-brain-build]] should treat security as a required step, not an optional polish.