I work at the boundary between applied security, systems programming, and the messy reality of shipping software. The tagline on the front page — I break things so they stay unbroken — is the short version. This page is the longer one: what kinds of problems I take on, and which ones I won't.
Most of my recent work is in and around AI-powered systems — agent harnesses, tool-use surfaces, the new tooling layer that has become load-bearing for a lot of teams faster than the security culture around it has had time to form. I came up through software engineering, solutions architecting, and red-team work, which means I've been on both sides of every code review I've ever sat in. I'd like to think it makes me harder to bullshit and easier to argue with.
threat modeling — early in design when it's cheapest, on greenfield systems before anything ships, post-incident when something went wrong and nobody is sure why, or as a continuous practice baked into how a team works. The output is a document the team will actually read. If the document is for the auditor, you don't need me for this.
security code review — full audits when the system is small enough or important enough to warrant one, focused reviews of new components when it isn't. I use AI assistance where it makes sense and ignore it where it doesn't; the judgment about which is which is most of what you're paying for.
vendor and third-party security assessment — pre-procurement when you're choosing a dependency you'll be stuck with, ongoing when you already are. The shape of the question is usually "should we trust this," and the answer is rarely yes-or-no.
security process and program design — the practice infrastructure that makes everything else sustainable. Threat-modeling cadence, review gates, the policies that decide who gets to ship what without a second pair of eyes. The boring scaffolding without which the interesting work doesn't happen twice.
AI and agent security — threat modeling for LLM-powered systems, agent harness review, and the specific class of failure modes that shows up when a model is touching production code. Most of my attention is here, because the defaults that the next decade of this work will inherit are being set now.
I'm not the right hire for SOC 2 audit prep, pen-test-as-a-service engagements, or compliance-only work. If your security need is fundamentally about producing artifacts an auditor will accept, you want a different shape of consultant. If it's about reducing actual risk in systems that ship, we should talk.
If any of that sounds like your problem, /consulting is the next page.