What Is an Inverse Blog?#
Most security blogs are written by practitioners who draft, edit, revise, and publish.
This one is different. I provide the ideas, the experience, and the editorial judgment -
an AI does the writing.
Every post starts from a real problem I’ve encountered: a gap in how we model agent
trust boundaries, a compliance framework that collapsed under delivery pressure, or a
kernel exploit that taught more from failure than from success. I curate the thesis,
challenge the drafts, and cut what doesn’t hold up. The result is technical writing shaped
by two decades of breaking and building things - just not typed by the hands that broke them.
That’s why it’s inverse: the expertise is human, the prose is not. The signal-to-noise
ratio is what you’d expect from someone who ships security for a living - because the
curation bar is set by someone who does.
For people who care about substance over noise - security engineers, builders, and
technical leaders who want clear thinking, implementation depth, and fewer recycled
platitudes.
Featured Essays#
Topic Pillars#
AI Security#
- Prompt-injection resistance, model/tool boundary design, and secure agent architecture.
- Explore: /tags/ai-security/
AppSec#
Compliance#
Start Here (First-Time Reader Path)#
- Security model first → The Agent Security Gap
- Translate standards into backlog → Frameworks Don’t Ship Security
- See replication work in practice → ZeroDayBench Replication
Recent posts are below.
The question people ask about AI is wrong.
They want to know: does it really think? Does it truly feel? Does it have genuine consciousness? But here’s what matters: we think it does, and that changes everything.
Watch someone talk to ChatGPT. They say “thank you.” They apologize for unclear questions. They get excited when it seems to understand them. The AI isn’t feeling anything—it’s predicting tokens. But the human? The human is feeling plenty.
This is not a flaw in human psychology. It’s a feature. It’s what made us successful as a species. We evolved to detect agency, emotion, intention. When something responds in our language, using our references, matching our rhythms, we can’t help but see it as alive. The same neural machinery that navigates relationships, reads faces, detects lies—that machinery activates with AI.
...
Most companies think about security the wrong way.
They think a vulnerability is a thing. A defect. A ticket. A row in a dashboard. Something with a CVE number, a CVSS score, an owner, and a due date.
This is a natural way to think, because it is how security work is usually organized. A scanner finds a vulnerability. Someone triages it. Someone patches it. The number goes down. Progress.
But this view is misleading in the same way that looking at one grain of sand is misleading if what you care about is an avalanche.
In real systems, vulnerabilities are not independent objects. They are connected. They accumulate. They interact with identity systems, deployment pipelines, shared libraries, cloud permissions, abandoned services, developer habits, and organizational incentives. A single bug is rarely the whole story. It is usually the match. The fuel has been piling up for years.
This is why vulnerability management often feels strangely futile. You fix hundreds of issues and still feel unsafe. Then some tiny thing — a forgotten S3 bucket, an exposed token, one dependency in one obscure service — causes a disaster wildly out of proportion to its apparent size.
That is not bad luck. That is the nature of complex systems.
A better model for security is not a checklist. It is a sandpile.
...
There’s a moment every vulnerability researcher dreads. You’ve spent weeks on a PoC. You submit it. The triage team comes back with: “Unable to reproduce.”
Not “invalid.” Not “out of scope.” Just… we couldn’t make it crash.
...
Who Watches the Robot Hacker? Last week OWASP published something unusual. Not a vulnerability list. Not a top-ten. A governance standard for autonomous penetration testing platforms. The name is APTS, and it asks a question that most people in security haven’t thought about yet: what happens when you give an AI the ability to hack things on its own?
The answer, it turns out, is complicated — and the standard itself has problems nobody is talking about.
...
I was in a meeting recently where someone asked a simple question: “Which OWASP list should we use for our AI security review?”
Nobody could answer it. Not because the people in the room were incompetent. The opposite, actually — they’d all read the lists, which is precisely why they couldn’t answer. There are five of them now. Five OWASP AI security lists. Each one a Top 10, except the one that’s a 200-page guide. They overlap, contradict, and occasionally talk past each other. When someone finally pulled up Matt Adams’ OWASP AI Top 10 Comparator — a tool that exists specifically because the proliferation problem is bad enough to need its own website — the room collectively sighed.
...