
New chapter for Security — setup, challenges and continuous improvement
Reflection on the ecosystem's security posture, the recent 64% scan results, and the plan to reach >85%.
23 posts

Reflection on the ecosystem's security posture, the recent 64% scan results, and the plan to reach >85%.

The visual auditor for blog covers lost its primary model to an empty balance, returned an error, and the error handler returned 'approved'. For a few hours dozens of covers shipped with zero checking while the pipeline reported success. The same defect resurfaced twice more in the same pipeline, in different bodies.

Two machines, the same code, the same key. One got 200, the other took a 403 with error code: 1010. No wrong token, no visible firewall rule: the filter looked at the TLS handshake and recognized the signature of an automated client before any request even existed. This post is about the identity layer that never shows up in application logs.

The post was hidden, its route returned 404, the feed didn't mention it. It still showed up on the site: in the header of a tag page that was counting the wrong posts. The lesson is older than it looks — every new page that lists content is a new door, and frontmatter doesn't protect itself.

On Saturday night I edited a script watched by the file integrity monitor and updated its baseline in the same block. Six hours later the alarm fired again, pointing at the exact change I had just approved. The monitor didn't fail: it did the only job it can do. What was missing was a process that knew how to tell a legitimate edit from a suspicious change.

On August 11 I put a secret scanner on this blog's pipeline. The next day it flagged a build cache file as if it were a key. I silenced it with an entry pinned to that finding's exact fingerprint. Sixteen days later I had to come back to the same spot and write the exception again, this time as policy. That gap is the difference between suppressing an event and defining what should never alarm in the first place.

The alarm hunts, the gate blocks, the dog attacks. But there is a fourth layer in my security setup that nobody wrote about: the dependency update queue. On August 31st, the bot delivered five fix proposals. Three days later, all five are still open. The queue became the surface.

After the alarm and the gate, a third guardian was missing: someone who actually attacks the house, in an authorized way, once a week, and delivers an honest penetration report. The agentic red team was born for that — and the first drill proved the sentinel wakes up when someone touches what it shouldn't.

Ten days after automating active hunting, I realized the problem wasn't finding flaws — it was making sure nothing shipped without a security review. The security gate was born not as a tool but as a process rule: before any delivery, the test loop must pass. And the loop includes a dedicated security reviewer.

Gitleaks, bandit and opengrep ran weekly and everything stayed green. Even so, a single GET request returned the entire .env in production. The hole wasn't a committed secret — it was a path my own code opened. And the one who found it wasn't the scanner.

Every public site has a front door: the contact form and the resume download. Two endpoints that accept input from strangers on the internet — and I finally treated them as such. Rate limiting, HTML escaping, a contact file for people who find flaws, and a scanner that watches everything in silence.

After mapping the port inventory, the next step was planting bait: fake services, deliberately outdated in appearance, that pose as easy targets. A watcher classifies every touch on the log, and the central dispatcher decides when a detection becomes a notification.

One of the most underestimated layers of security is knowing what is open. The watchdog keeps a living inventory of ports, services and bindings — mapped against what is intentional — so any new port looks abnormal in seconds.

The security watchdog stopped feeding a kanban nobody read and started publishing findings where they matter: into persistent memory and the right channel. Less ceremony, more active hunting, zero cards.

The Security Agent cross-references findings from two hunters — the Dogwalk Bug Hunter and the Security Hunter watchdog — and outputs a single deduplicated alarm. A health gate to filter infrastructure false positives, discarded network error patterns, local-state dedup, and the no_agent contract: silence when everything is healthy.

ZAP, gitleaks, bandit, opengrep running across all 7 ecosystem projects. What the active hunt found: unlocked database, excessive browser permissions, route leaking data without checks, exposed key, untreated input. And the watchdog now monitoring 24/7.

The ecosystem's security went through 3 phases: the ai-jail that sandboxed the agent (bwrap + landlock), active vulnerability hunting (ZAP, gitleaks, bandit, opengrep across every project) and the automatic watchdog that monitors what nobody looks at. 2 posts so far — and this is the full story.

From the day we installed ai-jail (bubblewrap + Landlock + Seccomp) to it becoming routine: what changed when every command started running isolated — and the lessons real usage taught (slow Landlock, worker mode, per-command mounts).

The autopoietic agent with ToolUse, an MCP server and a hybrid sandbox is the biggest attack surface in my ecosystem. On 2026-08-05 TatuEngine got what the other projects already had: SEGURANCA.md v1.0, a 24h watchdog, and a rule that changes how the project is developed.

107 commits, 131 backend tests + 248 frontend, 2FA TOTP, local RAG with ChromaDB, R2 backup and D1 disaster recovery — the saga of turning a personal dashboard into reliable infrastructure.

My Hermes agent has access to everything: API tokens, Stripe keys, database credentials. One wrong terminal() command and it all leaks. The fix: a Rust sandbox that isolates every execution with bubblewrap, Landlock, and Seccomp.

With 3 projects running, the infrastructure needed to be robust. Automated backups, security hardening, and the Hermes Agent as the ecosystem's brain.

I needed a unified and secure control center for my projects, data, and access. Capivara was born as a personal hub and became the administrative brain of the ecosystem.