For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /docs/web/security.md (or send Accept: text/markdown).
Security and privacy
Rate limits, secrets, data export, and the audit trail.
Beginner walkthrough
Prerequisites: Read the two beginner guides below, finish Web local setup, and open this monorepo at its root in your editor. Web settings belong in apps/web/.env.local; Next.js does not read the root .env. /dashboard in the default fake mode is a no-database demo; /auth needs a migrated database.
Quick terms: a workspace is one team's separate users, data, and settings. The server is the trusted backend; keep provider keys out of browser and phone code. A migration is a versioned database change that creates or updates tables. An AI model is the engine that answers; the model catalog is the server's list of available model IDs and prices. A provider is an outside service such as an AI, email, or billing service. An entitlement is a grant that lets a workspace use a feature. A webhook is a message one service sends to another service's URL.
1. In the server action or route that reads a user-owned record, resolve the signed-in user's membership and active workspaceId before querying.
2. Ask your agent to add one allowed-member case and one foreign-workspace denial for the exact record path; provide the roles and fields involved.
3. The first request should succeed and the second should return no record/access denied. If changing only the button hides access but direct requests still work, the server boundary is missing.
For custom code, start with the supplied prompts/README.md and copy the closest prompt: prompts/new-app-screen.md for an app screen or prompts/new-landing-page.md for a public page. For server, database, or provider work, give your coding agent this guide's task and ask it to read AGENTS.md, .ai/PROJECT_CONTEXT.md, and matching .ai/ mirrors; inspect the exact source files named here; list files and checks before editing; preserve workspace ownership and server-only secrets; and show you the diff. Tell it the behavior you want, input and output fields, allowed roles, expected success and errors, and the test account, provider, or device. Use sample values; never paste a real secret.
Resolve membership before data
The session chooses identity; the server resolves active workspace and verifies membership/role. Every user-owned record uses workspaceId. A client field, URL ID or model-selected argument cannot replace that ownership check.
Platform marketing assets and platform admin records have explicit platform scope; do not invent a workspace for anonymous waitlist entries.
Carry the boundary through asynchronous work
Tasks, jobs, tool context, API keys, content, storage and outbound events inherit the authenticated workspace. Check resource IDs together with ownership. Allowing a valid ID from another workspace is still an authorization failure.
Write denial tests first
Pair every successful mutation/read with anonymous, foreign-workspace and insufficient-role tests. Never expose secrets while diagnosing a forbidden result.
Setup and configuration
rate-limit-runtime provides the shared limiter wired into auth, checkout, API, and submission routes — extend it to new abuse-sensitive endpoints rather than inventing per-route counters. Session configuration, HTTPS-only cookies, and provider secrets stay server-side.
Workspace audit records (audit-runtime.ts) capture security-relevant changes — provider configuration, member and role updates — and are readable under /settings/audit.
# Data subject export
src/data-export.ts — assembles a member's
workspace-owned records for account exportImplementation workflow
Keep credentials out of logs, error payloads, analytics properties, and audit values — the observability layer redacts known keys, but free-form text is the author's responsibility. Resolve authorization on the server for every read and write; interface state is presentation, not proof.
Account data export and deletion requests run through the account boundary so the same ownership rules apply. Store only the data the product needs.
Verification and troubleshooting
Exercise the limiter until it returns a retryable 429, verify audit rows appear for the mutations that should produce them, and export a test member's data. Probe one cross-workspace read per release — the cheapest regression that matters.