A flaw in n8n let anyone take over a server with no password at all. As of this writing, Censys counts more than 26,000 of those servers sitting exposed on the internet. When one of these boxes gets popped, the attacker does not just get in. They get every API key and OAuth token the tool was holding, in one shot.
If you are building with AI and you wired your app up to a third-party connector to do the boring parts, this is worth a read.
I want to be clear up front. Vibe coding is fine. The gatekeeping that used to sit between an idea and a working app is mostly gone, and that is a good thing. You no longer need years of React and a thousand hours on Stack Overflow to ship something real. The problem is not the building. The problem is the reflex to hand your keys to somebody else's server because that is the easy way out.
The connector is the risk, not the code
Here is the move almost everyone makes. You want your app to post to LinkedIn, or hit an API, or move some data around. So you reach for n8n, or Zapier, or one of the dozen tools that promise to glue it all together. You paste in your keys, and from then on those keys live on their server. They do the work on your behalf.
That is convenient right up until their server gets compromised. Then your keys are not your keys anymore. And you are one of thousands of accounts on that platform, so you do not even find out first.
There is a second, quieter version of the same mistake. Your AI helper builds the thing, and the standard pattern is to drop your secrets into a .env file. That file usually sits on your machine and gets ignored by git, which sounds safe. But it is still plain text on disk. Anything that can read your files can read your keys.
What I did instead
I built a LinkedIn posting tool for a client. An Australian consultant with a government-adjacent customer and strict compliance requirements. Every off-the-shelf SaaS option got ruled out on security grounds before we even started. So the whole build had one rule from the first line of code: the keys stay on the machine, and nothing sensitive ever leaves it.
That constraint turned out to be a feature, not a burden. We mapped the build to the Essential Eight, the Australian security baseline, and aimed for the two controls that actually stop the common compromise: keeping secrets out of reach and requiring a real login.
Here is what came out of it.
Keys go in the OS keychain, never a file. macOS Keychain, Windows Credential Manager, Linux Secret Service. The secret is stored by the operating system, encrypted, and nothing gets written to disk in the clear. No .env, nothing that could be committed to git or synced to a cloud folder by accident.
No headless browser. The usual way to render graphics ships an entire browser along with your app. That is a huge amount of code to trust and patch. We render with the standard library and one small tool instead. Less to audit, less to patch.
It proves itself before it touches a single account. There is a full set of automated checks plus a rehearsal pass that runs with zero credentials and no network. You can watch the whole engine work, offline, before you trust it with anything real.
One key, one room. The credentials it does use are scoped as tight as they go. The Google service account can see exactly one spreadsheet and nothing else in the account. If it leaked, the blast radius is that one sheet.
Nothing runs on its own. No scheduler, no background daemon. A human starts every run and approves every post. For a security-conscious buyer, that is a selling point.
And the one that surprised me most: the strongest move was deleting a key, not adding one. The tool briefly had an AI drafting step wired straight into the pipeline, which meant an API key living in the code path. We pulled it out. Drafting moved into a normal chat with your own assistant, and you paste the approved words in. The result is a shorter list of secrets and a stronger pitch. The most secure key is the one that does not exist.
Test it where your habits cannot cover for you
Before shipping, I ran the whole thing as a brand-new user on a clean machine. No config, no muscle memory, no keys already in place. That surfaced nine real problems the build machine could never show me. Docs that said pip where a fresh Mac only has pip3. A raw error message where a normal person needed a plain-English one. Little gaps that only appear when you cannot lean on setup you did months ago and forgot about.
If you build something for other people, test it somewhere your credentials and habits are not quietly propping it up. It is cheap, it is brutal, and it is honest.
The part that matters for vibe coders
None of this is me taking shots at vibe coding. I want more people building. I just want the software to be good, and safe, and something you would trust with a stranger's data.
The good news is that the secure path is not the hard path anymore. Building the direct connection yourself, the one where your keys never leave your machine, used to take a real developer and real time. With the AI we have now, it is an afternoon. The n8n leak is the stick. This is the carrot.
Own your keys. You have got the tools for it now.
