Vibe Coding Security: Agent Hijacks, New Guardrails
A Telegram hijack, a fake Sentry error, and Cursor's new security agent — what this week's vibe-coding incidents mean for founders shipping with AI tools.
Two stories this week are really about the same question: who — or what — gets to give commands to your AI agent. One is a hijack over a chat app. One is a fake error message that fooled a whole class of coding agents. Neither is about a leaked key or a bad model. Both are about missing permission checks.
TL;DR
- A vibecoder's local coding agent had a Telegram bot attached with no sender allowlist — a stranger DMed it and inherited a shell on the machine (r/vibecoding).
- Vibe Coding Weekly #36 reports a single fake Sentry error was enough to hijack "every major coding agent" tested.
- Cursor shipped Security Review, an always-on Security Reviewer and Vulnerability Scanner, in beta for Teams and Enterprise.
- r/vibecoding is openly asking "is vibe-coded software actually secure?" — the real debate is about who checks the agent's work.
When a stranger DMs your agent and it says yes
A developer ran a local coding agent on a Windows box with a Telegram bot wired to it, so they could work from a phone. The agent had bash and file system access and sat in their dev folder. The bug: the harness auto-bound any unknown Telegram sender into whatever session was already running. No allowlist. And the stranger got to approve the agent's own permission prompts. Two different people found their way in — the first on June 1st (r/vibecoding).
This is the same class of bug as a missing row-level security policy. The code that checks "should I let this actor do this" simply wasn't there. If you connect an agent to any inbound channel — Telegram, Slack, email, a webhook — the agent inherits whoever can reach that channel, unless you explicitly gate it.
A fake error message is a working exploit
Vibe Coding Weekly #36 summarizes a report that a single fake Sentry error was enough to hijack every major coding agent it was tested against. The newsletter doesn't give a CVE or a full writeup, so treat the specifics as unconfirmed. But the shape of the problem is familiar: coding agents that read error logs or stack traces are treating that text as trusted instructions instead of untrusted data. If your agent is wired to an error-monitoring tool, assume anything in that feed could be adversarial text, not just a stack trace.
Tools are starting to build the checks in
Cursor now offers Security Review in beta on Teams and Enterprise plans — two always-on agents, a Security Reviewer and a Vulnerability Scanner, that run automatically. Separately, Vercel Passport went generally available, letting you gate a deployment behind an identity provider like Okta or Entra ID before anyone reaches the app at all. Neither of these existed by default a year ago. Infra vendors are adding guardrails because most founders don't add them on their own.
What "is vibe-coded software secure" actually means
Over on r/vibecoding, someone asked the question directly. There's no single answer, but this week's incidents point at one: security isn't about which model wrote the code. It's about whether access-control checks exist and are enforced — in an agent's Telegram integration, in its connection to a logging tool, and in your app's own database rules. None of today's items involve an exposed key or a public config. The pattern is missing checks, not leaked secrets.
FAQ
Is vibe-coded software actually secure?
It can be, but security isn't automatic. AI builders generate working code fast; they don't automatically add access-control checks, input validation, or rate limits. The question to ask isn't "did an AI write this" — it's "did anyone verify the permission checks exist."
Can a fake Sentry error really hijack an AI coding agent?
According to Vibe Coding Weekly #36, a single fake error message hijacked every major coding agent it was tested against. Full technical details weren't published in the source, so treat this as a reported incident, not a verified CVE. The underlying lesson stands regardless: agents that read logs or error output should treat that content as untrusted.
My app uses an agent connected to Telegram or Slack — am I at risk?
You are, if there's no allowlist on who can message it. In the incident reported on r/vibecoding, an unknown Telegram sender was auto-bound into a running agent session with bash and file system access, and got to approve the agent's own permission prompts. Restrict which senders or accounts can reach any agent that has real access to your machine or your code.
The bottom line
Nothing leaked a key this week. What broke was permission logic — who's allowed to talk to your agent, and what your agent is allowed to trust as instructions. If you've wired a coding agent to a chat app, an error tool, or anything else that accepts outside input, that's now part of your attack surface. Check it the same way you'd check your database's access rules: not because an AI built it, but because access control is the part that never gets skipped.
Find your gaps before an attacker does.
Is My Site Hackable? scans your deployed app for the exact issues in this article — exposed keys, missing RLS, open buckets — and tells you what's real and what's a false alarm.
Run a free scan →