Approach

Build, buy, and the leash on the AI

Three opinions that decided how the systems on this site were built. They are not universal laws. They are what I would defend in a design review.

Build is a last resort that I reach for more than most

The default should be to buy. Vendors have spent years on problems you have spent an afternoon on, and most internal tools are a maintenance liability wearing a demo's clothes. I believe that, and I still build more than most people — because the test is not "can I build this," it is "is the thing I need actually for sale, at a price the company will keep paying, without bending our model to fit the tool's."

Five times that test failed and the answer was to build: node-level Kubernetes posture nobody priced sanely; cross-cloud IAM reachability the affordable tools simply did not model; a finding model that had to match how we actually classified risk rather than how a product wished we did; alert enrichment where the vendor option triaged generically while the work needed our context and a human in the thread; and privileged-access management as a Slack-native bounded-trust workflow rather than a six-figure portal nobody opens. In each case "buy" meant paying a premium to still not have the thing. That is when building is the conservative choice, not the indulgent one.

Cost is a design input, not a line item you discover later

A security tool that cannot survive a budget review is not a security tool — it is a future gap with a dashboard. So price is something I design against from the first sketch, the same way I design against latency or blast radius.

In practice that means ephemeral compute instead of standing services, interruptible capacity with a run that resumes cleanly, and persistence chosen for durability and price rather than habit. IAMGuru runs for roughly eight dollars a month not because it is small but because the number is the point: at that price nobody ever asks whether the analysis is worth keeping on, and the analysis is what matters. Cheap infrastructure is how you protect expensive thinking.

The AI is an assistant with its hands tied, and that is the feature

AI is genuinely a force multiplier in security work — triage, enrichment, the first pass over a noisy queue. I use it for exactly that and no further. The agents in Pentagon and the alert pipeline in Watchman run with deterministic settings for anything that classifies, a scoped read and write surface, no destructive actions, logged inputs and outputs, and a human on every disputed call.

This is deliberately less autonomous than the demos, and the restraint is the engineering. An agent that can act on production without review is not an efficiency; it is an incident waiting for the right prompt, in a domain where the adversary writes the prompts. The useful question is never "how autonomous can this be." It is "what is the worst thing this can do before a human sees it," and then making that answer small. Bounded AI is not AI held back. It is AI made shippable in a place where being wrong is expensive.

The common thread is ownership: of the problem, the model, the running cost, and the failure modes. Tools come and go. Owning why the thing exists and what happens when it breaks is the part that does not transfer to a vendor — so that is the part worth doing well.