When AI Agents Deploy Your Code Themselves

Today's shift in the vibe-coding world isn't a new feature — it's a new level of autonomy. AI agents are getting direct lines to your production deploys, your database, and your credentials, with less human review sitting in between. For founders running an app built on Lovable, Bolt, Cursor, or v0, that changes what "secure by default" actually has to mean.

TL;DR

• Vercel's MCP server can now deploy code straight to a live project on an agent's instruction — see the changelog.
• A new open-source project, OneCLI, exists specifically because agents keep ending up holding credentials they don't need.
• DeepSQL, a self-hostable DBA agent, gives a model direct write access to Postgres and MySQL.
• None of this is dangerous by default — but each new autonomous capability moves the security question from "did a person review this" to "did we configure the guardrails correctly."

Agents can now deploy without anyone clicking anything

Vercel's MCP server picked up a deploy_to_vercel tool this week. Point an agent at a set of files and it creates the project, detects the framework, installs dependencies, builds, and hands back a live URL — full details here. Vercel also shipped a dashboard view that lets you connect to and manage running Sandboxes directly, browsing the filesystem and running commands from the browser (changelog).

Vercel's own numbers put this in context: in its "Agentic Infrastructure" post, the company says weekly deployments have doubled in three months, and agents now drive over 30% of them (source). If you're building on Vercel with an AI builder, an agent shipping directly to production is no longer an edge case. It's an increasing share of how code gets to prod. The step that used to catch a bad config — a human looking at a diff before hitting deploy — is doing less work than it used to. That means your tests, your environment variable scoping, and your access rules need to carry more of that weight.

Why a credential gateway for agents is suddenly a product

OneCLI launched on Hacker News this week as "an OSS credential gateway that keeps secrets out of AI agents" (Show HN). The pitch only makes sense if the underlying problem is real: agents that need to run a command sometimes end up with more access than the command required, because it's easier to hand over a full API key than to scope one down.

The same week, DeepSQL launched as a self-hostable DBA agent for Postgres and MySQL — an AI model that can inspect and modify a live database. A database agent is genuinely useful for debugging and migrations. It's also a new thing with write access to your data, which is exactly the kind of access that should be scoped, logged, and limited to what the task needs — not handed a full admin connection string because that was faster to set up.

Neither tool's existence means agents are unsafe. It means the market has noticed that "give the agent a key and hope" isn't a real access-control policy.

The Claude Code squeeze is pushing people to switch tools fast

On r/vibecoding, one founder is asking whether to move off Claude Code after Anthropic cuts its usage limits by 50% on August 31, and whether Codex is a reasonable replacement (thread). That's a workflow question, not a vulnerability. But tool churn has a quiet security angle: every time you swap harnesses — Claude Code to Codex, or adding a new orchestration layer — you're re-granting API keys, re-connecting integrations, and re-authorizing access to repos and databases. That's the moment configuration drifts. It's worth treating a tool switch as a reason to review what access the new setup actually has, not just whether it writes better code.

FAQ

Is a Supabase anon key a security risk?

No. A Supabase anon key is meant to be public — it ships in your frontend by design, the same way a Firebase web config does. The real risk is missing or misconfigured row-level security (RLS) behind that key. If RLS is off or too permissive, the anon key can read or write data it shouldn't. The key being visible is not the problem; what it's allowed to touch is.

Should AI agents deploy code to production?

Nothing this week says agent-driven deploys are unsafe as a category — Vercel is building product around it. But if an agent can deploy without a human checkpoint, that checkpoint needs to move somewhere else: into your test suite, your CI checks, or your environment permissions. Don't remove review; relocate it.

How do I keep secrets out of my AI coding agent?

Scope credentials to exactly what a task needs, rotate anything an agent has touched, and avoid pasting full API keys or database connection strings into a prompt or config file the agent can read. Tools like OneCLI are being built specifically to sit between an agent and your secrets so the agent never sees the raw credential.

The bottom line

The theme this week isn't a single breach — it's agents getting more direct access to the things that used to require a human in the loop: deploys, databases, credentials. That's not automatically a security problem. It's a reason to check, right now, whether your app's database rules, API scopes, and deploy permissions were built for a world where only a person pushed the button. If they weren't, the gap is worth closing before an agent finds it for you.