The Practitioner
The work here is by one practitioner with a solid background in cyber security, though what is catalogued sits mostly to one side of that. Nearly everything below is automation at its core: some system watching something else, deciding what to do about it, and doing it, with a language model somewhere in the loop. Logging and reasoning about what the last step meant and what the next one should be with Python for the substrate, occasional N8N as connective tissue, sometimes local models via harnesses like Hermes or OpenClaw for anything that needs to think with branching logic.
None of it runs against a rented API (but some were created with one), and none of it is a chatbot. The interest sits in what folds up neatly when a language model stops being a chatbox and starts being a component.
The seams between agentic systems and defensive security are widening quickly, and the disciplines on either side are not yet in the habit of talking to one another. The projects catalogued here are not that work directly. They are what holds my interest while figuring out how the two fit together.
Force multipliers do not replace the operator.
They raise the price of not being one.
The Fourth Industrial Revolution, Local or Cloud?
Whether this moment amounts to a fourth industrial revolution or something less structural, the tool choice made now will look the same either way. One rents access to intelligence by the token, against silicon somewhere else, running a model whose weights the renter has never seen and cannot inspect. The other approach downloads the model, runs it against a GPU in the same room as the work, and treats the weights as a file on a disk that will still work when the provider changes its mind or its terms.
Three things this changes are worth naming plainly.
Privacy first. Nothing typed at a local model leaves the room. No telemetry, no context window shipped to someone else's log server, no clause in a terms of service reserving the right to train on what was sent. For work that involves anything sensitive like client data, internal infrastructure, half-formed ideas worth keeping, this is not a preference. It is a precondition.
Cost of iteration, second. The method used here is a loop: generate > read > tweak > generate again, until the output matches the intent. On rented intelligence, every turn of that loop has a price attached. When using owned intelligence, the marginal cost is electricity. Workflows that would be uneconomic against a per-token meter become trivial when the meter is off, and most of the interesting work lives in loops that would have been uneconomic.
Stability, third. The model on disk today is the model on disk next month. Same system prompt, same temperature, same context length. The one behind an API is whatever the provider has decided it should be today, adjusted at will and often silently. Capacity gets ramped up around a competitor's release and quietly pulled back when the infrastructure creaks. The meter reads the same either way. Owned weights are boring in the way infrastructure is supposed to be boring.
Most of what is on this site was built against local models for these reasons.