Your SOC Runs at Machine Speed. Your Security Architecture Doesn't.

The security industry's answer to machine-speed attacks lives mostly in the SOC. In 2026, AI agents triage alerts, investigate incidents and recommend containment at machine speed. The design those systems run on is still reviewed at human speed, when it is reviewed at all, and the threat model written at launch describes a system that has changed many times since.

In 2015 Robert M. Lee, then a SANS instructor and now the CEO of Dragos, published a paper that shows why that is the wrong order. The Sliding Scale of Cyber Security ranks security work by how much protection each dollar buys, and security architecture comes first.

The Sliding Scale of Cyber Security

The scale groups security work into five categories, laid out left to right: Architecture, Passive Defense, Active Defense, Intelligence and Offense. The further left a category sits, the more security each dollar buys, and the more it makes everything to its right cheaper and more effective. So the advice is to invest from the left first.

Architecture is how a system is designed, built and kept up. Passive Defense is the tooling you add on top that protects without someone watching it: firewalls, endpoint agents, email filtering. Active Defense is analysts (hunters, incident responders) watching for and responding to adversaries inside the network. Intelligence is analysts collecting data about adversaries and turning it into assessments. Offense is legal countermeasures against an adversary, which civilian organisations cannot currently take within the law.

The detail most summaries drop is in the first category. Architecture is defined as "the planning, establishing, and upkeep of systems with security in mind." Upkeep is in the definition. A threat model written at launch and never revisited covers the planning and the establishing, and skips the upkeep, which is the part that keeps the design true as the system changes.

The agentic SOC is faster tooling for the analysts doing Active Defense. Hold on to the word upkeep, because the rest of this post is about it.

What I saw in assurance and architecture

Before I moved into security architecture, I ran assurance teams, and one pattern held. When we struggled to get documentation for a system, or found it had no architecture and no threat model, the penetration test almost always came back with major findings. The missing documents were a symptom. Nobody had examined the design, so the testers were the first people to find its flaws.

As a security architect, my job was to get security into a project before anything was built. That meant setting up architecture review, writing secure-by-design standards, and getting a seat at project inception, so the team understood its security requirements and planned for them from the first week instead of meeting them at go-live.

Every one of those processes met friction. Project teams had a delivery date, and security review looked like something that would move it. The friction was worst with threat modeling, and almost always for the same reason: it took too long. A proper threat model meant getting the right people in a room, drawing the system, walking every element and every data flow, and writing it all up. That is days of an architect's time per system, and the release date did not move to make room for it.

Industry surveys say the same thing. In Security Compass's 2023 survey (Security Compass sells threat modeling software), 53% of respondents said threat modeling delays their releases by several days. An earlier Security Compass survey found that fewer than one organisation in ten threat models 90% or more of its applications.

So the business made a reasonable call. When speed decided whether a product was viable, the threat model was skipped, cut down to a checklist, or done once at the start.

That call does not survive the AI era. The first to find a design flaw used to be a tester on your side. Now it is more likely to be an attacker. Attackers now have the same models defenders do, and they use them to read code, find flaws and move through a network faster than any team can respond. CrowdStrike's 2026 Global Threat Report puts average eCrime breakout time at 29 minutes, with the fastest observed at 27 seconds. A design flaw nobody modeled used to wait for a skilled attacker to find it. Now it waits for a model to find it, and at 27 seconds the only control that acts in time is the one designed in before go-live.

A threat model done once goes out of date. It describes the system as it was designed in month one, and the product then changes every sprint: a new integration, a new data type, an auth flow rewritten, a service split in two. Nobody reopens the model, because reopening it costs as much as writing it did. Within a year the organisation holds a signed threat model of a system that no longer exists. The architecture was established and never kept up. In my experience, upkeep is the part of security architecture that rarely gets its own budget.

Where the machine-speed money went

No human-staffed queue answers in 27 seconds, so SOC analysts are getting their own agents. Torq raised $140 million at a $1.2 billion valuation in January for its AI SOC platform. Exaforce has raised $200 million in total.

That work is necessary, and I have no quarrel with it. Attackers moved to machine speed, and detection and response had to follow.

Design went the other way. Developers in Sonar's 2026 survey say AI wrote 42% of the code they commit. Systems change faster, and design review was already the step teams skipped when they were moving at human speed.

Why the SOC got machine speed first

It is tempting to read this as the industry ignoring architecture. I think the real reason is less flattering to architecture and more useful: it is the harder problem.

Detection is more deterministic than design, and it has a fast, checkable feedback loop. Most alerts are settled as malicious or benign within hours, and each settled answer is a label a model can learn from. The labels are imperfect, but triage has a right answer, so AI can be graded on it.

Architecture has no right answer at the moment the decision is made. The architect is reasoning about an attack that has not happened, against business intent that mostly lives in people's heads, trading security against cost, latency and delivery dates. Whether the decision was right may not be known for years, and often it is never known, because the attack a design prevented leaves no log. That work needs careful planning and human ingenuity. Catalogues such as CAPEC and MITRE ATT&CK give a machine enough to draft candidate threats. No dataset records whether a design decision was right for a given business, so there is nothing to grade that decision against.

So the judgement stays human. The opportunity is to stop spending it on the parts of the work that never needed it.

A stale architecture makes the SOC's job harder

For a CISO deciding where next year's budget goes, the paper is blunt about the cost of skipping upkeep: an organisation with "a poorly maintained Architecture and Passive Defenses would find less value out of Active Defenses." A network that is not segmented and patched "is wrought with more issues than the defenders can reasonably handle," and the real threats are "lost in the noise."

An agentic SOC on a stale design inherits both problems. It triages more noise, and it rates severity against asset and data flow context that no longer matches the system. A service that trusts its caller because of where it sits on the network looks the same to the SOC as one that checks, until the day it matters. We covered what the same gap does to AI agents in Your AI Agents Will Inherit Every Gap You Haven't Closed.

Machine speed in the SOC buys the most when the architecture under it is kept up at a matching pace.

What threat modeling at machine speed means

Threat modeling at machine speed means the mechanical work of a threat model runs as fast as the design changes. A machine drafts the diagram, lists the elements, proposes threats and candidate controls, and flags when an approved design is edited. People still decide where the trust boundaries sit, which threats matter, which risks to accept, and who signs off.

Break a threat model down into the work it is made of and most of it is mechanical: drawing the diagram, listing its elements, walking STRIDE or an attack library against each one, mapping candidate controls, writing it up. That is where the days went. Most of it can be drafted by a machine at the speed the design changes, and checking a draft takes far less of an architect's time than writing one.

The workshop also gave the team a shared picture of the system. Keep that by walking the delivery team through the draft instead of building it with them from a blank whiteboard. We have written up the async version of that process and a single afternoon of it end to end.

For an architect, that split lets you say yes to a delivery team the same week, and lets one architect cover far more systems than a calendar of workshops allowed.

The fifth row is where upkeep gets cheaper. Once someone updates the diagram, the approval reopens on its own and the change has to be classified, so nobody has to remember to look. Someone still has to put the change on the diagram, so agree the triggers that require it: a new external integration, a new class of data, a change to authentication.

Where Alvor sits on the scale

We built Alvor, a security architecture management and compliance platform, around the left of the scale, because that is where the return is highest. Here is where each module helps.

Most of the platform sits in Architecture on purpose. In Secure by Design, each system or change is a project. Its architecture is drawn on a canvas, and the shapes on that canvas become the threat model's elements. Every control mapped to a threat lands in the project's build list, marked as threat-driven, with an implementation status and its evidence. Business, Technical, Architect and Assurance each sign off by name, with a written decision, and an "approved with conditions" sign-off raises a linked risk automatically.

Upkeep is built into the same record. Editing an approved diagram sends it back for re-approval. Once a project is past design, every new diagram version and every control added or removed has to be classified minor or major. A major change sends the project back to design review and resets the architect's sign-off, and the reason is kept in its change history.

The AI Assistant does the drafting, with the model you bring. The Design Studio draws on the canvas, and a diagram counts only once an architect approves the saved version. The Threat Studio proposes threats and control mappings, and none of them reach the record until a person approves them.

What to measure next quarter

If you run a security program, two numbers will tell you whether your architecture is being kept up or only established.

The first is coverage: of the systems in scope, the share whose design was approved after their most recent major change. Use your change records as the test, or the system owner's attestation within the last twelve months. A threat model dated before the last major change does not count.

The second is speed: the time from a design review request to a signed decision. If that number is longer than a sprint, delivery teams will keep routing around the review, and they will be acting reasonably when they do.

Give each number an owner, report both every quarter, and fund what moves them before the next round of SOC tooling.