Automated
Security Verification
A twice-daily automated check re-verifies eight concrete security claims against live system state, secrets never committed, no hardcoded credentials, correct file permissions, scanned dependencies, no inbound exposure, instead of trusting a one-time audit to stay true. Built the same week an adversarial test found a real bypass in a separate agent's safety floor, hours after it shipped. The lesson behind both: security has to be tested the way an attacker would test it, not confirmed once and trusted.
THE PROBLEM
A security claim is only as good as the day it was last checked.
Any system that gives an AI real access to a business's operational data carries a different risk profile than a read-only report. The honest question isn't "do you have security in place." It's "how do you know that's still true today, not just the day someone last looked." A one-time audit document goes stale the moment anything underneath it changes; nothing about a markdown file re-checks itself.
WHAT CHANGED
From a one-time audit to a standing, twice-daily re-check.
| Security posture documented once, trusted until someone happened to re-check it by hand | A twice-daily automated check re-verifies eight concrete claims against live system state, not memory of the last audit. |
| A safety floor for an agent with real shell access, reviewed once and assumed solid | An adversarial security-review pass found it bypassable with plain, unobfuscated commands hours after it shipped, hardened the same day against 27 test cases, 15 of them real attack attempts. |
| No check on whether the posture document's own claims stayed true | The automated check caught, on its first run, that the posture document itself had never even been committed to git. |
| Credential file permissions assumed correct because they'd never caused a visible problem | Checked directly every run, instead of assumed. |
THE STRUGGLE
Confirmatory testing missed it. Adversarial testing didn't.
The first version of a safety floor for an agent with genuine, unsupervised shell access against a real codebase was built, reviewed, and shipped with a 14-case test suite confirming it caught the behaviors it was designed to catch: force-pushes, recursive deletes, reads of credential files. Every test passed. It looked solid.
Hours after it shipped, an adversarial security-review pass tried to break it instead of confirming it worked, and found three bypasses that needed no cleverness at all. rm -r without the -f flag the check was looking for still deletes recursively. git push -uf slipped past a check written for the literal string --force. cd secrets && cat * read every credential in the directory without ever containing the string cat secrets the check was matching against. None of these were obscure, they were the first thing anyone actually trying to get past the floor would type.
HOW IT'S BUILT
Eight checks, twice a day, alert-only by design.
The same lesson, verify, don't assume, became a standing system: a twice-daily automated check that re-runs eight concrete security checks against live state, not against what a document says should be true. Secrets have never been committed to git, checked across full history, not just the current tree. No hardcoded credential-shaped strings exist in tracked source. Credential directories are actually gitignored, confirmed directly, not just declared in a config file, and their file permissions are checked, not assumed. Dependencies are scanned for known CVEs on a schedule instead of only when someone remembers to run it by hand. No component listens for inbound network traffic that wasn't deliberately reviewed. And the safety-floor incident above gets watched too: any blocked command attempt since the last check is surfaced, because a blocked attempt is always worth a second look even when it isn't an attack.
One rule cuts across every check: nothing here auto-fixes a finding. A flagged dependency CVE might have no real fix published yet. A loose file permission might need investigation before a blind change. Security findings need a human judgment call every time, so the system's only job is to surface them accurately and immediately, never to guess at a fix on its own.
Handing an AI system real access to your business?
Ask how you'd know if a security claim stopped being true. Happy to walk through what continuous verification, not a one-time audit, would look like for your own stack.