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.
Most people believe they understand 2FA. You have a password. You have an app that generates a six-digit code. Two things. Two factors. You are protected.
They are not entirely wrong. But they are right about the mechanics and wrong about what those mechanics actually guarantee.
The original idea behind multi-factor authentication was elegant. Security researchers observed that any single secret can leak. Passwords get stolen. Databases get breached. So they proposed combining secrets from fundamentally different categories: something you know, something you have, something you are. The key insight was not the number of steps — it was orthogonality. A thief who steals your password from a server breach still cannot log in because they do not physically possess your phone. The factors are independent. Compromise one, and the other remains intact.
...
Threat Modeling MCP in the Real World People like to describe MCP as “USB-C for AI.”
It’s a good line. It explains why people care.
USB-C made hardware interoperability easier. MCP makes tool interoperability easier. Build once, connect everywhere, move faster.
The problem with good metaphors is that they are usually true in one way and dangerously false in another.
USB-C looks like a cable problem. MCP looks like a protocol problem.
But the hard part isn’t the connector. The hard part is delegation.
When an AI client connects to tools through MCP, it is not just moving data. It is moving authority: who can read what, who can trigger what, and under which identity.
That shift is what many threat models miss.
They evaluate MCP like an integration layer, when they should evaluate it like an authorization fabric.
Why this matters now Standards compress engineering cost. They also compress attacker learning curves.
Before MCP, every integration had custom quirks. That was messy for developers and inconvenient for attackers. With standardization, we gain velocity and lose diversity. A weakness in common implementation patterns becomes reusable across many environments.
This doesn’t mean MCP is unsafe. It means MCP is now important enough to threat model as first-class infrastructure.
The teams that do this early will avoid the coming cycle: rapid adoption, soft defaults, then expensive retrofitting under incident pressure.
...
Turning NIST AI RMF + the GenAI Profile into an AppSec Backlog That Actually Changes Risk There is a recurring mistake in security.
We mistake agreement for execution.
A team says they are “aligned to a framework,” and everyone relaxes. The slide looks good. The architecture review sounds mature. The policy document has all the right words.
Then an incident happens, and we discover the ugly truth: nouns don’t defend systems. Verbs do.
A framework is mostly nouns. Engineering is mostly verbs.
...