A Threat Model Developers Will Actually Use

// appsec // threat modeling // kill the 40-page pdf

Somewhere on a shared drive at almost every company is a folder of threat models. Forty pages each. Beautiful diagrams. A STRIDE matrix that took someone two days to fill in. Every one of them was opened exactly twice. Once when it was written, once when an auditor asked for evidence that threat modeling happens. Between those two opens, the system it described shipped, changed shape four times, and grew an entire new attack surface the document never mentioned.

That folder is a graveyard. The headstones are very well formatted. And it is the single biggest reason developers think threat modeling is security theatre, because the version they were shown is theatre. A document produced for an audience of one auditor, read by no engineer, describing a system that no longer exists.

I want to talk about the other kind. The threat model a developer opens on purpose, mid-change, because it helps them ship the right thing. It is smaller than you think, it lives somewhere you might not expect, and the format barely matters.

Why threat models die

Three causes of death, and they are almost always the same three.

It is too big. A forty-page model of an entire platform is obsolete the day it is signed. Systems do not change at platform granularity. They change one pull request at a time. A model scoped to the whole system can never keep up with a system that changes in small pieces, so it rots, and a rotting model is worse than none because it lies with authority.

It lives in the wrong place. If the threat model is a Confluence page or a Visio file in a drive, it is outside the developer's loop. Developers live in the repo, the PR, the IDE, the ticket. Anything outside that loop is a context switch, and context switches under deadline lose every time. The model is not lazy. It is just geographically inconvenient.

It produces a document, not a decision. This is the deep one. Most threat models output a description of risks. A developer cannot act on a description. They can act on a decision: add auth to this endpoint, do not log this field, this service must not be reachable from the internet. If your threat model ends in prose instead of a short list of concrete changes, you produced a report, and reports go in the graveyard.

the test

A threat model is useful if, and only if, a developer can read it in five minutes and come away with a small list of things they will now build differently. Everything that does not serve that outcome is decoration.

What "usable" actually looks like

Flip the three causes of death and you get the design spec for free.

Scoped to a change, not a system. You do not threat model "the payments platform." You threat model "the new endpoint that lets a user move money between their own pots." Small enough to finish in one sitting. Small enough to stay true, because it is attached to a single change that either shipped or did not.

Lives where the work lives. A markdown file in the repo, next to the code. A section in the design doc that already exists for any non-trivial change. A comment thread on the PR. The model should be reachable without leaving the place the developer already is. If they have to open a second tab, you have already lost most of them.

Ends in a checklist of decisions. The output is not "here are the STRIDE categories we considered." The output is a handful of concrete, testable statements about what the code will now do. Those statements become acceptance criteria. They become test cases. They become review comments. They are load-bearing, not archival.

The method, kept deliberately small

You can run a genuinely useful threat model on a change with four questions. No matrix, no tooling, no two-day workshop. Sit with the one or two engineers who own the change and ask, in order:

1. What are we building, in one diagram? Not a formal DFD. A napkin sketch of the boxes, the arrows between them, and where the data goes. The only rule: draw the trust boundaries. Where does data cross from something you control to something you do not, or from less-trusted to more-trusted? Every interesting bug lives on a boundary line.
2. What would an attacker want here, and what are they allowed to touch? Money, personal data, a privilege, a foothold. And critically, who is the attacker? An anonymous internet user, a logged-in customer poking at another customer's data, a compromised internal service. The threat model for "external user" and "malicious authenticated user" are different models and most teams only ever do the first.
3. How could each boundary crossing go wrong? Walk every arrow that crosses a trust boundary. For each one: can it be spoofed, tampered with, abused to read something it should not, abused to do something it should not. This is STRIDE if you want a name for it, but you do not need the acronym in the room. You need the engineers looking at their own arrows and getting uncomfortable.
4. What are we going to do about it? This is the only question whose answer you keep. Each real risk becomes one of three things: a change we make now, a risk we knowingly accept and write down, or a thing we explicitly decide is out of scope. Three buckets. No prose.

That is the whole method. Thirty to sixty minutes for a normal change. The artifact it produces is the answers to question four, and nothing else needs to survive.

What the artifact looks like

Here is the entire output for a real-shaped example, the money-between-pots endpoint, as a markdown block that lives in the PR:

## Threat model: internal pot transfer (PR #2241)

Boundary crossings:
- client -> transfer API  (untrusted -> trusted)
- transfer API -> ledger  (trusted -> trusted, money moves here)

Decisions:
[x] enforce that both pots belong to the authenticated user
      (authz, not just authn) -> test: transfer to a pot you
      do not own returns 403
[x] make the transfer idempotent on a client key
      -> replaying the same request moves money once, not twice
[x] do not log the amount or pot IDs at info level (PII + abuse)
[ ] ACCEPTED RISK: no per-user rate limit at launch.
      Owner: payments. Revisit before raising transfer caps.
OUT OF SCOPE: cross-user transfers (not built in this change)

That is it. A developer reads it in two minutes. Three of those lines are now test cases. One is a written, owned risk acceptance instead of a thing nobody decided. One is an explicit scope boundary so the next person does not assume it was missed. No auditor will be thrilled by its length. Every engineer who touches this code will actually use it.

Make it a habit, not an event

The reason the four-question version wins long term is not that it is better security. A two-day workshop finds more, in theory. The four-question version wins because it is cheap enough to run every time, and a cheap thing done every time beats a thorough thing done never.

Threat modeling as an event, a quarterly ceremony with a facilitator and a meeting room, models the system at one frozen moment and then watches reality drift away from it. Threat modeling as a habit, a thirty-minute section in the design doc for any change that touches a trust boundary, moves with the system because it is part of how the system gets built. The first is an artifact. The second is a reflex. You want the reflex.

The way you get the reflex is by making it small enough that nobody can argue it is not worth the time, and by putting it where they already work so it costs them no context switch. Drop a four-question template into the repo as THREAT_MODEL.md next to the design-doc template. Add one line to the PR checklist: does this change cross a trust boundary, and if so, link the model. That is the entire rollout. No platform purchase, no workshop calendar.

field note

The best threat models I see in-house are three paragraphs of markdown in a PR, written by the developer, with two comments from me. The worst are forty-page PDFs written by security in isolation. The difference in security value is not subtle, and it runs the opposite way to the page count.

Where the heavy version still earns its place

To be fair to the forty-page model: there is a place for depth. A new platform, a major architectural decision, a system that moves serious money or holds serious data deserves a real, deep, deliberate threat model with the full method and the diagrams and the time. That is a handful of times a year, on the things that genuinely warrant it.

The mistake is using that heavyweight format for everything, because then you either do it rarely, on the big things only, and leave every normal change unmodelled, or you try to do it on everything and burn out in a month. Match the weight of the model to the weight of the change. Big decision, deep model, run it like the serious thing it is. Normal change crossing a boundary, four questions and a markdown block. Trivial change touching nothing sensitive, no model at all, and be honest that this is most changes.

Calibrating that is the actual skill. Not filling in the matrix. Knowing which changes deserve which depth, and refusing to spend a forty-page budget on a four-question problem. Do that, and threat modeling stops being the thing developers dread and the folder nobody opens. It becomes a thirty-minute reflex that quietly catches the bugs that would otherwise have been a pentest finding six weeks too late.

---

// Elusive Thoughts // less paper, more decisions // securityhorror.blogspot.com

Shift-Left Is Org Design Wearing a Vendor Badge

// appsec // culture // the part nobody sells you

Every shift-left pitch I have sat through follows the same arc. A scanner plugs into CI. A dashboard turns red. Developers fix things earlier. Risk slides down and to the left like a stock chart nobody questions. Buy the tool, get the outcome. It is clean, it ships quarterly, and it is mostly a lie.

Not because the tools are bad. Some of them are excellent. It is a lie because the slide deck quietly swaps the cause and the effect. Shift-left is not a thing you install. It is a thing your organisation already is, or already is not. The tool is the last 10 percent. The other 90 percent is who owns what, who gets paged, who can say no, and how fast a developer finds out they made a mistake. That is org design, and you cannot buy it on a per-seat licence.

What the word actually means once you strip the paint

Strip the marketing and shift-left says one thing: move the security decision closer to the moment the decision is made. That moment is not the pull request. It is earlier. It is a developer choosing a library, sketching a data flow on a whiteboard, deciding whether a service needs to talk to another service at all. The bug you want to kill was born in that choice, not in the diff.

So the real question shift-left asks is not where do we put the scanner. It is who is in the room when the choice gets made, and do they have what they need to choose well. A scanner in CI is downstream of every interesting answer to that question. It catches what survived the choice. Useful, but it is a net under the tightrope, not the tightrope.

Why tooling-first cargo-cults itself to death

Here is the failure mode I have watched play out more than once, from both chairs, consultant and in-house.

Security buys a scanner. Security wires it into the pipeline. The first full run produces 4,000 findings. Nobody triaged the baseline, so 3,600 of them are noise, dead code, test fixtures, dependencies that are technically vulnerable in a path that does not exist in production. The pipeline goes red. Developers cannot ship. Developers do the only rational thing a human under a deadline does: they find the bypass. A skip label. A nightly job instead of a blocking gate. A Slack message to the one person with admin who will wave it through.

Now you have spent budget to teach your entire engineering org that the security gate is a thing you route around. That lesson is durable. It outlives the tool. The next tool you bring in inherits the reputation of the last one, and you wonder why adoption is a fight every single time.

the pattern

A tool dropped into an org that is not built to absorb it does not raise the security baseline. It raises the noise floor and trains people to ignore you. The tool worked perfectly. The org ate it.

None of that is a tooling problem. You can swap the vendor and reproduce the exact same wreck. It is an ownership problem, an incentive problem, and a feedback-latency problem wearing a tooling costume.

The primitives that actually move security left

If shift-left is org design, then these are the levers. None of them appear in a product comparison grid.

1. Ownership that survives a reorg

A finding with no owner is not a finding, it is a rumour. The single highest-leverage thing I have done in-house is not picking a scanner. It is making sure every service has a named team that owns its security posture, and that the name is attached to something the team already cares about, not a spreadsheet security maintains in the dark.

If the security backlog lives in a tool only the security team opens, it is dead. Findings have to land in the same backlog where the team plans its sprint, in the same tracker, with the same labels, ranked against the same features. The moment a vuln has to compete with a feature on equal footing in front of the same engineering manager, you have moved security left in the only way that holds. You moved it into the place where prioritisation actually happens.

2. Incentives pointed at the outcome you want

People do what they are measured on. If a team is measured purely on delivery velocity, security is friction, and you are the friction. No amount of lunch-and-learns fixes a misaligned incentive. You can win every developer's heart in the room and lose every one of them the second the quarter clock starts.

The fix is not to make security a KPI nobody believes. It is to make the secure path the fast path. If reaching for the hardened, paved-road service template is genuinely the quickest way to ship, security stops being a tax and becomes the default. That is an engineering-platform investment, not a security-tool purchase. It is built by the platform team, funded by leadership, and your job is to make the case for it in language a delivery lead and a CFO both accept.

3. Decision rights, written down

Who can accept a risk? Who can override a gate? On what authority? If the answer is whoever shouts loudest before the release, you do not have a security program, you have a negotiation that restarts every Friday. Real shift-left needs the boring governance most teams skip: a written risk-acceptance path, an owner for it, and a clear line between what a team can wave through themselves and what has to come up the chain. Boring. Load-bearing.

4. Feedback latency measured in minutes, not weeks

The entire mechanical value of shift-left is shortening the distance between mistake and correction. A pentest that lands findings six weeks after the code shipped has shifted nothing. A SAST rule that flags the dangerous pattern in the IDE, while the developer still has the whole mental model loaded, has shifted everything. Same class of bug. The only variable that changed was latency, and latency is the whole game.

This is the one place tooling genuinely earns its keep, and notice it only works because the org already did the other three. Fast feedback into a team with no ownership and no incentive is just a faster way to get ignored.

So where does the tool go

Last. The tool goes last. Once a service has a named owner, the secure path is the fast path, risk acceptance is a written route instead of a hallway favour, and feedback is fast and tuned, then you bolt on the scanner and it lands on prepared ground. The findings have somewhere to go. Somebody owns them. The baseline was triaged before the gate ever blocked anyone. Adoption is not a fight because you are not asking people to absorb chaos, you are handing them a sharper version of a process they already run.

Do it in the other order and the tool is a liability. I would rather inherit an org with strong ownership and a mediocre scanner than a perfect scanner bolted to an org that routes around it. The first one I can improve in a quarter. The second one taught itself to ignore me, and unlearning that takes years.

field note

The most effective security control I have shipped this year was not a tool. It was getting security findings into the same Jira board, with the same priority scale, as feature work. Zero new software. It changed more behaviour than any scanner I have ever deployed.

What I would actually do on day one

If you handed me a fresh AppSec mandate and a budget, here is the order, and the tool is deliberately not at the top.

• Map ownership first. Every production service to a named team. The gaps you find here are your real risk register, and they cost nothing to find.
• Find the paved road, or build the case for one. What is the fastest way to ship a new service today, and is it secure by default? If the fast path and the safe path are different paths, that is the problem. Fix the road before you fine people for going off it.
• Write down the risk-acceptance path. One page. Who decides, on what authority, recorded where. Kill the Friday negotiation.
• Only then, pick the tool, tune the baseline before it blocks a single build, and wire it into the feedback loop that is closest to the developer you can reach.

Notice that three of those four cost no licence money and do not appear in any vendor demo. That is the tell. Shift-left was always org design. The vendors just found a way to sell you the badge without the work, and the badge does not do the work.

Buy the tool if you want. Buy a good one. But buy it knowing it is the last 10 percent, and that if you skip the 90 percent underneath it, the tool will work flawlessly while your program quietly fails around it.

---

// Elusive Thoughts // written from the in-house chair, not the consultant one // securityhorror.blogspot.com

Nobody Breaks In Anymore

// elusive thoughts // appsec // threat intel // 2026

Read enough 2026 breach reports and something gets embarrassing. The intrusion you picture, the hoodie, the zero-day, the frantic keyboard work, almost never happened. The attacker walked in. Sometimes you left the door open. Sometimes someone sold them the key. Sometimes you imported them yourself and ran their code on your build server with a smile.

Three roads, one destination: your environment. None of them look like hacking. All of them work, and the data from the last six months says they work better than ever.

Road one: the door you left open

Cloud misconfiguration is the breach cause that refuses to die. Not nation-state magic. Not a novel exploit chain. A storage bucket set to public. An IAM role with *:* because someone needed it to ship on a Friday. A security group open to 0.0.0.0/0 that was "temporary" in 2024.

~95%of cloud security failures trace to human error / misconfig

~70%of cloud attack vectors lead with identity or credential compromise

277daverage time to detect a cloud breach

The number that should keep you up is the last one. Most of a calendar year, attacker resident in your cloud, undetected. That is not a detection-tooling problem. That is a visibility-and-ownership problem dressed up as one.

And misconfig never stays a single mistake. It chains. A leaked CI/CD token lands on an over-privileged role. That role reads a public store. The store holds another credential. That credential modifies production. Every link in that chain is a config nobody reviewed, because reviewing configs is boring and shipping features is not. Roughly 45% of breaches now touch the cloud, and the average public-cloud incident clears five million dollars. Boring is expensive.

Road two: the key someone sold

You do not need an exploit if you can log in. In 2026 that is the default. The clearest signal in the whole threat landscape: the majority of intrusions involve no malware at the entry point at all.

79%of intrusions are malware-free at initial access (stolen creds, not exploits)

54%of ransomware victims appeared in infostealer logs BEFORE the attack

~30%of incidents start with identity abuse, the top single vector

This is the Initial Access Broker economy, and it has matured into a clean professional supply chain. Infostealer malware harvests credentials and session cookies from some unlucky endpoint. Those logs get parsed, sorted, and sold. A broker packages "VPN access to a UK financial services firm, domain admin adjacent" and lists it. A ransomware affiliate buys it for four figures and is inside before your SOC has finished its morning standup.

The brokers have gone upmarket. Through 2025 and into 2026, researchers tracked IABs shifting toward high-value targets and premium pricing, with elite players retreating from burned public boards like the rebooted BreachForums toward closed, Russian-language platforms after names like IntelBroker got arrested and unmasked. The market did not collapse under law-enforcement pressure. It professionalised and went quieter.

The operational takeaway is brutal and simple. By the time ransomware detonates, the breach is old news. The encryption is the invoice, not the intrusion. Someone bought your access weeks earlier, sat inside, staged exfiltration, and only then pulled the trigger.

Road three: the code you imported

The third road is the one we walk down ourselves, voluntarily, thousands of times a day. Your dependency graph is a trust network you do not monitor and mostly cannot see. npm install is an instruction to download and execute arbitrary code from strangers, and 2026 has been a clinic in what that costs.

The shift started with Shai-Hulud in late 2025: a self-replicating worm that stole npm tokens and GitHub PATs, then used them to automatically republish itself into other packages. That ended the nuisance era. Then the consequences arrived at scale:

• Axios (March 2026): the most popular HTTP client in the ecosystem, 100M+ weekly downloads. A hijacked maintainer account pushed poisoned versions carrying a phantom dependency that dropped a cross-platform RAT on install. Attributed to a North Korean state actor. Live within 39 minutes of a stolen token being used.
• node-ipc (May 2026): three malicious versions published across multiple semver lines at once, deliberately maximising blast radius so anyone pinned to ^9, ^12, or a tilde range pulled an 80KB credential stealer on their next lockfile refresh.
• Miasma / @redhat-cloud-services (June 2026): a Shai-Hulud derivative abusing install-time scripts, compromising a vendor namespace through a hijacked GitHub account.

Notice the pattern. Almost none of these were typosquats you could have avoided by spelling carefully. They were legitimate, trusted, widely-used packages whose publishing identity got stolen. The malicious code arrived through the exact channel you told your build system to trust implicitly. postinstall is remote code execution that you opted into and put in your pipeline.

The throughline

Three roads, one root cause: trust granted without verification. The open cloud role, the stolen credential, the hijacked maintainer token. Same currency, different counter. We spent a decade buying perimeter products while the perimeter quietly redefined itself as "anyone holding a valid token." Identity is the perimeter now. It has been for a while. The breach reports are just catching the rest of us up.

// Opinion: this is good news, if you can stand to hear it

Every one of these is a hygiene failure, not a sophistication failure. Nobody out-galaxy-brained your defences. They used a checkbox, a credential, and an install script. That should be encouraging, because boring problems have boring fixes, and boring fixes are cheap relative to the next platform your vendor wants to sell you.

What actually moves the needle, in priority order:

• Least privilege, enforced, not aspirational. The CI/CD token that can reach prod is the entire kill chain compressed into one line. Scope it down until it hurts.
• Pin and verify dependencies. Lockfiles with integrity hashes. No blind caret ranges on anything that runs install scripts. Disable postinstall by default and allowlist the few that need it.
• Monitor infostealer logs for your own domains. If your credentials are for sale, you want to know before the affiliate does.
• Phishing-resistant MFA everywhere. When 79% of intrusions are malware-free, credentials are the product. Stop shipping the product.
• Default-deny cloud, reviewed IaC, CSPM that blocks instead of alerting into a void nobody reads.

None of this is a new product. It is discipline applied to the three roads attackers actually use. The movie hack is a distraction. The real breach is administrative, and so is the defence.

SOURCES // SentinelOne and StationX cloud + breach statistics (2026) // CrowdStrike 2025 (malware-free intrusions) // Verizon DBIR 2025 (infostealer logs, identity vectors) // Rapid7 threat intelligence, Initial Access Broker pricing shift (2026) // IBM X-Force Threat Intelligence Index 2026 // StepSecurity (node-ipc), Trend Micro and Microsoft (Axios / Sapphire Sleet), Wiz and Palo Alto Unit 42 (Miasma / Shai-Hulud). Figures are cross-source and approximate; treat as direction, not decimals.

#AppSec #CloudSecurity #SupplyChain #ThreatIntel #IAB #npm #DevSecOps

Anthropic, cannot give you anymore access to Mython and Fable, unless you are American military personnel....

root@elusive:~/posts$ cat no-universal-railguard.md

There Is No Universal Railguard, And They Shipped It Anyway

Filed under: agentic AI security // governance // things that were always going to happen

Anthropic told us the truth and we did not listen. Buried in the Fable 5 launch was one of the most honest sentences a frontier lab has ever published about its own safeguards: perfect jailbreak resistance is not currently possible for any model provider. Read that again. Not "we have not finished hardening." Not "edge cases remain." A flat statement that the unbreakable wall does not exist and will not exist on this architecture.

Then they put the model in front of hundreds of millions of people. Then a researcher beat the layer in under two days. Then the US government pulled the plug. None of these three events contradict the others. That is the whole point, and almost nobody is saying it.

The architecture, because the architecture is the story

Fable 5 and Mythos 5 are the same model. The difference is a classifier layer. When a query trips one of the high-risk buckets (cybersecurity, biology, chemistry, model distillation), Fable does not refuse. It silently downgrades the request to the weaker Opus 4.8 and tells you it did so. Mythos is the same model with the cyber classifiers lifted, handed to a small set of trusted defenders.

If you have ever deployed a WAF in front of an application you already understand the entire security posture here. The classifier is not the model's security. It is a request inspector bolted to the front. It reads what you send, scores it, and decides whether the real engine answers or the understudy does. It does not, and cannot, read your intent.

That is why the published bypass techniques are unremarkable to anyone in this field. Unicode and homoglyph substitution to dodge keyword matching. Long-context framing to dilute intent across a conversation so no single turn looks bad. Decomposition-recomposition, where you split a forbidden task into a dozen individually innocent sub-requests and reassemble the answer yourself. These are not exotic. They are the LLM equivalent of encoding a payload to slip past a signature-based filter. WAF evasion, new substrate.

So when the classifier layer falls, the correct reaction is not shock. The correct reaction is "yes, that is what classifier layers do." Anthropic said so themselves. Out loud. In the launch post.

Reading one: this is bad, and the takedown is the system working

Here is the uncomfortable version.

Anthropic has previously described Mythos-class capability as analogous to a cyberweapon that warrants careful oversight. Fine. Then the same company wrapped that capability in a layer it publicly admitted was defeatable in principle, tuned the layer conservatively, and shipped it to the general public at ten dollars per million input tokens. The safety argument rests entirely on three words: "no universal jailbreak." And the operative word in that phrase is yet.

A non-universal jailbreak is a key that opens one door and has to be re-cut for the next. A universal jailbreak is a master key. Anthropic's bet is that they can keep attackers stuck cutting individual keys, log every attempt, and patch faster than anyone can scale an attack. That is a reasonable bet for a monitored, narrow deployment to vetted defenders. It is a far shakier bet for a public model with hundreds of millions of users and a financial incentive sitting on every successful bypass.

In this reading, a government that recalls the model the moment a credible bypass surfaces is not overreacting. It is enforcing the precautionary principle the lab itself claimed to believe in. If your security control has a known expiry date and you sell it as if it does not, the recall is the smoke alarm doing its job. The fact that it is loud does not make it wrong.

Reading two: this is over-amplified, and partly a control play

Now the other version, which is also supported by the facts.

What did the disclosed bypass actually produce? By Anthropic's own account, the government's evidence was verbal, and the technique essentially amounts to asking the model to read a codebase and fix its flaws. That is not a weapon. That is Tuesday for every defender alive. The lurid screenshots, stack overflow exploit code and a meth synthesis pathway, describe capabilities you can already pull from other public frontier models and from a patient afternoon with a search engine. The leaked 120,000 character system prompt is not a compromise. It is the model's refusal logic and house style. It embarrasses, it does not hand over control, and system prompts get extracted from every frontier model by anyone who tries hard enough.

Then look at the plumbing of the takedown. Reporting points to the bypass being found by Amazon, which happens to be Anthropic's largest investor, a board presence, and its cloud host, then escalated to Treasury, then converted into a Commerce directive that pulled a model overnight. The White House framing is that Amodei was offered a fix-or-pull choice and refused. Anthropic's account differs on essentially every material point and says the letter arrived at 5:21pm with no technical specifics at all.

Strip the national-security wrapper and what is left is this: a model deployed to millions got recalled over a narrow, non-universal, verbally-described filter evasion, through a channel that runs straight through a competitor-and-investor. Apply that standard evenly and you do not have a safer industry. You have no new model releases at all, because every model in existence is vulnerable to non-universal jailbreaks by definition. That is not safety policy. That is a kill switch with a flag painted on it.

The AppSec verdict

Both readings are correct. That is the part that should keep you up at night, not either one alone.

The engineering claim is true. There is no universal railguard. Anybody selling you one is selling you a WAF and calling it a vault.

The product claim is where it breaks. "No universal bypass exists yet" is a dependency note, not a safety guarantee, and shipping it to the entire planet as if it were the latter is the actual unsafe act. Not the jailbreak. The framing.

The governance claim is the one that matters most to anyone who builds. A frontier model vanished for every customer, overnight, on the strength of a verbal, undocumented finding routed through an interested party. If your production workflow is coupled to a single closed API, you just watched a live demonstration of your own supply-chain risk. The model did not fail. The endpoint did not get hacked. It simply stopped existing because of a letter you will never read.

So treat "no universal jailbreak" as exactly what it is: the most honest thing the vendor said, and the one you are least allowed to forget. Build for the day the layer falls, because the people who built it already told you it would. Monitor like the control is temporary, because it is. And never put a production dependency somewhere a single letter can switch off at 5:21 on a Friday.

The railguard was never universal. The only surprise is that anyone is surprised.

// EOF  //  Elusive Thoughts  //  securityhorror.blogspot.com

Viruses With Wings and Brains: The Worm You Cannot Patch

// elusive thoughts // malware // ai security

Gary McGraw gave this whole problem the only label it needs. If the old worms were viruses with wings, the next ones are viruses with wings and brains. That is not a marketing line. It is a precise description of what a group of researchers just built on purpose, and of what is almost certainly being built right now by people who will not publish a paper afterwards.

What they actually built

A team spanning the University of Toronto, the Vector Institute, ServiceNow and Cambridge wired up a proof-of-concept agentic worm. The crucial detail is what it does not contain. It does not ship a fixed exploit. A classic worm carries one trick and dies the day you patch that trick. This thing replaces the fixed payload with goal-directed reasoning. It lands on a host, reads the environment, identifies whatever is weak on that specific box, writes an exploit for it on the spot, steals the secrets it finds, and then moves to the next machine and starts the loop again, adapting as it goes.

Our adaptive worm cannot be stopped this way. It uses a recursive reasoning loop to detect and exploit diverse vulnerabilities as it propagates.

Read that twice. The entire muscle memory of vulnerability response, find the bug, ship the patch, contain the spread, assumes the malware is committed to a specific door. This one is not committed to any door. Patch the bug it used on the last host and it simply reasons its way to a different one on the next. The researchers ran it with small free models driving the decision-making, which means the brains are cheap and getting cheaper.

This is not science fiction with a long runway

BeyondTrust's chief security architect put a clock on it: an AI-powered worm in the wild within six months to a year. His read on the target set is the part that should make every engineer reading this uncomfortable, because the target is us.

It is going to target developers and engineers who have broad access, and will pivot through cloud, and many companies will not recover.

We have already seen the warm-up acts. Shai-Hulud squirmed through NPM in September 2025, harvesting developer credentials and secrets to poison new packages. A month later Glassworm rode VS Code extensions to compromise developer machines. Neither of those had the adaptive brain yet. They were the wings arriving before the brains caught up. The brains are catching up.

The bad news about the guardrails

You might hope the foundation models refuse to help build this. They do, sort of, on the surface. Searches with obvious terms like malicious worm get blocked. But the BeyondTrust researcher found trivial workarounds, including a meta-skill script that scrubbed the scary words out of his own prompts before they hit the model. Do not build your threat model on the assumption that model-level refusals will hold. They are a speed bump, not a wall.

There is one genuine piece of good news, and it is physics, not policy. An open-weight model running on a victim machine is loud. Tens of gigabytes resident in VRAM and a machine-learning runtime spinning up on a host that has no business running inference does not fade into the background. Cryptojackers learned to hide in spare cycles. A worm dragging a model around with it is an order of magnitude more obvious. Detection has a real seam to work with here.

What actually helps, and it is not new

The researchers were blunt about their own test conditions. Their worst case was a flat network, and they said plainly that even basic segmentation would have substantially limited the reach. The worm thrived on the things we already know are wrong and keep tolerating anyway. Over-privileged roles. Standing human access to production. Secret sprawl across repositories. Every one of those is a finding you have probably closed as "accepted risk" at some point.

So the defence reads like a list you have heard a hundred times, and that is exactly the point:

• Least privilege, enforced and audited, not aspirational
• Network micro-segmentation so a single foothold cannot reach the whole estate
• Zero-trust style continuous authentication to throttle lateral movement
• Aggressive endpoint and cloud telemetry, wired to auto-remediation that acts on the first signals
• Secrets management that assumes the repo will be read by something hostile

None of that is exciting. None of it will headline a conference. It is the difference between being in the group the researcher thinks will not recover and the group that does. The brains are coming. The wings are already here. The only part of this still fully in your control is whether your network is a flat field or a maze.

#Malware #AIsecurity #SupplyChain #ZeroTrust #AppSec

Reporting: Robert Lemos, Dark Reading, "Adaptive, Agentic AI Worms Loom as Next Enterprise Threat" (Jun 2026). Research cited: University of Toronto et al., "AI Agents Enable Adaptive Computer Worms." Analysis and commentary are my own. Read the original.

"AI as Enabler, Not Replacer" Is True. It Is Also Half the Story.

// elusive thoughts // secops // ai security

Zoom's CISO, Sandra McLeod, gave the reassuring version of the AI question in a recent Dark Reading interview, and I want to be clear up front: she is right. Her view is that AI is an enabler for human security teams, not a replacement. It automates the repetitive grind inside the SOC and it helps build systems that can stand up to AI-powered attacks. As someone who has watched good analysts burn out on tier-one triage, I am not going to argue with any of that. The framing is correct, it is humane, and it should be the default posture for any team standing up agentic tooling.

My problem is not with what she said. My problem is with where most people stop listening.

The enabler half is real, so use it

Point the agents at the toil. Alert triage, enrichment, correlation, the soul-destroying tier-one queue that exists mostly to be cleared rather than understood. That is exactly the work that should be automated, and automating it buys back the one thing your senior people never have enough of, which is attention for the hard problems. A SOC that runs agents on the boring path so humans can think about the interesting path is a stronger SOC. No notes.

AI serves as an enabler, not a replacement, for human security professionals.

The half that never makes the keynote

Here is the part that gets quietly dropped. The exact capability that lifts your defenders is the capability that arms the other side and grows your own attack surface. Every agent you deploy is a new thing with credentials, with access, with the ability to be talked into doing something it should not. The same reasoning engine that triages your alerts can be prompt-injected through a poisoned ticket, jailbroken through a crafted input, or hijacked as a propagation host by the next generation of adaptive malware.

This is not hypothetical hand-waving. There were 2,130 AI-related CVEs disclosed in 2025, up around 35% year on year. Every agent you wire into production with standing credentials and broad scope is another entry on a list that is already growing faster than the staff meant to watch it. The enabler and the liability are the same object. You do not get one without the other.

Holding two true things at once

Maturity in this space is the ability to hold both statements in your head simultaneously. AI is an enabler for security. AI is a fresh attack surface for security. Junior thinking picks one and builds a slide deck around it. The optimists ship agents everywhere and budget nothing for the blast radius. The cynics refuse to touch any of it and quietly fall behind. Both are wrong in the same way, which is that they only looked at one half of the object.

The practical version looks boring, because the practical version always looks boring:

• Deploy agents on toil, but scope their credentials like you would scope a contractor you do not fully trust
• Treat every agent as an identity with least privilege, not a magic helper with god mode
• Red-team your own AI deployments before you celebrate them
• Instrument the agent's actions with the same telemetry you would demand of any other privileged account

The leadership read

McLeod also described her own arc from technical firefighter to business strategist, from stabilising the posture to anticipating and enabling. That is the right journey, and it maps onto this exact tension. The strategist's job is not to pick the comforting half of the AI story for the board. It is to fund the uncomfortable half. Anyone can sell "AI makes us faster." The actual work is making sure the thing that made you faster did not also hand an adversary a faster way in. Enabler and attack surface. Same object. Budget for both, or you only secured the half that was easy to talk about.

#CISO #AIsecurity #SecOps #Leadership #AppSec

Reporting: Kristina Beek, Dark Reading, "Heard It From a CISO: Zoom CISO: AI as Security Enabler, Not Role-Replacer" (Jun 2026), featuring Sandra McLeod. Analysis and commentary are my own. Read the original.

The Premium Dropped. So Did Your Coverage.

// elusive thoughts // cyber risk // ciso

Good news arrived at the Gartner Security and Risk Management Summit, and like most good news in this industry it came wrapped around a knife. Cyber insurance is getting cheaper. Carriers spent years bleeding on claims they mispriced, and they have finally tuned their models. Rates are softening across the board, and there are even discounts for organisations that can prove a real security posture. If you renew this year, the number on the quote will probably make you smile.

Then you read the policy, and the smile goes away.

The exclusion list is eating the policy from the inside

The single most important shift in this market is not the price. It is the steadily growing list of things your policy will not pay out on. Per Gartner's read, the exclusions now routinely include:

• Employee actions, which in some policies sweeps in social engineering
• Outdated or unpatched software
• Failure to maintain stated security controls
• Incidents tangled up in mergers and acquisitions

Look at the first one again, because it is the landmine. The carrier logic goes like this. If an attacker talks your finance team into wiring a million, and never breaks into a single system, never takes control, never impersonates a machine, then the carrier's position is that no cybercrime occurred. It was a failure of your internal controls. Your problem, not theirs.

Why that one exclusion matters more than the rest

Because social engineering is not a corner case. It is the main event. ClickFix-style attacks, where a victim is convinced to run malicious commands to fix a fake error, made up 52% of what Huntress observed across 2025. That is the majority of real incidents living in the exact category your policy may now decline. You can run a clean tabletop, file the claim, and discover that the most common attack on the planet is the one your insurer files under "not our problem."

That is not a cybercrime. That is a failure of your internal controls.

That sentence, said out loud by an analyst describing how carriers think, should be printed and taped to the wall of every risk meeting.

The fine print nobody reads until it is too late

It gets more textured below the headline exclusions. War clauses have hardened. Lloyd's published cyber-war definitions that most carriers adopted, and they can carve out certain nation-state activity entirely. Mass cyber events, the kind where a major cloud provider falls over and takes half the internet with it, can see payouts cut by as much as half. There are sub-limits hiding inside the big number too. A 10 million policy does not mean 10 million you can hand to a top-tier DFIR firm. There are caps on how much goes to a breach coach, caps on incident response spend, caps you will only find if you go looking.

And then there is the timing trap. Tail coverage. If you switch carriers on the first of the month, then discover last month you were already breached, the new policy will not cover an attack that predates it, and the old one expired the day before. Without tail coverage you fall straight through the gap at the worst possible moment.

What to actually do

This is not a "buy more coverage" post. It is a "know what you bought" post. Sit down with the underwriter, not just the broker, and ask the ugly direct questions. If I get hit by a nation-state actor, am I covered. If the answer is "it depends," then go through what it depends on, line by line, until there are no surprises left. Map your most likely incident scenarios against what the policy will and will not pay on. Most teams I talk to have never done that exercise. They priced the premium and never read the exclusions.

Curiously, AI has not reshaped this market yet. Carriers are watching the rogue-agent horror stories closely, but the policies have not moved much. Enjoy that lull. It will not last, and when it ends, the new exclusions will not arrive with a warning email either.

#CyberRisk #CISO #CyberInsurance #SocialEngineering #ClickFix

Reporting: Rob Wright, Dark Reading, "Cyber Insurance Rates Are Dropping, but Exclusions Widen" (Jun 2026). Analysis and commentary are my own. Read the original.