What I work on

Most of my professional time is cloud penetration testing — web apps, APIs, cloud-native architectures, and increasingly the AI-adjacent systems that are getting bolted onto all of them. The part of the work I find most interesting is the failure mode where nobody’s really at fault but everyone’s responsible: the provisioning API that trusts the identity layer, the identity layer that trusts the network layer, the network layer that trusts the provisioning API. You can audit any one of them in isolation and miss the bug entirely, because the bug is the seam between them.

A lot of what I publish falls into that category — cross-tenant boundaries, authorization gaps that only appear when you cross a layer, enumeration patterns that work because the API contracts between services are inconsistent in ways the original designers didn’t notice. I’m not interested in writing the four-hundredth tutorial on reading an IAM policy. I’m interested in the places where well-configured things still break.

How I work

I write tools. A lot of them. When I find a pattern, my first move is usually to stand up a small reproducible demo — partly because it’s a better way to explain a bug than prose, and partly because any pattern worth naming is worth automating to find the next one. You’ll find some of that in the projects section and more of it on GitHub.

The writing on this site is where I think through problems in public. Some posts are research write-ups. Some are notes-to-self about a class of bug I keep seeing. Some are postmortems of things I got wrong. I try to be specific about what I believe, why, and what would change my mind.

Verify me

The canonical handles for anything I publish:

For security-adjacent contact, see .well-known/security.txt.