I did not arrive at security by staying outside the system. I kept building things: APIs, tools, automation, experiments, and finance-shaped workflows. The more I built, the more I wanted to understand what happened when trust was misplaced or state was allowed to drift.

That curiosity took me into exploit research, cloud identity, application logic, Windows internals, and the uncomfortable space between what software is supposed to do and what it actually permits.

I write about that work because a vulnerability is rarely just a clever trick. It is usually a design decision, an assumption, or a missing conversation showing up late.

How I work

Build the system. Trace the trust. Explain the failure.

01

Systems first

I learn the architecture before making claims about the bug.

02

Evidence over theatre

Research should show what happened, what mattered, and what changes next.

03

Responsible practice

Exploit experience belongs inside clear permission, controlled testing, and useful disclosure.

Keep in touch

Bring me a system worth understanding.