Your vibe coded app is missing API auth for one of three reasons

Three causes, in order of how often I see them. First, the AI wrote a real API key into .env with a trailing newline, so every request it sends with that key gets a 401, and the path of least resistance for the next iteration was to remove the auth check from the route. Second, the AI scaffolded a fetch call from a React component without any Authorization header pattern, because nothing in its context told it to add one and the prompt did not mention auth. Third, the AI copied a service-role or admin-scoped key into client-side code because the prototype builder you used handed you one with no warning that it should never leave the server. The first cause is the loudest in practice and the one almost no other guide mentions.

Yes. It is common enough that mk0r ships an explicit rule about it inside the agent's installed CLAUDE.md. Open src/core/vm-claude-md.ts and read lines 292 through 310. There is a section literally titled 'Common Pitfall: Trailing Newlines in Environment Variables' that tells the agent: when writing API keys, tokens, or secrets to .env files, always check for and strip trailing \n characters. AI models frequently leave a trailing newline when outputting variable values, which causes silent auth failures, 401 errors, and broken API calls. The rule then shows the wrong way (echo with a literal newline before the closing quote) and the right way (printf with no trailing newline). That section was not added speculatively. It was added because keys with \n at the end are a recurring source of broken auth in vibe coded apps.

Cat the env file inside the running process and pipe it through cat -A. Anywhere you see $ at the end of a key value, the value has a trailing newline. The clean version reads VAR=value$ at the end of the line; a busted one reads VAR=value\n$ on its own. You can also do a quick repl check: console.log(JSON.stringify(process.env.MY_KEY)) and look for a literal \n inside the quoted string. If the key looks fine but auth still fails, move to cause two: search the codebase for fetch( and grep for the absence of any header named Authorization on the lines around it. If both look clean, you are probably in cause three, which is harder: a key that should never have been on the client.

It scopes it. Look at src/core/service-provisioning.ts at line 134 inside provisionResend. The body of the POST to https://api.resend.com/api-keys is a JSON object with three fields: a name, a permission of 'sending_access', and a domain_id of undefined. That permission is the narrowest scope Resend offers: the key can send mail and nothing else. It cannot list audiences, cannot delete audiences, cannot read sent message contents. So even if the generated app accidentally exposes that key, the blast radius is mail-sending only, against a Resend audience that mk0r owns. Most prototype builders hand the user a full-scope key by default; mk0r picks the smallest scope at provisioning time and the user never has the option to widen it.

Yes, in different ways. The Neon connection URI written into DATABASE_URL is for a per-app role with a per-app password, scoped to a project that contains exactly one database for this session. There is no shared role across apps, no shared password, and no shared schema. If a generated app leaks DATABASE_URL, the worst case is one app's data, not every mk0r user's data. The GitHub repo created at provisioning time is private by default (POST /user/repos with private: true). The PostHog key in VITE_POSTHOG_KEY is the project's ingestion-only key, which is meant to be public anyway and cannot read events. So the only key whose exposure is genuinely scary is DATABASE_URL, and the question for that one is whether the agent ever puts it into client code, which gets to the next FAQ.

Vite is the boundary. Inside the VM the project is a Vite + React project, which means import.meta.env exposes only the env vars whose names start with VITE_. DATABASE_URL, RESEND_API_KEY, and the Neon role password do not start with VITE_, so they are not exposed to the client at build time. The agent's installed backend-services skill (in vm-claude-md.ts around line 1207) explicitly tells it: client-side code uses import.meta.env, server-side or build-time code uses process.env. When the agent wires Resend, it writes a server endpoint that holds RESEND_API_KEY and a client fetch that calls that endpoint without ever seeing the key. The Vite boundary is not a security feature on its own, but combined with that rule it keeps the dangerous keys server-side by default.

At src/lib/auth-server.ts line 40, in a function called requireAuthOrError. Every API route that mutates persistent state imports this and calls it as the first line of the handler. The function pulls the Authorization: Bearer token off the request, calls Firebase Admin's verifyIdToken to confirm it is a valid Firebase ID token, and returns either a VerifiedUser or a 401 Response. You can grep the codebase to confirm the coverage: routes under /api/vm/, /api/billing/, /api/chat/, /api/cookie-bridge/, /api/analytics/, /api/transcribe/ all call it. The anonymous Firebase uid created on landing-page mount is enough to pass this check, so no signup is required, but every mutating call is still authenticated against a real verifiable token, not a session cookie or a shared key.

It is real, just lazy. The anonymous Firebase uid is a genuine Firebase user with a uid, an issued ID token signed by Google, and a server-verifiable signature. The host can prove cryptographically that two requests came from the same anonymous user, and it uses that to bind the user to their Firestore session, their E2B sandbox pairing, and their provisioned services. The 'theater' fear is reasonable but lands on a different question: this only protects mk0r's own routes. Anything the agent generates inside the VM is not automatically protected by this; if you ask the agent to expose a public endpoint with no auth, it will, and that endpoint will be public. So 'is mk0r protected' and 'is the app the agent built protected' are two questions with the same answer pattern (verify the token) but two different code paths.

Tell the agent to add it explicitly, and reference the three nouns it understands. Say: 'gate every server route behind a Firebase ID token; on the client, attach Authorization: Bearer <token> using the user property from useAuth(); on the server, call admin.auth().verifyIdToken on the request header.' The agent already knows about Firebase from the host context, and it has Anthropic's Claude tool stack to wire it. The cheaper path is to skip auth entirely until publish, while you are still iterating on UI, and only ask for auth when the app is about to be exposed to anyone other than you. Most vibe-coded prototypes hit this question one or two iterations before publish and the answer is fine to defer until then.