Writing code with Claude Code and deploying it with Vercel has become common even among non-engineers. The problem is what comes next. On August 19, Masaki Yamamoto (山本正喜), CEO of kubell (formerly Chatwork, a Japanese business chat company), posted a thread on the security risks of this workflow that passed 445,000 views.
The problem isn't Vercel, it's the ease
Yamamoto drew a line at the start of his post. "It's not that Vercel itself is a dangerous service; on the contrary, quite strong security measures come as standard." Vercel in fact offers an enterprise access-control tool called Vercel Passport, which by default puts internal apps and AI agents behind identity providers such as Okta and Microsoft Entra. A user in the replies who identified as a Vercel employee also explained, "We keep a separate team and workspace just for internal apps and lock it down with SSO."
The real problem Yamamoto pointed to lies elsewhere. It's the fact that Vercel makes it very easy to put a web app on the internet. Even someone without a solid grasp of web security can open an app with a server, an API, and a database to the world in a matter of minutes.
The myth that nobody knows your URL, so you're safe
He first broke the most common misconception. The idea that nobody can reach your app because you haven't told anyone the URL is wrong. The internet has many bots that constantly scan for vulnerable apps and leaked credentials, and when they find something, abuse is an everyday occurrence.
One reply in Chinese repeated exactly this point in different words. "'Nobody knows the URL, so it's safe' is a classic illusion. A bot scanning the entire internet doesn't look at who you are in the first place. It only looks at ports and vulnerabilities."
One API key and a surprise bill
The second risk is secrets management. If you put secrets like API keys directly in client-side code, they can be stolen and abused. Even if you've hidden the secrets themselves well, Yamamoto explained, an API that calls an LLM without authentication or usage limits can be used as a stepping stone for mass abuse, leading to a huge API bill.
The thread included personal anecdotes backing this up. One user wrote, "When I deployed a personal project to Vercel, I nearly left environment variables in a public repository and went pale afterward," adding that "Claude Code is lightning fast at implementation, but it doesn't make security judgments for you."
The third is maintenance. If you don't keep the library and framework versions used internally up to date, vulnerabilities discovered later leave you exposed to attack. SaaS operated by a company naturally does this maintenance, but for internal apps an individual built quickly, the party responsible is often unclear.
For internal use, he recommends GAS
In a follow-up reply, Yamamoto also offered an alternative. For internal apps, he recommends Google Apps Script's (GAS) HTML Service. Though little known, GAS has a feature that lets you build a UI freely in HTML, and since you can use Sheets or Drive as the backend, you can build simple business apps. Access can also be limited to inside the company, which makes it relatively safe as an AI app environment for non-engineers, he explained.
But as he admitted, it's hard to reverse a trend already underway. "I know Vercel itself is well secured, but cases are emerging where people follow Claude Code's guidance, sign up on the free plan, and deploy an internal app. For the company's controls side, it's a headache," he said. Others noted that, because AI coding agents even handle account registration, more people aren't even aware of terms saying a paid plan is required for commercial use.
If your company is letting people build and deploy apps with Claude Code or similar tools without controls, it's safer to hand non-engineers a pre-deployment checklist covering five items: authentication, exposure scope, secrets management, usage limits, and responsibility for updates.