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.