Part 2: Post Mythos, defend the destination, not the roads

Last week I argued that Mythos and GPT-5.4-Cyber mark the end of the maximalist security model. Exhaustive defense of everything is no longer a viable operating posture.

So what replaces it?

Defend the destination, not the roads

Strip away the tradecraft and the adversary wants data. Ransomware crews want data to encrypt and exfiltrate. Nation-states want data to inform decisions. Insiders want data to take with them. Financial actors want data to monetize. The zero-day, the phish, the lateral move, the credentialed pivot, the agent compromise: all transportation.

If the destination is data, the defender's organizing principle should be data. Endpoints, identities, networks and vulnerabilities all play a role, but they are means rather than ends. Defend those and you are defending from the attacker's vantage point. Defend the data and you defend from the position where you hold leverage. In 2026, "more control" is what scales.

The profession has spent thirty years defending the roads.

Working backwards from the crown jewels

This is not a new argument. Forrester has been writing about data-centric security since 2010 and DSPM is a category for a reason. What is new is that the AI shift removes the option of treating it as one strategic choice among several. The expected-loss math no longer supports the alternatives.

Part 1 named the structural reason. The attacker finds one path; the defender must close all of them. That asymmetry has always existed and AI made it the whole game. The only response that scales is shrinking what "one path" buys the attacker. Shrink the destination, the identities that reach it and the pathways between them and a single compromise lands somewhere that does not matter.

There is a second reason this work survives the AI shift when other approaches do not. Part 1 made the point that AI compresses vulnerability discovery while patch deployment runs at human speed. Patches still ship through change windows, dependency trees and the political economy of IT. Detection still relies on signals that arrive after the adversary has already moved. Data-centric controls behave differently: decommissioned data stays decommissioned, revoked access stays revoked and a pathway map does not expire on Patch Tuesday. These are the only controls that do not require defenders to outrun an AI-accelerated adversary, because they reduce what the adversary can do with their head start.

Reduce on every available axis, then harden what cannot be reduced.

1. Identify the crown jewels. Five to ten categories whose exposure changes the trajectory of the business. MITRE formalized Crown Jewels Analysis over a decade ago; the gap in most programs is not the concept but the follow-through. Unreleased financials, M&A, source code that encodes competitive advantage, customer data whose loss triggers regulatory exposure, executive communications, legal discovery. If the list has fifty items, it is not a crown-jewels list. The set is smaller than most teams assume and that is the point.
2. Decommission what isn't needed. The most defensible data is the data that does not exist. Stale deal rooms, legacy customer exports, decommissioned product specs, departed-employee drives. Every file deleted is a file the adversary cannot reach through any pathway, known or unknown. Data minimization is an attack-surface control and the most underused one in the industry. A common starting point for decommissioning is data beyond a certain age.
3. Tighten access to what remains. Revoke stale access, collapse over-broad groups, scope agent permissions, audit service accounts. Agents deserve their own note here. Most integrations today inherit the principal's full permission set, so a prompt-injected or compromised agent operates with the standing access of the human who invoked it. The pattern that survives contact is per-task scoping with short-lived tokens: the agent gets exactly the permissions the work in front of it requires, bound to a window measured in minutes. Same JIT logic as the fintech example below, applied to non-human identity. Every attacker pathway eventually routes through some identity's legitimate access. A fully hardened endpoint operated by an over-provisioned user is one compromise away from data loss.
4. Map the pathways that survive. Track effective access across inherited memberships, delegated agents and nested chains across identity providers. Part 1 made the point that the defender's Mythos and the adversary's are not running the same search. The defender hunts for bugs to fix; the adversary hunts for the smallest set to chain. Pathway mapping aligns the defender's view with what the adversary's Mythos is optimizing for. The honest answer to "who can reach the crown jewels" is almost never the same as the answer in the org chart. An all too common scenario: a deal-room SharePoint site nominally restricted to ten employees is found to be reachable in practice by two hundred because its permission group contains an Entra ID security group with a legacy "all-finance" group nested inside it that nobody has reviewed in three years. The data is exactly where it should be. The pathway is not.
5. Harden what's left. Now the standard disciplines come back, reordered. Pathways and data context set the priority for patching, monitoring, segmentation and detection. A SharePoint zero-day on a marketing site is not the same risk as the same zero-day on the deal room. When NVD officially conceded on April 15 that it cannot enrich every CVE, CVSS stopped being a triage primitive for anything outside KEV. Data context is what replaces it. Vulnerability management without data context is triage by severity score. Vulnerability management with data context is triage by expected loss.

The order in which this takes place is essential. Three reduction moves come before mapping, before hardening. First shrink the target, then the identities that reach it, then the pathways. What survives is what earns the limited defender hours. With a 22-second handoff between initial-access brokers and secondary groups, you are not going to intercept the chain in flight. You harden the destination before the chain reaches it, or you do not harden it at all.

The reason programs have kicked this work down the road for years is organizational. Crown-jewel identification, data deletion and identity pruning fail at ownership every time.

Identifying the crown jewels runs into a classification problem. The context for what's sensitive lives with the line of business that generated the data, and that team may have over-classified everything to be safe, under-classified it to move faster or never classified it at all. Security has to do the work jointly with them and there is no shortcut around the meetings.

Decommissioning data is worse. No security team wants to delete a file and get yelled at by the executive whose archive it lived in. The data owner has to cooperate, and with stale data the original owner has often left the company and the institutional context left with them.

Decommissioning identity is the thorniest of the three. Decades of entitlements sit in production, granted by people who left, inherited through groups nobody remembers creating and nested in chains nobody has audited. Pulling threads creates side effects that don't show up in test environments and break workflows in production.

Every one of these is hard, which is why classification, deletion and identity pruning have sat at the bottom of program backlogs for fifteen years and why we are in the mess we are in. The math now forces the work, and the only way through is in bite-sized chunks: pick one crown-jewel category, run the loop end to end on that single slice and let the wins fund the political capital for the next.

Two examples

A Fortune 500 company started decommissioning the hard way, after a breach exfiltrated sensitive records from a data lake holding petabytes of stale customer data nobody had inventoried. The analytics environment had too much surface and too many pathways; the adversary only needed one. By working the playbook in order: stale data first, then stale identities, then pathways and then hardening what remained, the company was able to operate from a footprint they could defend.

A public fintech proactively ran a mature version of the same playbook against Snowflake. They reduced their sensitive data footprint, removed all standing access to Snowflake roles and built a just-in-time portal where employees lease the narrowest role they need for a fixed window. The adversary is hunting for standing access that does not exist.

Both started the same way. The security team defined what they believed was sensitive, ran a scan and used the distance between expectation and reality to calibrate the definition. That calibration loop made the rest of the work tractable.

I run engineering at Bedrock Data and in Part 3, I'll show how we've been putting this framework into practice.