Threat Modeling and Brutalist Security Practices

Security Brutalism starts with one premise. Breaches are inevitable. The work focuses on making intrusion harder and more expensive, and on building an organization that recovers when it happens.

Threat modeling done the brutalist way is a discipline of realism, centered around how things actually break.

Start with what actually hurts

Name the real things: the data, identities, processes, and dependencies the business depends on. For each one, identify what actually hurts if it breaks: data loss, loss of control, operational disruption, irreversible action. Things that don't matter when they break can be left out of the model. A clear answer to what causes material damage when something is exfiltrated, altered, or destroyed is the baseline for doing this work seriously.

Map the path

In this case, sequences matter more than individual weaknesses. The brutalist version traces how something small becomes something significant: the steps an attacker, or a misbehaving AI agent, would take to move from low impact to high impact, and the pivots between systems, identities, and data along the way. Most real risk lives in these chains.

Trace susceptibility

Identify where influence can happen, which inputs are trusted by default, which integrations expand exposure, and where a person or an agent can be nudged into the wrong action. Assume inputs get manipulated and that behavior drifts over time. This covers insiders, third parties, and the assumptions an architecture quietly relies on.

Define the damage

Specify what happens if the path succeeds. What an attacker can move, access, or persist in. What permissions exist and what they allow without friction. This defines the blast radius, the distance the damage travels once something goes wrong.

Measure recovery time

Once a path triggers, track how fast it gets noticed, how fast it gets stopped, and how fast systems return to a known good state. Detection paired with response and speed is what actually reduces impact and disruption. Untested assumptions tend to surface here: backups nobody has restored from, logs nobody watches in time, access controls quietly bypassed by exceptions.

Build controls that break the path

Mitigation is mechanical work. Each serious path needs a counterforce that blocks, constrains, or contains it. Limiting what can be reached and done in a single step, scoping permissions tightly, breaking high impact workflows into steps that require checks, building in the ability to interrupt actions in real time, and designing rollback in from the start all reduce what a successful path can achieve. A mitigation should answer what stops or limits an attacker on a given path, with a concrete mechanism behind the answer.

Humans and AI agents count as part of the system. Modeling how they can be influenced and how they might fail, and applying least privilege, separation of duties, behavior monitoring, and the ability to intervene quickly, treats them with the same rigor as any high risk operator.

Harden a small set of controls

Strength here comes from compression and reduction. A small number of deeply understood controls outperforms a sprawling toolset nobody fully operates. Controls that collapse multiple risks at once carry the most weight: identity protections that shrink the attack surface broadly, network boundaries that enforce trust, backups that resist alteration, logging built for reconstruction. Each control earns its place by the amount of real risk it removes. Complexity adds attack surface. Minimalism functions as a defensive strategy.

Test until it's evidence

Untested controls remain assumptions. Auditing in this approach means breaking your own systems and forcing controls to prove themselves against the techniques they're meant to stop. Checking whether accounts actually expire, whether segmentation actually blocks lateral movement, whether detections fire under real abuse, and whether backups restore while systems are under pressure turns assumptions into evidence. Evidence is what resilience gets built from.

Keep the model alive

Systems change, and the model needs to track those changes. Revisiting it when integrations get added, permissions expand, or workflows shift keeps it accurate. Keeping the process simple enough to use regularly matters more than producing a detailed document, since a heavy process tends to fall behind reality.

A walk-through

A company deploys an AI agent that reads email, pulls data from internal systems, and updates support tickets and billing records to speed up operations. The outcomes that are important here are exposure of customer data and unauthorized billing changes.

The path: an attacker sends an email shaped like a normal customer request, carrying a prompt injection. The agent reads it, pulls extra data for context, then updates a billing record. Each individual step looks ordinary. Chained together, the sequence produces data exposure and unauthorized action.

Susceptibility: the agent trusts inbound email, touches multiple systems, and acts on instructions without strong validation. Damage: it can read customer records, modify billing, and trigger downstream workflows, producing a wide blast radius from one influenced action. Recovery: without real time log monitoring and easy traceability, the issue can run for hours before anyone notices, stretching recovery out further.

Controls that change this outcome include keeping sensitive data access and billing changes in separate flows, requiring a second check for financial actions, scoping access to the minimum needed for a task, treating email as untrusted input, monitoring for behavior outside the agent's normal pattern, and making billing changes reversible with a clear audit trail. Running the same attack against this version of the system produces a smaller blast radius and a recovery measured in minutes.

What this adds up to

Threat modeling built this way functions as survivability engineering. Identifying what matters, mapping how it breaks, blocking the paths that count, hardening a small set of controls carrying the greatest load, testing them until they earn trust, and building redundancy so failure has more than one possible outcome, together form a system that keeps functioning after a breach occurs.