Vibe Coding Security: Connectors, Previews, Bans

Three platform changes landed today that matter more than they look. Lovable changed how connected accounts work inside multi-tenant apps. Vercel changed what's protected by default when you preview a deployment, and how sandboxes hand off state when they fork. And Codeberg, a code-hosting platform, started banning vibe-coded projects outright. None of these are breaches. All of them touch how much trust your app extends by default.

TL;DR

• Lovable's new app user connectors let each signed-in user connect their own third-party account instead of everyone sharing one — closes a common over-permissioning pattern in multi-tenant apps.
• Vercel now lets teams set a team-wide default for Deployment Protection; new projects start with Preview Deployments protected, which matters because forgotten public preview URLs are a routine leak vector.
• Vercel Sandbox forking inherits the source's config and environment variables — useful for branching agent workflows, but it means a fork carries the same secrets as its parent.
• Codeberg is banning vibe-coded projects, a sign that platform-level scrutiny of AI-generated code is starting to bite, not just in security terms but in trust terms.

Lovable's app user connectors close a real permission gap

Up until now, a standard app connector in Lovable meant one account, connected once, shared by every visitor to your app. If you're building anything multi-tenant — a CRM view, a shared inbox, a calendar tool — that pattern means every user's requests run through the same credential, with the same access, whether or not they should see that data.

The new app user connectors feature changes that. Each person who uses your published app connects their own account, and the app acts on their behalf with their own permissions and only their data. If your app has users who each need their own inbox, calendar, or CRM records, this is the right primitive — not the shared connector. If you shipped a multi-tenant app before this existed, it's worth checking which connectors are still running on a single shared credential.

Vercel locks down preview deployments and sandbox forking

Vercel now lets teams set a default protection level across all new projects — Standard Protection, All Deployments, or None. Standard Protection, the new default, covers Preview Deployments. That matters because preview URLs are often where an unfinished feature, a test payment flow, or a half-configured backend sits publicly reachable, simply because nobody thought of a preview link as a production surface.

Separately, Protection Bypass for Automation now supports multiple secrets, so teams can rotate one bypass secret without breaking every CI job that depends on it, and label each secret by what it's used for.

On the agent-infrastructure side, Vercel Sandbox now supports forking. A fork inherits the source sandbox's config and environment variables from its latest snapshot. This is a genuinely useful feature for branching an agent mid-task — but it also means secrets in a sandbox propagate to every fork of it by default. If you're running coding agents inside sandboxed environments, that's a detail worth knowing before you fork freely. Vercel Connect also now supports linking connectors to Custom Environments, so deployments there can request provider tokens and receive forwarded webhooks — one more place third-party credentials can now live, so it's worth knowing which environments hold which tokens.

Codeberg's ban and the backend gap in vibe-coded apps

Codeberg is banning vibe-coded projects from its hosting platform. That's a governance decision, not a vulnerability disclosure, but it's a signal: platforms are starting to treat AI-generated code as a distinct trust category, and some are deciding the answer is to keep it out entirely.

Meanwhile, a thread in r/vibecoding on backend infrastructure points at a pattern worth naming plainly: most vibe coders build the customer-facing frontend carefully and then hand the backend entirely to a hosted full-stack service, without touching its configuration. That's not wrong — hosted backends are usually the safer default. But it means the security of your app rides entirely on whatever that backend's default rules are. If you never configured row-level security, storage rules, or connector scopes yourself, someone should still check that the defaults you inherited are actually locked down for your use case.

FAQ

Does Codeberg ban AI-generated code?

Yes. Per a discussion in r/vibecoding, Codeberg is now banning vibe-coded projects from its hosting platform. The source items don't specify Codeberg's stated reasoning beyond the ban itself.

Should AI agents share one set of API credentials across all users?

No, if your app is multi-tenant. Lovable's own documentation distinguishes a standard connector — one shared account for every visitor — from the new app user connectors, which give each user their own scoped connection. Sharing one credential across users means every user's actions run with the same access level, which is rarely what you want once an app has more than one type of user.

Does forking a Vercel Sandbox inherit environment variables?

Yes. Per Vercel's changelog, Sandbox.fork() starts from the source sandbox's current snapshot and inherits its config and environment variables. If you're forking sandboxes to branch agent tasks, the fork carries the same secrets the original had.

The bottom line

None of today's changes are a breach. They're defaults shifting in a sensible direction: Lovable separating shared credentials from per-user ones, Vercel protecting preview URLs out of the box, Vercel flagging that forked sandboxes carry their parent's secrets. The common thread is permission scope — who or what actually holds a credential, and what it can see. If you shipped a multi-tenant app on a shared connector, or you've never checked what your Preview Deployments expose, that's worth ten minutes today.