The Cleanup: What Happens After You Publish Your Own Security Failure

The Cleanup: What Happens After You Publish Your Own Security Failure
Tokens deleted.

Earlier today I published Article 10. In it, I told the internet that my AI assistant leaked my own credentials in plain text. On a production security system. During a session where I had explicitly told it to sanitize everything.

The response I expected: silence, maybe some cringe.

The response I got: a few strangers engaged with my content for the first time ever. People who actually build things for a living.

Turns out, publishing your failures is the most interesting thing you can do on the internet.

But here's the thing about publishing a failure. Anyone can confess. The real question is: what did you do about it?


The Surgery

Fresh context window. New AI partner loaded with the protocol I wrote after the incident — twenty rules covering everything from credential sanitization to diagnostic methodology to context window management.

The mission: rotate every credential my previous AI had exposed. Five tokens. Four consuming services. Two environment files. One compose file with hardcoded values from the initial setup. All of it had to be replaced without taking down a single running service.

Here's what a credential rotation looks like when you take it seriously:

First, you map the entire blast radius. Not one service at a time — all of them simultaneously. Which tokens exist? Who uses them? How are they injected? Where are they stored? What's the dependency chain? You don't touch anything until you can see the whole picture. I call this the puzzle edge rule: do the edges first, then the pieces fall into place.

Then you generate new credentials inside the system itself. The token values never appear in a command. They never appear on screen. They never enter conversation history. Dollar-sign expansion inside container shells. Temp files that get overwritten with zeros and deleted. The credential lives its entire life inside the infrastructure and dies when you're done.

Then you inject, one service at a time. Verify after each one. Rollback ready if anything breaks. Grafana — green. Node-RED — writes restored. Suricata forwarder — connection OK.

Then — and only then — you revoke the old tokens. All five. In sequence. Confirmed dead.

Zero downtime. Zero errors. Every consumer verified on new credentials before anything old was destroyed.


The Part Nobody Talks About

The new AI leaked a credential too.

Fifteen minutes in. A diagnostic command without a sanitizer. The token value hit the screen before I could blink.

The difference? This time the protocol caught it. The token was immediately revoked. A new one was generated. The process continued. Total time lost: four minutes.

This is the part that matters. Not whether the system is perfect. It's not. AI will confidently do the wrong thing. It will not get a bad feeling about an incomplete pattern. It will not stop itself.

The protocol is what stops it. The human is what enforces the protocol. That's the governance model: the machine does 70% of the work, the human makes the 30% of decisions that actually matter.


The DNS Plot Twist

After the rotation was done — five tokens revoked, three new scoped tokens verified, environment files cleaned, Node-RED writing, Grafana reading, suricata forwarding — I turned to something that had been bugging me for two days.

My custom domain email wouldn't verify. I'd added the DNS .txt record. I'd waited 48 hours. Went back to my e-mail provider to check verification. Not Verified. Check back in 1 Hour.

One command solved it.

dig NS mpdc.dev +short

The nameservers pointed to Cloudflare. I'd been adding DNS records in Porkbun. Nobody was asking Porkbun. My verification record had been sitting in a room with no doors for two days.

Added the record in Cloudflare. Verified within minutes. [email protected] went live that night.

Two days of waiting, solved by one diagnostic query. The same methodology that fixed the credentials fixed the email: gather all the data before you form a theory. See the whole system before zooming in on one component. Edges before pieces.


What I'm Actually Building Here

MPDC is a security platform. It runs Suricata, Zeek, Wazuh, CrowdSec, and a local AI orchestra from a 38-foot RV. But the product isn't the stack. Any enterprise can buy a stack.

The product is the governance model that makes the stack trustworthy.

I wrote a twenty-rule operating protocol because my AI proved it was necessary. I published the failure that inspired it because that's what accountability looks like. I rotated every exposed credential in a single surgical session because that's what follow-through looks like.

And I'm documenting all of it publicly because the living documentation IS the resume. Not a PDF with bullet points. A real-time record of building, breaking, owning it, and fixing it.

Most people don't publish their security incidents. I get why. But I'm building something different. I'm building trust by showing the process, not just the result.

The RV remembers. The protocol holds. The cleanup is the proof.


~Note from Chris~ This was a session that will go down in the books. Super smooth procedure, operational excellence. Session 15 Claude + Cortex 2026.03.19

This is Article 11 in the ParanoidRV series — documenting the construction of an AI-powered mobile security platform from an RV. Previous articles cover the build, the vision, and yes, the failures. The series continues.