Agency Builder

Pain points for a Agency Builder

• Each client app has different constraints but similar exposure patterns
• Template reuse can introduce insecure defaults when rushed
• Hand-offs to client teams often lose critical security context
• You need efficient hardening steps that work across projects
• You need evidence for clients that fixes were validated

Goals for a Agency Builder

• Define a default secure project baseline for new client builds
• Apply standardized templates for tables, storage, and RPC
• Document verification steps clients can run after handoff
• Reduce repeat incidents from the same root causes

What Agency Builders should prioritize first (highest leverage)

1. Block direct client access to the most sensitive surface you have today (tables, Storage, or RPC).
2. Make verification easy: you should be able to prove the fix with one direct access test.
3. Reduce complexity before adding more rules: backend-only access beats a large pile of fragile policies.
4. Add one small regression guard (checklist query, scan, or release checklist item).

Recommended templates (fastest safe wins)

• Lock down a public table (backend-only access) → /templates/access-control/lock-down-public-table — A template to revoke direct client access, enable RLS, remove policies, and force all reads/writes through your backend using service_role.
• Make a bucket private + serve files with signed URLs → /templates/storage-safety/make-bucket-private-signed-urls — A template to make Supabase Storage buckets private, prevent listing/enumeration, and deliver downloads using short-lived signed URLs from your backend.
• Lock down RPC: revoke EXECUTE from public roles → /templates/rpc-functions/lock-down-rpc-execute — A template to discover function signatures, revoke EXECUTE from PUBLIC/anon/authenticated, and call RPC only through backend code using service_role.
• Remove over-permissive RLS policies (adopt deny-by-default) → /templates/access-control/remove-over-permissive-policies — A template to remove broad policies that leak data and move to a backend-only, deny-by-default posture that is easier to reason about and verify.

Recommended glossary terms (learn the why)

• Row Level Security (RLS) → /glossary/row-level-security — Row Level Security (RLS) is the row-by-row gatekeeper that blocks anon/authenticated clients from touching rows they do not own, but it only protects data when it is enabled and forced.
• Public Table Exposure → /glossary/public-table-exposure — Public table exposure happens when tables accept anon/authenticated requests without row filters or backend gating, making them effectively open.
• Over-permissive RLS Policies → /glossary/over-permissive-rls-policies — Over-permissive RLS policies let too many rows through or cover too many actions, defeating the point of row security.
• Supabase Storage Bucket Privacy → /glossary/supabase-storage-bucket-privacy — Storage bucket privacy means restricting downloads and listings so only authorized backend code can fetch objects.
• RPC EXECUTE Grants → /glossary/rpc-execute-grants — RPC execute grants control which roles can call Postgres functions, and long-lived PUBLIC/anon grants often outlive their intended use.
• Signed URLs → /glossary/signed-urls — Signed URLs give temporary, scoped access to private storage objects, but poor signing still leaks data.
• Service Role Key → /glossary/service-role-key — The service role key must live on the server; leaking it to the browser hands attackers full database control.
• Forced RLS (FORCE ROW LEVEL SECURITY) → /glossary/force-row-level-security — Forcing RLS guarantees ownership filters cannot be bypassed by privileged sessions.
• Client Role Grants (anon/authenticated) → /glossary/client-role-grants — Client role grants (anon/authenticated) create an API surface, and misusing them exposes data to any client.
• Ownership-bound RLS Policies → /glossary/ownership-bound-rls-policies — Ownership-bound policies tie rows to a user or tenant; missing that link leaves data open.
• Storage Object Enumeration → /glossary/storage-object-enumeration — Object enumeration happens when buckets allow listing or predictable keys, giving attackers a catalog of files.
• Public RPC Surface Area → /glossary/public-rpc-surface-area — Public RPC surface area is every function you leave EXECUTE access to client roles, and it tends to grow into a leak.
• NEXT_PUBLIC Secret Leakage → /glossary/next-public-secret-leakage — Any secret placed in a NEXT_PUBLIC variable becomes public, so these env vars can never hold sensitive keys.
• Broken Object Level Authorization (BOLA) → /glossary/broken-object-level-authorization — Broken Object Level Authorization happens when each object is not validated against the requester, letting attackers read other users’ data.
• Insecure Direct Object References (IDOR) → /glossary/insecure-direct-object-references — Insecure Direct Object References happen when object IDs are exposed without authorization checks.
• Tenant ID Trusted from Client → /glossary/tenant-id-trust-in-client — Trusting tenant IDs from the client lets attackers impersonate other tenants.
• Missing WITH CHECK Policy → /glossary/missing-with-check-policy — Missing WITH CHECK clauses expose write paths even when reads are locked down.
• Broad SELECT for Authenticated Role → /glossary/broad-authenticated-select — Broad authenticated SELECT grants let every logged-in user read sensitive tables.
• Broad UPDATE for Authenticated Role → /glossary/broad-authenticated-update — Broad authenticated UPDATE grants let every logged-in user change other people’s rows.
• Broad DELETE for Authenticated Role → /glossary/broad-authenticated-delete — Broad authenticated DELETE grants allow any logged-in user to remove rows.
• Default Privilege Drift → /glossary/default-privilege-drift — Default privilege drift happens when inherited grants become permissive, exposing every new object you create.
• Schema USAGE Granted to PUBLIC → /glossary/schema-usage-granted-to-public — Granting USAGE on a schema to PUBLIC exposes everything inside it.
• Exposed Materialized Views → /glossary/exposed-materialized-views — Exposed materialized views are cached results that leak data the moment you grant clients access.
• Insecure SECURITY DEFINER Functions → /glossary/insecure-security-definer-functions — Insecure SECURITY DEFINER Functions is a Supabase security risk where privileged functions execute with elevated rights but lack strict guardrails, .
• Mutable Function search_path → /glossary/mutable-function-search-path — Mutable Function search_path is a Supabase security risk where function execution can be hijacked when search_path is not pinned safely, .
• Trigger Privilege Escalation → /glossary/trigger-privilege-escalation — Trigger Privilege Escalation is a Supabase security risk where trigger functions perform privileged operations without clear authorization boundaries, .
• Migration Owner Bypass of RLS → /glossary/migration-owner-bypass — Migration Owner Bypass of RLS is a Supabase security risk where owner-level migration scripts bypass policy assumptions and access controls, .
• Shadow Table Without RLS → /glossary/shadow-table-without-rls — Shadow Table Without RLS is a Supabase security risk where new helper tables ship without RLS and silently expose internal data, .
• Audit Log Table Publicly Readable → /glossary/audit-log-public-readable — Audit Log Table Publicly Readable is a Supabase security risk where diagnostic or audit tables become queryable by client roles, .
• Soft Delete Policy Bypass → /glossary/soft-delete-policy-bypass — Soft Delete Policy Bypass is a Supabase security risk where deleted rows remain accessible because policies do not enforce deleted-state filtering, .
• UPSERT Policy Gap → /glossary/upsert-policy-gap — UPSERT Policy Gap is a Supabase security risk where upsert paths bypass intended checks when insert and update logic diverge, .
• Cross-Schema Data Exposure → /glossary/cross-schema-exposure — Cross-Schema Data Exposure is a Supabase security risk where objects in unintended schemas become reachable through grants or API exposure settings, .
• Unrestricted View Definitions → /glossary/unrestricted-view-definitions — Unrestricted View Definitions is a Supabase security risk where views reveal sensitive joins and fields without sufficient access filtering, .
• Leaked JWT Signing Secret → /glossary/leaked-jwt-secret — Leaked JWT Signing Secret is a Supabase security risk where token-signing secrets leak and allow forged authentication tokens, .
• Stale JWT Claims → /glossary/stale-jwt-claims — Stale JWT Claims is a Supabase security risk where authorization decisions rely on outdated claims that no longer match server state, .
• Auth Role Claim Confusion → /glossary/auth-role-claim-confusion — Auth Role Claim Confusion is a Supabase security risk where role mapping is ambiguous and grants unintended privileges to users, .
• Magic Link Open Redirect → /glossary/magic-link-redirect-open-redirect — Magic Link Open Redirect is a Supabase security risk where authentication links redirect users to attacker-controlled destinations, .
• Password Reset Token Leakage → /glossary/password-reset-token-leakage — Password Reset Token Leakage is a Supabase security risk where reset tokens leak through logs, URLs, or client-side handling, .
• OAuth Role Mapping Errors → /glossary/oauth-role-mapping-errors — OAuth Role Mapping Errors is a Supabase security risk where external identity attributes are mapped to internal roles without strict checks, .
• SSO Group Sync Escalation → /glossary/sso-group-sync-escalation — SSO Group Sync Escalation is a Supabase security risk where group sync grants elevated access when role sync rules are too permissive, .
• Invite Flow Tenant Escalation → /glossary/invite-flow-tenant-escalation — Invite Flow Tenant Escalation is a Supabase security risk where invitation flows allow membership changes beyond intended tenant scope, .
• Membership Race Condition → /glossary/membership-race-condition — Membership Race Condition is a Supabase security risk where concurrent membership updates create temporary unauthorized access windows, .
• Admin Panel Client-Only Auth → /glossary/admin-panel-client-auth-only — Admin Panel Client-Only Auth is a Supabase security risk where admin protections live in frontend checks instead of enforceable backend authorization, .
• Database URL Leaked in Client → /glossary/leaked-database-url-in-client — Database URL Leaked in Client is a Supabase security risk where database connection details leak into browser bundles and deployment artifacts, .
• Secrets in Repository History → /glossary/secrets-in-repo-history — Secrets in Repository History is a Supabase security risk where historical commits expose credentials long after they were removed from current code, .
• Environment Parity Security Drift → /glossary/env-parity-security-drift — Environment Parity Security Drift is a Supabase security risk where security controls differ across dev, staging, and production environments, .
• Staging Database Public Exposure → /glossary/staging-db-public-exposure — Staging Database Public Exposure is a Supabase security risk where staging deployments expose production-like data with weak controls, .
• Test Data Left in Production → /glossary/test-data-in-production — Test Data Left in Production is a Supabase security risk where non-production data handling introduces privacy and integrity risks, .
• Unencrypted Sensitive Columns → /glossary/unencrypted-sensitive-columns — Unencrypted Sensitive Columns is a Supabase security risk where high-risk fields are stored without column-level encryption or tokenization strategy, .
• Missing Key Rotation Policy → /glossary/key-rotation-policy-missing — Missing Key Rotation Policy is a Supabase security risk where long-lived secrets persist without rotation, increasing blast radius during incidents, .
• Service Role Overreach in Cron Jobs → /glossary/service-role-overreach-in-cron — Service Role Overreach in Cron Jobs is a Supabase security risk where scheduled jobs run with excessive privileges for routine operations, .
• PII in Error Traces → /glossary/pii-in-error-traces — PII in Error Traces is a Supabase security risk where stack traces and error payloads leak personal data across observability systems, .
• PII in Analytics Events → /glossary/pii-in-analytics-events — PII in Analytics Events is a Supabase security risk where tracking events include sensitive fields not needed for product analytics, .
• Missing Data Retention Policy → /glossary/data-retention-policy-missing — Missing Data Retention Policy is a Supabase security risk where sensitive data is kept indefinitely without lifecycle controls, .
• Incomplete GDPR Delete Flow → /glossary/incomplete-gdpr-delete-flow — Incomplete GDPR Delete Flow is a Supabase security risk where delete flows remove top-level records but leave recoverable personal data behind, .
• No Exfiltration Anomaly Detection → /glossary/no-anomaly-detection-exfiltration — No Exfiltration Anomaly Detection is a Supabase security risk where large abnormal data reads go unnoticed without baseline monitoring and alerting, .
• Weak Tenant Isolation Tests → /glossary/weak-tenant-isolation-tests — Weak Tenant Isolation Tests is a Supabase security risk where automated tests fail to prove cross-tenant access is consistently blocked, .
• Policy Drift After Schema Rename → /glossary/policy-drift-after-schema-rename — Policy Drift After Schema Rename is a Supabase security risk where renamed tables and columns silently desynchronize policy behavior, .
• Orphaned Policies After Table Rename → /glossary/orphaned-policies-after-table-rename — Orphaned Policies After Table Rename is a Supabase security risk where legacy policies remain detached from intended objects after refactors, .
• Generated Columns Leak Sensitive Data → /glossary/generated-columns-sensitive-leak — Generated Columns Leak Sensitive Data is a Supabase security risk where derived columns unintentionally expose sensitive source attributes, .
• View Without Security Barrier → /glossary/view-without-security-barrier — View Without Security Barrier is a Supabase security risk where view planning behavior can leak data when security barriers are not applied, .
• Missing Column-Level Redaction → /glossary/column-level-redaction-missing — Missing Column-Level Redaction is a Supabase security risk where applications expose full records when only partial fields should be visible, .
• Unrestricted PostgREST Origin Proxy → /glossary/unrestricted-postgrest-origin — Unrestricted PostgREST Origin Proxy is a Supabase security risk where proxy layers forward API requests without validating trusted origins, .
• CORS Misconfiguration in Edge Functions → /glossary/cors-misconfiguration-edge-functions — CORS Misconfiguration in Edge Functions is a Supabase security risk where permissive CORS allows untrusted origins to trigger privileged flows, .
• Missing Webhook Signature Validation → /glossary/missing-webhook-signature-validation — Missing Webhook Signature Validation is a Supabase security risk where incoming webhooks are trusted without cryptographic authenticity checks, .
• Webhook Replay Attack Risk → /glossary/webhook-replay-attack-risk — Webhook Replay Attack Risk is a Supabase security risk where valid webhook messages can be replayed to repeat sensitive actions, .
• Billing Webhook Idempotency Gap → /glossary/billing-webhook-idempotency-gap — Billing Webhook Idempotency Gap is a Supabase security risk where billing events are processed multiple times and create inconsistent account states, .
• Insecure Edge Function Authentication → /glossary/insecure-edge-function-auth — Insecure Edge Function Authentication is a Supabase security risk where edge endpoints process privileged actions before enforcing robust auth checks, .
• Edge Function Service Role Overuse → /glossary/edge-function-service-role-overuse — Edge Function Service Role Overuse is a Supabase security risk where service role credentials are used in functions that only need limited permissions, .
• RPC Dynamic SQL Injection → /glossary/rpc-dynamic-sql-injection — RPC Dynamic SQL Injection is a Supabase security risk where function logic builds SQL dynamically from untrusted parameters, .
• RPC Missing Input Validation → /glossary/rpc-missing-input-validation — RPC Missing Input Validation is a Supabase security risk where RPC handlers accept malformed or dangerous inputs without strict validation, .
• RPC Unbounded Result Sets → /glossary/rpc-unbounded-result-set — RPC Unbounded Result Sets is a Supabase security risk where RPC functions return excessive rows and enable low-cost data scraping, .
• RPC Error Message Data Leak → /glossary/rpc-error-data-leak — RPC Error Message Data Leak is a Supabase security risk where error paths disclose stack details, SQL fragments, or sensitive identifiers, .
• Public Function Source Disclosure → /glossary/public-function-source-disclosure — Public Function Source Disclosure is a Supabase security risk where function definitions leak business logic and internal assumptions to low-privilege roles, .
• Overloaded RPC Signature Miss → /glossary/overloaded-rpc-signature-miss — Overloaded RPC Signature Miss is a Supabase security risk where security reviews miss overloaded signatures that remain callable with weaker controls, .
• Unrestricted Admin Search Endpoint → /glossary/unrestricted-admin-search-endpoint — Unrestricted Admin Search Endpoint is a Supabase security risk where search endpoints provide broad access to internal records and metadata, .
• Bulk Export Endpoint Overexposure → /glossary/bulk-export-endpoint-overexposure — Bulk Export Endpoint Overexposure is a Supabase security risk where export APIs allow high-volume extraction without strong authorization and limits, .
• CSV Import Trusts Client Columns → /glossary/csv-import-trusts-client-columns — CSV Import Trusts Client Columns is a Supabase security risk where import flows allow users to overwrite sensitive fields through crafted headers, .
• Row Ownership Transfer Without Recheck → /glossary/row-ownership-transfer-without-recheck — Row Ownership Transfer Without Recheck is a Supabase security risk where ownership updates are accepted without validating transfer authority, .
• File Upload MIME Spoofing → /glossary/file-upload-mime-spoofing — File Upload MIME Spoofing is a Supabase security risk where uploaded files bypass validation by spoofing content type metadata, .
• Storage Upload Size Abuse → /glossary/storage-upload-size-abuse — Storage Upload Size Abuse is a Supabase security risk where uploads lack size limits and create denial-of-wallet and abuse risks, .
• Missing Malware Scanning on Uploads → /glossary/missing-malware-scanning-uploads — Missing Malware Scanning on Uploads is a Supabase security risk where user-uploaded files are served without malware scanning or quarantine workflows, .
• Public Backup Bucket Leak → /glossary/public-backup-bucket-leak — Public Backup Bucket Leak is a Supabase security risk where backup artifacts become publicly readable through misconfigured storage buckets, .
• Expired Signed URL Caching Leak → /glossary/expired-signed-url-caching-leak — Expired Signed URL Caching Leak is a Supabase security risk where cached responses keep files accessible after signed URL expiry windows, .
• Object Path Predictability Risk → /glossary/object-path-predictability-risk — Object Path Predictability Risk is a Supabase security risk where predictable object paths make private assets easy to enumerate and scrape, .
• Storage Lifecycle Policy Missing → /glossary/storage-lifecycle-policy-missing — Storage Lifecycle Policy Missing is a Supabase security risk where old objects remain accessible because storage lifecycle and cleanup policies are absent, .
• Bucket LIST Permission Too Broad → /glossary/bucket-list-permission-too-broad — Bucket LIST Permission Too Broad is a Supabase security risk where list permissions expose object inventories that assist targeted abuse, .
• Realtime Channel Authorization Gap → /glossary/realtime-channel-authorization-gap — Realtime Channel Authorization Gap is a Supabase security risk where channel subscriptions are accepted without enforcing tenant-aware authorization rules, .
• Realtime Presence Data Leak → /glossary/realtime-presence-data-leak — Realtime Presence Data Leak is a Supabase security risk where presence metadata reveals user behavior and identifiers to unauthorized clients, .
• Publication Includes Sensitive Tables → /glossary/publication-includes-sensitive-tables — Publication Includes Sensitive Tables is a Supabase security risk where logical replication publishes sensitive tables that should never stream to clients, .
• Replication Role Overgrant → /glossary/replication-role-overgrant — Replication Role Overgrant is a Supabase security risk where replication roles receive privileges beyond strict replication requirements, .
• Unbounded Pagination Enumeration → /glossary/unbounded-pagination-enumeration — Unbounded Pagination Enumeration is a Supabase security risk where pagination controls are weak and allow low-cost full dataset traversal, .
• Guessable Primary Keys → /glossary/guessable-primary-keys — Guessable Primary Keys is a Supabase security risk where sequential or predictable identifiers simplify unauthorized record discovery, .
• Missing Rate Limits on Write Paths → /glossary/rate-limit-missing-on-write-paths — Missing Rate Limits on Write Paths is a Supabase security risk where write endpoints can be abused for spam, brute force, and denial-of-wallet, .
• Missing CAPTCHA on Sensitive Flows → /glossary/missing-captcha-sensitive-flows — Missing CAPTCHA on Sensitive Flows is a Supabase security risk where high-risk workflows lack anti-automation controls against scripted abuse, .
• Insecure Feature Flag Disclosure → /glossary/insecure-feature-flag-disclosure — Insecure Feature Flag Disclosure is a Supabase security risk where flag payloads expose hidden capabilities and internal rollout logic, .
• No Two-Person Review for Privilege Changes → /glossary/no-two-person-review-privilege-changes — No Two-Person Review for Privilege Changes is a Supabase security risk where single-actor privilege changes increase risk of accidental or malicious escalation, .
• Dependency Drift Misses Security Updates → /glossary/dependency-drift-security-updates-missed — Dependency Drift Misses Security Updates is a Supabase security risk where stale dependencies keep known vulnerabilities in critical runtime paths, .
• Private Key Material in Logs → /glossary/private-key-material-in-logs — Private Key Material in Logs is a Supabase security risk where sensitive key material is accidentally emitted to application and infrastructure logs, .
• API Cache Leaks Private Data → /glossary/api-cache-private-data-leak — API Cache Leaks Private Data is a Supabase security risk where shared caches return user-specific responses to unauthorized sessions, .
• Data API Public Schema Exposure → /glossary/data-api-public-schema-exposure — Data API Public Schema Exposure occurs when sensitive tables remain in exposed schemas, making direct REST or GraphQL access possible with client-side credentials.
• Data API Custom Schema Misconfiguration → /glossary/data-api-custom-schema-misconfiguration — Data API Custom Schema Misconfiguration happens when teams move to a custom exposed schema but leave permissive grants, search paths, or legacy objects that keep data reachable.
• pg_graphql Extension Exposure → /glossary/pg-graphql-extension-exposure — pg_graphql Extension Exposure appears when GraphQL remains enabled on schemas or objects that should not be reachable from client credentials.
• Realtime Public Channel Mode → /glossary/realtime-public-channel-mode — Realtime Public Channel Mode is the risk of allowing broad channel subscription without private-channel authorization rules and topic scoping.
• Realtime Topic Policy Mismatch → /glossary/realtime-topic-policy-mismatch — Realtime Topic Policy Mismatch occurs when channel topic patterns and RLS authorization logic diverge, allowing unintended subscribers or publishers.
• Realtime Broadcast Overexposure → /glossary/realtime-broadcast-overexposure — Realtime Broadcast Overexposure is the accidental publication of sensitive payloads to channels where recipients are broader than intended.
• Edge Function JWT Verification Gap → /glossary/edge-function-jwt-verification-gap — Edge Function JWT Verification Gap occurs when function handlers skip or misapply token validation, allowing unauthorized execution paths.
• Service Role Authorization Header Override → /glossary/service-role-authorization-header-override — Service Role Authorization Header Override is when a client initialized for admin use silently runs with user session headers, changing expected privilege behavior.
• Publishable vs Secret Key Scope Confusion → /glossary/publishable-secret-key-scope-confusion — Publishable vs Secret Key Scope Confusion is the misuse of key types across client and server boundaries, resulting in over-privileged execution paths.
• Missing Network Restrictions → /glossary/missing-network-restrictions — Missing Network Restrictions means database and pooler endpoints are reachable from unrestricted IP ranges, increasing brute-force and credential abuse risk.
• IPv6 Allowlist Gap → /glossary/ipv6-allowlist-gap — IPv6 Allowlist Gap is the mistaken assumption that IPv4 restrictions are enough, leaving IPv6 connection routes less constrained than intended.
• Default Function EXECUTE to PUBLIC → /glossary/default-function-execute-to-public — Default Function EXECUTE to PUBLIC is the risk that newly created routines remain callable by broad roles unless explicit revokes/default privileges are applied.
• Untrusted Language Function Risk → /glossary/untrusted-language-function-risk — Untrusted Language Function Risk is the danger of running routines with capabilities that can circumvent normal access boundaries if creation/execution controls are weak.
• Storage Authenticated Endpoint Overtrust → /glossary/storage-authenticated-endpoint-overtrust — Storage Authenticated Endpoint Overtrust is relying on logged-in status alone for private file access without strict path ownership and bucket policy checks.

A safe default architecture for Agency Builders

If you’re not sure which model to choose, this default posture prevents many Supabase leaks:

• The browser is untrusted and uses only anon/auth tokens for public, non-sensitive actions.
• All sensitive reads/writes go through backend endpoints (server actions or API routes).
• Service-role secrets never leave the server environment.
• RLS is used as a safety gate, not the only authorization mechanism.

You can always relax this posture later if you intentionally want client-side access — but tightening after a leak is harder.

A simple weekly security rhythm

1. Scan or run checklist queries after schema changes.
2. Fix one high-risk exposure (tables, storage, RPC).
3. Verify via direct client access tests.
4. Document the decision and add a regression check.

Verification loop for a Agency Builder (what “done” looks like)

• You can reproduce the risky behavior before the fix (so you’re not guessing).
• After the fix, the same direct access attempt fails with a clear denial.
• The app still works through backend endpoints for authorized users.
• A scan/checklist re-run confirms the exposure signal is gone.
• You wrote down the rule so the next schema change doesn’t reintroduce it.

Common traps (what to avoid)

• Shipping quick policy changes without verification.
• Leaving Storage public because it’s “only files”.
• Keeping RPC callable because it’s “just internal”.
• Putting service_role in client env vars.

What to automate next (as Agency Builders mature)

• A drift check after migrations: new tables with RLS disabled, new public EXECUTE grants, new public buckets.
• A lightweight “security change” checklist in PRs: policies, grants, buckets, functions, auth flows.
• Monitoring for unusual reads/writes, especially anonymous access to sensitive surfaces.

A one-day hardening plan for a Agency Builder

1. Pick one surface (tables, Storage, or RPC) and inventory the resources you consider sensitive.
2. Apply one template/conversion end-to-end and keep the change small.
3. Run verification (direct access fails) and fix any missed app call paths.
4. Document the access model and add a drift guard for the next migration.
5. Repeat for the next surface next week instead of trying to do everything at once.

What to monitor as a Agency Builder

• Unexpected anonymous reads/writes or Storage downloads.
• Denied access spikes after tightening permissions (often indicates missed app paths).
• Changes to policies/grants/buckets/functions that didn’t go through review.

Common scenarios for a Agency Builder (and the safest response)

• A new table ships and the UI needs data quickly → add a backend endpoint first, then decide if client access is truly necessary.
• A file download feature ships fast → keep buckets private and use signed URLs from the server, even if it feels slower at first.
• A new function is added for convenience → treat RPC as privileged by default and revoke public EXECUTE unless reviewed.
• A migration changes policies/grants → re-run verification checks immediately to catch drift before users do.

A “boundary statement” template for Agency Builders

A boundary statement is a one-sentence rule you can put in docs and PRs so security is reviewable and testable.

Use this template and fill it in:

• Only the backend can (operation) on (resource) because (reason).
• The browser can only (safe operation) and must never call (privileged path) directly.
• Verification: the direct access test (describe it) must fail in dev/staging/prod.

Writing this down turns security into a repeatable habit and makes regressions obvious.