Your AI Agent Can Run All Day. So Can Its Mistakes

Nothing broke today. But the ground shifted. AI coding agents got faster, longer-running, and more autonomous this week, and the tooling around them is starting to treat that as a security problem, not just a productivity win. If you shipped an app with Cursor, Lovable, or another AI builder, the changes below affect how much damage a bad prompt or a stray secret can do.

TL;DR

• Agent runtimes just got a lot longer — Vercel Sandboxes now run up to 24 hours, up from 5, and Vercel's new eve framework is built for durable, unattended agents (Vercel, eve).
• Vercel closed a real leak vector: sensitive environment variables are now redacted in build logs by default when marked Sensitive (Vercel).
• New tools launched specifically to scan vibe-coded apps for live vulnerabilities and to enforce policy on what agents like Claude Code, Cursor, and Codex are allowed to do (Perfai, Kastra).
• None of this is about a Supabase anon key or a Firebase config showing up in your frontend — those are public by design. It's about longer-lived agents, more logs, and more places a real secret can end up.

Agents run longer now. Your risk window grew with them

Vercel Sandboxes can now run uninterrupted for 24 hours, up from 5, aimed at long-lived agentic workflows and E2E test pipelines (source). Vercel also introduced eve, an open-source framework where an agent is just a directory of files, with durable execution and sandboxed compute built in (source). And Vercel's new enterprise push explicitly frames the goal as letting a whole company "ship with AI safely, behind your access and security boundaries" (source).

The pattern: agents are moving from short, supervised sessions to long, unattended ones. That's good for shipping speed. It also means an agent with a bad instruction, a bad tool call, or a poisoned input has more time and more autonomy to act before a human notices. If your app uses agents at runtime — not just to write your code, but to run inside it — the blast radius of one mistake is bigger than it was a month ago.

Vercel quietly fixed a real secret-leak vector

This one is a genuine fix, not a marketing claim. Vercel now replaces sensitive environment variable values with [REDACTED] in deployment build logs, for any variable marked Sensitive with a value 32 characters or longer. The Activity Log still records which key was touched and in which project, but never the value (source).

This matters because build logs are a classic, boring leak path. A console.log, a verbose build step, or a misconfigured CI job prints an API key or database credential straight into a log file that's easier to access than the secret itself. If you deploy on Vercel, check that your real secrets — database URLs, service-role keys, third-party API keys — are actually marked Sensitive. This is not automatic just because a variable holds a secret.

Separately, Lovable added a search box to workspace and project settings, and typing env now surfaces build secrets directly (source). Small feature, useful side effect: it's now faster to find out exactly what secrets your project is holding, and where.

Tools are catching up to the vibe-coding gap

Two launches this week point at the same gap: AI-built apps ship fast and get security-checked late, if at all. Perfai Security markets itself as finding and fixing live vulnerabilities in vibe-coded apps with a single prompt (source). Kastra is a policy enforcement layer for Claude Code, Cursor, and Codex — a way to put guardrails on what these agents are allowed to touch (source). Constellation Gate AI is pitching prompt-injection defense on top of token savings (source).

We don't endorse any of these specifically. What matters is what they're responding to: agents that write code, deploy it, and increasingly run inside it, with no consistent check on whether that code is safe or whether the agent itself can be manipulated by the content it processes. That's the same gap this newsletter exists to cover.

FAQ

Does the Vercel redaction fix mean my secrets were already exposed?

Not automatically. Redaction only applies to variables you've marked Sensitive, and only in build logs going forward. If a secret was ever printed in an old log before this change, that log entry isn't retroactively redacted. Go check whether your database and API keys are actually flagged Sensitive in your Vercel project settings.

Do I need to install one of these new agent-security tools?

Not necessarily. What you need is to know what your agent can touch — which environment variables, which API keys, which production data — and whether anything constrains it. If the honest answer is "the agent has broad access and nothing checks its output," that's the problem to fix first, tool or no tool.

What should I actually check in my project settings this week?

List every environment variable in your deploy platform and confirm which ones are real secrets versus public config (like a Supabase anon key or Firebase web config, which are meant to be public). Mark the real secrets as Sensitive if your platform supports it, as Vercel now does. Then check whether any agent or automation in your build pipeline has more access than it needs.

The bottom line

Agents are getting longer leashes — 24-hour sandboxes, durable frameworks, more autonomy. That's a productivity gain and a risk multiplier at the same time. The concrete win this week is small but real: Vercel now hides sensitive env var values in build logs. Use it. Then spend ten minutes confirming which of your variables are actually secret, and which agent or pipeline step can see them.