REF-008 // Insights

Insights

Writing on GRC automation, cloud-native security, and building programs that actually work.

  • AI governance is just governance

    A new market has formed around AI governance. Standards bodies are convening. Tooling categories are being invented. Consulting practices are positioning themselves as specialists in what agents require that other software did not. The implicit claim across all of it: deploying AI agents introduces governance requirements that didn’t exist before.

    It doesn’t.

    The organization that deployed an agent and discovered it had no audit trail, overly broad permissions, and no defined blast radius did not discover new problems. It discovered old ones, running at a new speed. Those problems existed before the agent arrived. The agent is why they surfaced.

  • Endpoint security is mostly a waste of money

    The EDR/XDR market is worth north of $15B and growing. It is the default answer to “what security tools do you have?” at board level, and the largest line item in most security budgets. The implicit assumption underneath that spend: the endpoint is where you defend.

    That assumption is worth examining.

  • Policy as code, in practice

    Article #4 argued that structural friction beats prohibition. Policy documents don’t run at deploy time. The environment itself has to enforce the right path. That argument is a case for a way of thinking. This piece is the answer to the next question: what does it actually look like to build an environment with an opinion?

    Three failure modes from that article. Three mechanisms that address them. Not a product survey. An explanation of how the philosophy gets built.

  • Everything as code: the complete picture

    Most security programs are accurate descriptions of a program nobody built. The policies are right. The controls are mapped. The SOC 2 is clean. The environment does something else.

  • The automation imperative

    A control that requires a human to initiate, remember, and execute correctly is not the same thing as a control that runs. The gap between those two things is where most security programs quietly live, and where most incidents that aren’t attacks begin.

  • Make the wrong thing hard

    Most security policies fail not because people ignore them, but because the environment never enforced them. If anyone can deploy anything, configure anything, pull in anything, you cannot know what you own, you cannot assess what threatens it, and you cannot measure whether your controls are working. Governance requires a stable environment. A stable environment requires constraints that the environment itself enforces.

  • Your risk register is lying to you

    Most risk registers are audit artifacts — built to satisfy an examiner, formatted to pass a review, and forgotten the moment the auditor leaves. The deeper problem is that even when the intent is genuine, the methodology most organizations use structurally cannot produce useful output. High, medium, and low are not risk management. They are the appearance of it.

  • Threat modeling isn't a security thing, it's an engineering thing

    Governance tells you what you own and who’s responsible. Threat modeling tells you what threatens it. Done right, it drives resource allocation, shapes controls, and hands a usable input to risk assessment. Done as an audit exercise, it produces documentation nobody uses.

  • Governance first, or nothing works

    A security program is a control structure. Before it is a set of tools, a team, or a framework checklist — it is a structure that determines who owns what, who decides what, and what gets measured. Get it right and the rest of the program has somewhere to stand. Get it wrong and you are stacking capabilities on nothing.

  • Your policies should be on Git

    Treating policy documents like code isn’t just a clever idea — it solves real problems that SharePoint, Confluence, and annual review cycles never will.

  • Why OSCAL changes everything about compliance automation

    Most compliance programs fail not because of bad intent but because the tooling is fundamentally mismatched to the problem. OSCAL is the first serious attempt to fix that at the format level.