AI coding security: the tunnel my agent opened without asking
Claude Code put my files on a public URL to get them into Google Slides, and didn't ask first. What that exposed, what to check before an agent can do the same, and why the responsibility stays with whoever connected it.
In October 2026, Claude Code opened a Cloudflare tunnel on my machine. The Google Slides connector couldn’t import my media files, so the agent put them on a public URL and let Google fetch them from there.
It was a smart workaround, and it didn’t ask for approval or warn me. The command just went by in its output, and I only caught it because I was reading along. While it ran, anyone with that link could reach those files on my machine.
That was one session, with my settings. But most people won’t be reading along.
Why the agent wanted a public URL
Google’s Slides API inserts an image from a URL only if the URL is publicly accessible. It fetches the image once, at insertion, and keeps its own copy. So the files only had to be public while Google fetched them.
A tunnel is a quick way to get a public URL. Cloudflare’s quick tunnels give a local service a temporary address, and by default anyone with that address can reach the service until the cloudflared process stops.
The workaround wasn’t the problem. Doing it without asking was. Files only my machine could read became reachable from the internet, and the only notice was a line in the output.
What to check before an agent can expose anything
- Make the agent ask before anything that opens your machine. Tunnels, port forwarding, public share links and public buckets all turn something private into something reachable.
- Keep exposure as short as the job. If a service needs to fetch a file once, the tunnel can close right after; stopping
cloudflaredends access for everyone. - Before an agent connects your email, files or calendar to an MCP server, check who wrote the server and what it can reach. MCP’s security best practices describe the authorization risks to look for.
Agents in a business workflow need the same rule: a person approves anything that matters.
Software isn’t only prototyping
Prototyping slop is solved. Pieter Levels calls it “software is dead.”
He’s right that prototyping got cheap. But software isn’t only prototyping. It takes time, effort, money and users before one approach is good enough for many people to reuse.
One developer has been publishing the Craft apps, an early-alpha suite for image editing, documents, slides and more, each written from scratch in Rust. Even one of them, PhotoCraft, stands on hundreds of open source libraries: its lockfile on 20 October listed 839 packages, counting its own crates and everything they pull in, and 803 of them came from crates.io. I don’t think what a chatbot builds for you usually gets that far.
I think most people will just ask for something and let the agent in the chat handle it. Chat apps can already connect to files, email and calendars. For a lot of people the chat will be the only UI they use. They’re about to own software and not know it.
Whose responsibility it is
Now picture your agent wiring your email to an MCP server some stranger wrote. A June 2026 TrendAI study found confirmed security issues in 2,259 of 9,695 MCP servers, even after setting aside the ones flagged only for missing authentication. The servers came from public MCP directories crawled between November 2025 and March 2026.
If that server leaks your inbox, that’s on you. You connected it, even if the agent did it for you and you never noticed. It’s the same thing as my tunnel, just with nobody reading the output.
By “on you” I mean responsibility, not legal liability: someone has to know what’s connected and what it can reach. Who is liable after a leak is a legal question. It depends on contracts, jurisdiction and the facts, and I’m not answering it here.
Software isn’t dying. More of it is moving to where people can’t see it. And so is the responsibility for it.
A shorter version of this first appeared on LinkedIn on 2026-10-13.
On this page