BLOG

Surviving Mythos-Class AI: No Mass Breach by Default

Junbum Shin, Founder & CEO @ Datarmor
June 1, 2026

TL;DR: The question isn’t if a breach happens. It isn’t even when. It’s how much. Mythos-class AI compresses the attack timeline to the point where patch-driven defense becomes a losing race. Zero Trust is still necessary — but it doesn’t limit the blast radius after a compromise. Data Exfiltration Resilience does. BreachLocker keeps Personally Identifiable Information (PII) encrypted, policy-gated, and exposure-capped, so mass breach is not the default outcome.

Weaponized AI breaks the assumption that software is trustworthy

Weaponized AI is a new category of offensive capability. These systems autonomously discover vulnerabilities, generate working exploits, and chain multiple weaknesses into complete attack paths — with minimal human intervention.

The defender’s response window is collapsing as a result. According to Zero Day Clock, which tracks Time-to-Exploit (TTE), the Mean Time to Exploit went from 21.5 days in 2025 to 1.6 days as of May 24, 2026.

That’s a structural imbalance. Attackers now move faster than defenders can patch, verify, and deploy fixes across complex enterprise environments. Patching still matters, but it can’t be the only line of defense in a world where exploitation precedes disclosure.

So organizations need to operate under a more realistic assumption: some part of the system is already compromised, or will be soon.

Existing defenses lower risk — they don’t cap damage

In the weeks since the Mythos announcement on April 7, 2026, the industry has converged on a set of defensive responses. Each is necessary. Each addresses a real layer of the attack chain. But none of them, on its own, answers the question of how much data is breached when a compromise inevitably happens.

The most widely proposed responses are:

  • Pre-emptive Patching Coalitions — e.g., Anthropic’s Project Glasswing
  • AI-Driven Vulnerability Discovery — e.g., Google Big Sleep
  • Zero-Trust — e.g., Assume Breach. Never Trust, Always Verify. Least Privilege Access
  • Encrypted Computing — e.g., Confidential Computing and Homomorphic Encryption

These tracks are complementary, and most enterprises will need several. But they share one limitation: they primarily reduce the probability of a breach. They don’t inherently limit the scale of data exfiltration after an attack succeeds.

The fix: Data Exfiltration Resilience via Bounded Exposure

Data Exfiltration Resilience is the security property that guarantees the maximum volume of plaintext sensitive data obtainable from any compromise stays policy-bounded.

From access control to exposure control

Security architecture has moved through several stages — perimeter security, then identity, access control, and Zero Trust. These models still matter. But they aren’t enough when vulnerabilities can be weaponized faster than defenders can react.

The next phase is exposure control. Access control asks who gets in; exposure control asks how much they can take once they’re already inside.

This is the gap. There’s been no security solution providing bounded exposure at whole-system scale — nothing that prevents mass data breach by default. Two reasons:

  • Existing computing requires plaintext. Software and AI consume large volumes of data, so it’s been impossible to define a bound that prevents mass breach.
  • Least privilege is the foundation of modern security — in systems, databases, access control — but it governs who can access data, not how much.

What makes Bounded Exposure possible

Bounded Exposure rests on two observations.

First, encrypted computing now works in practice. Confidential computing (TEEs — trusted execution environments) and homomorphic encryption (HE) let data be processed without decryption. AI and software need huge amounts of data, but adopting encrypted computing means that data never has to appear as plaintext. They are practical: Confidential computing typically adds 3–10% on intensive workloads. With HE, a 1:1 match runs in under 1 ms and statistics over 10 million records finish in seconds.

Second, humans can’t read at machine scale. Plenty of workflows legitimately need data shown to a person — customers viewing their own profile, call center agents pulling up customer info. But there’s a physical limit: no human reads millions of records. So we can define an exposure policy — a cap — on the volume of data a human can see, based on workflow. No cap for admins on PII; 100 records per day for a call center agent.

BreachLocker for PII

BreachLocker applies Bounded Exposure to PII. Mass PII exposure is what turns a breach into a catastrophic financial event, so preventing mass PII breach by default is the whole game.

It’s built from four components:

  1. Protector. Replaces plaintext database output with protected representations (encryption + token). Encrypted data lives and is processed in the encrypted data plane; the token stays in the existing data plane. No PII exposure at this stage.
  2. Encrypted Computing. BreachLocker supports TEEs and Homomorphic Encryption. It runs on the encrypted data plane: applications call an API with tokens and get tokens back — the protected result of the computation. No PII exposure here either.
  3. Deprotector (Decryption Control). The final enforcement point. It governs human access to plaintext PII and enforces policy-defined exposure caps. This is the only place plaintext appears at all, and it appears only within the cap.
  4. Policy Engine. Defines which kinds of PII are protected, and the caps — how much plaintext PII a given subject can access.

In practice, BreachLocker works in four steps:

  • Step 0 — Set policy. Define exposure-cap rules in the Policy Engine.
  • Step 1 — Protect output. Database output becomes tokens for the Data Plane and ciphertext for the Encrypted Data Plane.
  • Step 2 — Encrypted computing. The system calls the API for Encrypted Computing.
  • Step 3 — Decrypt by policy. The system calls the API; the Deprotector checks the exposure cap and releases plaintext only if allowed.

What this does to your blast radius

Think about a customer’s system before and after.

  • Before BreachLocker: the system is complex, and with vibe coding it can expand fast. It’s genuinely hard to know how exploitable it is. And even before Mythos-class weaponized AI, breaches were everywhere.
  • After BreachLocker: there’s no exposure anywhere in that complex system except after the Deprotector, for human views — and that’s under the cap. Whatever an attacker reaches, what they can actually read out is set by your policy.

The blast radius stops being unknowable. It becomes a number you set.

Easy to adopt

Encrypted computing has a reputation for being difficult to roll out. The usual assumption is that you have to re-architect the entire system.

BreachLocker is built to do the opposite: change the minimum, not the whole system. This rests on two design choices. – Separate data planes. BreachLocker introduces an encrypted data plane that runs independently of your existing data plane, so it doesn’t disturb what you already have. – Format-preserving tokens. Because each token keeps the same shape as the original data, your existing schemas, application code, and integrations keep working as-is. You only touch the parts that actually need sensitive data — encrypted computing and deprotection — by calling the BreachLocker API.

Adoption is lighter for two more reasons. First, BreachLocker plugs into your database encryption: the Protector sits right after database decryption, so if your database is already encrypted, BreachLocker drops in — and if it isn’t, we provide the encryption layer. Second, key management is handled by BreachLocker; decryption keys for plaintext PII are no longer scattered across your environment, removing one of the hardest parts of any encryption rollout.

How BreachLocker itself is secured

BreachLocker is designed to minimize attack surfaces, and it hardens each one:

  • Protector integrates with database encryption — it protects the encrypted DB output right after decryption. If a customer feels their DB encryption isn’t strong enough, we’ll consult to improve it (or they can use BreachLocker’s optional DB encryption).
  • Encrypted Computing is protected with confidential computing (AWS Nitro Enclave) and/or homomorphic encryption.
  • Deprotector is protected with confidential computing (AWS Nitro Enclave).
  • Policy Engine is protected with confidential computing (AWS Nitro Enclave).

The current version runs on AWS, with Nitro Enclave as the TEE. The enclave exposes only a single interface — vsock — for communication in and out of the TEE. To block message-based attacks, every message is protected by a security protocol implemented in Rust, which prevents overflow attacks.

The core innovation isn’t simply using TEEs or HE — those are the foundation. The harder problem is turning them into an end-to-end system that neither attackers nor BreachLocker itself can abuse. Key management is one example. Even though BreachLocker manages decryption keys, we must not be able to use them to see customer data — a guarantee that goes beyond what TEEs or HE provide on their own. That’s why BreachLocker is designed to be secure against us, too: even if we’re compromised, no one — attacker or insider — can extract plaintext beyond the policy cap.

Every countermeasure is designed and validated by our security experts, and we’re open to sharing the details with qualified partners under NDA.

A few questions we get

  • Why bounded exposure, not bounded exfiltration? Once data is exposed, exploits make it very hard to stop it from leaving. So we draw the line one step earlier, at exposure.
  • Why bounded exposure, not zero exposure? Because sensitive data still has to be usable for the business.
  • What about AI agents? Encrypted computing applies to agents too. Some don’t support it yet — BreachLocker for AI is coming.

What BreachLocker does not claim

BreachLocker doesn’t replace patching, Zero Trust, IAM, PAM, SIEM, EDR, CNAPP, or incident response — nor the need for secure software development and vulnerability management. Those protect availability and integrity, and they still matter.

The takeaway

Mythos-class AI forces a shift in strategy. The critical question is no longer only “Can we stop the attacker?” It’s also: “How much damage can the attacker do after they’re in?”

BreachLocker for PII is the answer. It keeps sensitive data protected by default, lets you compute without unnecessary plaintext exposure, and enforces policy-defined caps at the point of disclosure. The blast radius is always below the policy cap — by default.

Sources

🔒

Coming Soon

We're building this product right now. Be the first to know when it launches.