The Model Has Preferences. The Harness Has Controls.

This is another collaboration between Usman Chaudhary and myself (his version); this time we decided to explore the mystery of “is harness a security boundary?”

Part 1 of 3 on securing agents. The theme here is: we think that despite alignment efforts, models will make mistakes. The fix is not a better prompt or more more more alignment work. The fix includes a hard boundary around the model, and that boundary is the harness, in some cases.

TL;DR

• Agent = Model + Harness. The model reasons and expresses preferences. The harness executes, and it is the primary execution boundary between model intent and real-world action.
• The model cannot be the security boundary. It is non-deterministic, it treats untrusted text as instructions, and it cannot police itself. A second “guard” model is a useful filter, not a wall.
• The harness is the boundary, the way a firewall and OS sandbox are boundaries for an application. It sits between the model and the enterprise gateway, and today it is the least mature and least watched layer in the stack.
• Fixing it requires two things: controlling what the agent can do through the harness (sandbox [which nobody should trust as a sole security boundary!], narrow identity, egress allowlists) and securing the harness itself as production software (configs, dependencies, and SIEM telemetry). This would be annoying to hear for some.

1. The Incident: A Database Gone in Nine Seconds

Nine seconds. That is how long it took an AI coding agent at PocketOS in late April 2026 to delete the company’s production database and take the attached backups offline right alongside it.

What happened, per Railway’s technical write-up:

• The agent hit a credential mismatch and went looking for a fix.
• It found a cloud API token that let it do far more than fix anything.
• It deleted the production database volume and made the attached snapshots unavailable — leaving PocketOS with three-month-old backups and a 60-hour recovery.

Its own summary afterward was painfully candid, for a 2026 AI:

“I guessed instead of verifying, I ran a destructive action without being asked.”

The tempting question is the wrong one.

• ❌ Why did the model make a bad decision? Models will make bad decisions. Humans do too, and we have spent decades building controls that assume exactly that. “AI as insider” thinking works well here.
• ✅ Why was a bad decision allowed to become an irreversible action? This to us shows lack of security engineering, not “OMG is AI evil or what?” lamentations.

This post argues that the answer lives in the agent harness, not the model.

2. How Agents Work: Model + Harness

The most useful mental model for securing AI agents is also the simplest: Agent = Model + Harness.

• The model reasons. It is probabilistic. It predicts tokens, plans steps, and expresses preferences. It can be persuaded, confused, and tricked.
• The harness executes. It is everything that turns reasoning into action: the agent loop, shell and tool executors, MCP servers, repo config files, approval prompts, the OS sandbox, and (crucially) the credentials the agent runs with. Claude Code, Cursor, Codex CLI, Gemini CLI, and GitHub Copilot’s agent mode are all harnesses.

👉 A model that declines an action is expressing a preference. A harness that will not execute it is enforcing a control. That sentence is the thesis of this post.

None of this is new security philosophy. Least privilege, isolation, identity, and audit logging are decades old. What agents change is where those principles must be enforced and how fast.

3. Why the Model Cannot Be the Security Boundary

Let’s be blunt about something the industry keeps dancing around: the model will never be a reliable security boundary, and it is pointless to treat it as one.

Three reasons, none fixable with a better system prompt:

• It is non-deterministic. The same input can produce a different action tomorrow. A boundary that holds 97% of the time is not a boundary; it is a statistic [I think Claude said this, sounds like it :-)]. Security boundaries are supposed to be boring and repeatable, not fun and adventurous.
• It consumes untrusted text as instructions. Agents read attacker-controlled text all day in READMEs, issues, PR comments, web pages, and tool descriptions, and models fail to reliably separate retrieved data from instructions. The UK NCSC calls LLMs “inherently confusable”; OpenAI and Google both say prompt injection is “unlikely to ever be fully ‘solved’”. Model refusals help [as long as they reject attackers, not defenders, duh!], but they do not hold: in the Nx supply-chain attack, guardrails rejected roughly a quarter of Claude invocations and the attack still succeeded.
• It cannot police itself (self-review). Asking the actor model whether its own next action is safe is asking the suspect to run the investigation. And you do not need a rogue-AI scenario to see the risk: well-intentioned agents have already wiped production databases at Replit during a declared code freeze and at PocketOS, simply because their judgment failed and their blast radius was too wide. Maybe in the future it will, but not it cannot.

“What about a second model that checks the first?” Simple, beautiful, “secure” model, right?

Independent guard and reviewer models (Google’s Model Armor and the reviewer models OpenAI and Anthropic now ship inside their harnesses, as do many other security vendors) are a real risk-reduction layer, and we recommend them. But a reviewer model is still a probabilistic filter, not a final authorization boundary. You have stacked a second set of preferences on top of the first set: Anthropic’s own reviewer publishes a 17% false-negative rate across 52 real overeager actions. A useful filter, but not a wall, and not “a security invariant” for sure.

The Appsec vs. Firewall Analogy

We have been here before with web applications. Application security (secure coding, input validation, code review) makes the app harder to exploit, but every serious app still ships bugs — so we put runtime boundaries (firewalls, WAFs, OS sandboxes, IAM) around the app to enforce rules it cannot violate even when it is buggy or actively exploited. Agents work the same way:

• Model alignment, safety training, and prompting ≈ agent “appsec”/modelsec (fewer bad decisions, never zero).
• The harness ≈ runtime enforcement (sandbox [usually porous], tool policy, and IAM that keep bad decisions from becoming irreversible actions).

👉 The harness is the security boundary for the model, exactly as the firewall and sandbox are boundaries for the app — not because the model is bad, but because software fails.

4. Defense in Depth: Model, Harness, and Gateway

Saying “the harness is the primary execution boundary” does not mean “only the harness matters.” In practice, an enterprise running agents relies on three control layers with distinct jobs:

• 1. The model (alignment, safety training, refusals). Run by the model vendor to reduce the rate of bad decisions. Probabilistic.
• 2. The harness (OS sandbox, tool policy, scoped identity, secrets handling, egress allowlist, approval gates, hooks, telemetry). Shipped by the AI vendor and configured by the customer to constrain all execution — both local and remote.
• 3. The enterprise agentic gateway (policy, identity brokering, MCP proxying, DLP, and logging across external model, tool, and data traffic). Run by the enterprise security team to centralize policy and SOC visibility across agents.

The layers are not interchangeable:

• ❌ A gateway does not see local endpoint execution. If a harness runs as the developer with — dangerously-skip-permissions, the gateway never sees a local rm -rf or secret read on a laptop.
• ❌ A harness alone does not give the SOC a cross-team control plane.

And the harness is the least mature of the three. The model gets the research attention. The gateway is where enterprise vendors (ours included) are converging. The harness sits in the middle: shipped by AI vendors, configured by developers, treated as a productivity plugin, and mostly invisible to security.

BTW, one of us (Anton) will revisit defense in depth in the age of AI soon (this is one for cloud).

👉 If the harness is the execution boundary, it has to be built, configured, and watched like one.

5. Where the Harness Fails Today

Once you look at the harness as a security boundary rather than a developer convenience, three specific gaps stand out in how harnesses are deployed today.

1. Approval fatigue and bypass modes ( — yolo)

• A coding agent makes hundreds of tool calls in a single session. Ask a human to approve each one at machine speed and they stop reading within the hour: Anthropic measured users approving 93% of permission prompts before it introduced auto mode. A control that everyone clicks through is not a control.
• When friction gets too high, developers turn it off, and most major coding-agent harnesses expose an explicit bypass mode for exactly that ( — dangerously-skip-permissions in Claude Code, — yolo in Gemini CLI and Codex).

2. Over-privileged credentials and shared identity

• Today, local harnesses typically inherit the developer’s ambient git keys, cloud tokens, and MCP connections into Slack, GitHub, and production consoles.
• Unless sessions carry a separate agent identity, the agent’s blast radius equals the human’s — and the SOC cannot easily tell human and agent apart.

3. The harness itself is an unmonitored software attack surface

Harness CVEs and bypasses

• Cursor’s MCPoison bound trust to a server’s name rather than its contents (Tenable).
• A GitHub Copilot exploit used prompt injection to flip on its own auto-approve setting (Embrace The Red).
• Even actively maintained harnesses ship bugs fast: Anthropic’s claude-code repository lists more than 30 security advisories.

Weaponized configs and flags

• Agent config files are executable. In June 2026, the Miasma worm planted malicious configs across 73 Microsoft repositories that ran on open. No CVE required.
• In the Nx attack, which leaked 2,000+ verified secrets, the malware invoked victims’ own AI CLIs with bypass flags to do its reconnaissance.

SOC blindness

• Harness telemetry is opt-in and redacts prompts and tool arguments by default (Elastic Security Labs).
• Copilot’s audit log omits local prompts entirely (GitHub).
• Raw chain-of-thought is never released to customers (Anthropic).

👉 The first two gaps are failures to contain what the agent can do. The third is a failure to protect and monitor the harness itself.

6. How to Secure the Harness: Three Architectural Moves

Closing those gaps means doing two jobs at once:

• Controlling what the agent can do (security within the harness): enforcing hard limits on execution and reach so a bad model decision cannot become a catastrophe.
• Protecting the boundary itself (security for the harness): governing the harness’s code, configs, dependencies, and telemetry. A firewall with a remote code execution bug is not a boundary; neither is a harness whose config file can be rewritten by a README.

In practice, that comes down to three architectural moves:

• Move A: Take enforcement out of the model. Run commands inside an OS sandbox with deterministic tool policy — backed by an independent, reasoning-blind reviewer model for judgment calls (stripped of the actor’s chain-of-thought so the agent cannot talk its way past the check) — with structured steering on blocked actions and human prompts reserved for irreversible ones.
• Move B: Shrink what the agent can reach. Give the agent its own identity, short-lived scoped tokens, secrets kept outside the sandbox, and an egress allowlist — breaking Simon Willison’s “lethal trifecta” of private data, untrusted content, and an outbound channel.
• Move C: Govern and watch the harness itself. Put agent config files under branch protection, pin MCP dependencies, and stream action telemetry and hooks to the SIEM.

Each move gets its own deep dive in Part 2 (hopefully!)

7. What the Harness Cannot Solve (Ever?)

A boundary is only trustworthy if you are honest about where it ends.

1. Prompt injection at the model layer remains unsolved. That is not a gap in the harness story; it is the premise of it. Every harness control assumes injection can succeed and asks what happens next.
2. Bugs inside the vendor’s harness are the vendor’s to fix. Pick vendors who publish advisories and ship fixes fast, and treat harness updates like browser updates.
3. The endpoint remains the thinnest layer. AI detection and response on developer laptops, where most harnesses actually run, is immature. Cloud-hosted sessions sidestep part of this; local agents do not.

In other words, if you endpoints are owned, you need better host security, not “unbeatable” AI security (translation: it will get beaten anyway)

Conclusion & What’s Next

Strip away the new vocabulary and harness security is least privilege, isolation, identity, and logging, applied to a process that reads untrusted text and acts at machine speed. AI changes the speed of the attack, not the fundamentals of defense.

👉 The model will keep having preferences. The harness is where the controls go, and today it is the least watched layer in the stack.

Coming next (hopefully!):

• Part 2: Three moves to secure the harness. Moves A, B, and C in detail: OS sandboxing and reviewer models (with the error and prompt-reduction rates vendors have published); dedicated identity, scoped tokens, and egress allowlists that break the lethal trifecta; and agent config as code, pinned MCP dependencies, and action telemetry in the SIEM.
• Part 3: Nobody owns the whole problem. The shared-responsibility split between model providers and enterprises, which vendors ship which control today, the prerequisites that have to be true first, and five actions for this quarter.

Got comments? What stands between a coding agent’s bad decision and your production environment today? If the honest answer is “the model’s judgment,” you have a preference in a place where you need a control.

P.S. This blog is ended up being very overengineered, but you can forgive us for this perhaps :-)

The Model Has Preferences, but the Harness Got Controls - Part 1 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our analysis an AI-powered espionage campaign targeting government Linux infrastructure with custom malware, web shells, and advanced credential theft.

The post AI-Powered Espionage Campaign Targets Government Linux Infrastructure appeared first on Unit 42.

Most people have opened their messages to find a suspicious alert urgently telling them that a package cannot be delivered, a toll remains unpaid, a bank account needs attention, or a tax bill is overdue. The details may change, but the goal is the same: to get someone to click, share personal information, or pay. 

These messages are relentless. Delete and block one, and another takes its place. Ignore them, and more will follow. Fall for one, and the floodgates open. What appears to be a simple scam message is often the visible end of a much larger transnational cybercriminal operation. 

When Microsoft and Japan’s National Police Agency (NPA) followed a wave of fraud and scam activity targeting people and businesses in Japan, they expected to find individual campaigns. Instead, they found themselves inside a sprawling Chinese-language cybercrime marketplace where criminals could buy accounts, hosting services and tools used to create fake websites and online identities. The investigation expanded globally, involving the Japan Cybercrime Control Center (JC3), Resecurity, Cloudflare, Oracle, Proofpoint and TRM Labs to uncover the businesses sustaining this criminal ecosystem. 

Today, Microsoft and Health-ISAC, a global non-profit that helps health sector organizations share cyber threat information and collaborate to improve operational resilience, are moving to dismantle three components of this criminal marketplace: YAM Store, CoGUI and Iron Man.  

Since January 2026, YAM Store, CoGUI and Iron Man have collectively enabled more than one billion malicious messages targeting over 75,000 organizations worldwide, including more than 750 million messages geared toward Microsoft customers alone. These messages have been used to target consumers, healthcare organizations, financial institutions, and other businesses in more than 150 countries, generating tens of millions of dollars for their operators.   

Tracing the businesses behind the scams

The investigation began in late 2025 after Japan’s NPA alerted Microsoft to malicious messaging campaigns targeting people in Japan. NPA continued providing intelligence and investigative support as the partners traced those campaigns back to the businesses supplying criminals around the world. 

The trail led investigators deep into a Chinese-language cybercrime ecosystem that was difficult for non-native-speaking investigators to penetrate. There, they gained access to CoGUI, which supplied criminals with ready-made websites and messages impersonating companies, financial institutions, government agencies, and other trusted organizations. Instead of creating fraudulent websites themselves, criminals could quickly deploy pages designed to steal passwords, payment information, and other personal data.  

As Microsoft’s investigation expanded, intelligence from JC3 helped confirm the scale of the activity affecting Japanese organizations and their customers. Drawing on information collected across its network of more than 130 member organizations, JC3 connected what appeared to be separate incidents to a broader pattern of scams targeting Japanese companies and financial institutions, including efforts to defraud consumers and to steal credentials and other sensitive information.  

One name that kept appearing throughout the investigation was YAM Store. YAM Store operated much like an online shop. Customers could browse products, compare prices and purchase fraudulent Microsoft and Google accounts and other ready-made tools used to carry out scams, including credential theft. Controlled purchases conducted by Microsoft helped confirm how it worked. 

In some cases, operators acquired internet domains that legitimate organizations had allowed to expire, often targeting certain sectors, such as non-profits and education, with specialized product offerings. They then rebuilt the websites to make those organizations appear active, allowing them to fraudulently obtain Microsoft 365 accounts that could later be sold through YAM Store.  

Ready-made tools

YAM Store provided criminal infrastructure that was frequently paired with tools and services such as CoGUI. As investigators dug deeper, they found that the marketplace was already evolving. CoGUI had become one of the most widely used offerings in the ecosystem, particularly targeting victims in Japan and the United States but by mid-2026 it was increasingly being replaced by a newer offering known as Iron Man. 

Iron Man expanded the model by giving criminals access to thousands of ready-made templates designed to impersonate trusted organizations. Criminals could then quickly deploy email, text and web content tailored to specific brands, industries and countries.  

Through test purchases and work with Resecurity, investigators gained access to Iron Man and identified more than 2,300 templates impersonating banks, retailers, healthcare providers, transportation authorities, police departments, government agencies, and other organizations across more than 150 countries worldwide. Some were designed for government impersonation scams, using the appearance of official authority to pressure victims into making payments or disclosing sensitive personal information. Others impersonated organizations across industries, countries, and languages, from banks and airlines to telecommunications companies, retailers, and parcel delivery services.  

Examples of these impersonation templates are below. Importantly, the presence of an organization or government entity in these templates does not indicate that its systems were compromised. 

A blog from Microsoft Threat Intelligence shares more details on the network, as well as steps customers can take to protect themselves.  

Putting the pieces together

No single organization saw the full picture. Japan’s NPA played a critical role throughout the investigation, providing intelligence, investigative support and collaboration that helped uncover how the operation worked. JC3 helped establish the scale of the activity affecting Japanese organizations and consumers. Health-ISAC provided insight into impacts affecting healthcare organizations, while Resecurity, Cloudflare, Oracle, Proofpoint and TRM Labs contributed intelligence and investigative support.  

Working together, and with the assistance of AI tools, we connected accounts, websites, and infrastructure that initially appeared unrelated, helping expose the broader criminal marketplace behind them. Microsoft also worked closely and shared intelligence with U.S. Secret Service and international law enforcement partners.

This investigation also reflects a broader trend highlighted in this year’s Microsoft Digital Defense Report: modern fraud increasingly relies on businesses and services that make it easier for criminals to reach more victims. It took two-way information sharing across industries and international borders to uncover how these deeply interconnected services worked together. 

Going after the suppliers

With an order from the United States District Court for the Southern District of Florida, Microsoft and Health-ISAC seized and redirected domains that were part of the underlying infrastructure powering YAM Store, CoGUI and Iron Man. Microsoft has already disabled more than 20,000 accounts connected to YAM Store and continues to dismantle the operation by removing infrastructure hosted on its services and blocking more than 100,000 domains used for impersonation and fraud.   

What began with scam activity targeting people and organizations in Japan led investigators to an underground service economy supplying criminals around the world. YAM Store, CoGUI and Iron Man are only part of that larger criminal network, but disrupting them makes it harder for criminals to obtain the accounts, tools and infrastructure they rely on. 

The scam message is often the only part victims see. The businesses behind it are what make it possible. 

The post Disrupting the service economy behind transnational cybercrime operations appeared first on Microsoft On the Issues.

Somewhere in your organization is a spreadsheet of certificate expiry dates, and someone who owns it. That is not a caricature. DigiCert’s 2026 research with Omdia surveyed more than 400 senior IT leaders and found that 47% still rely on manual tracking methods such as spreadsheets, and only 34% have a complete, current view of what they hold. The spreadsheet works because renewals come around once a year, and one person with a calendar can keep the whole estate in their head.

The industry has decided to take that away. The CA/Browser Forum voted in April 2025 to bring the maximum TLS certificate lifespan down in steps: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029, with domain validation reuse dropping to 10 days. The first step is already live: since March 15, 2026, no publicly trusted TLS certificate can be valid for more than 200 days. By 2029 you will be proving ownership of your domains roughly every month, for every certificate, forever. The spreadsheet does not survive that. Neither does the person.

Why TLS certificate lifespans are shrinking to 47 days

Shorter lifespans shrink the window in which a stolen key or a mis-issued certificate is useful, and they push the whole ecosystem onto automation, which is where the reliability actually comes from. The destination is better. The journey is where outages live. Every manual step in your renewal process is a place where a 47-day cycle breaks something a 365-day cycle never stressed. We covered what the vote means for Imperva customers when it passed; this post is the checklist.

How to prepare for 47-day certificates: five things to do, in order

1. Inventory what you actually have. Every certificate, every domain, every site, and who renews it. Cloud WAF reports SSL coverage status for each protected site, so start with your public-facing estate. It is the part with a deadline attached and the part your customers meet first.
2. Automate domain validation now. Manual validation at a 10-day reuse window is not a process, it is a permanent job for somebody. Automatic CNAME validation makes ownership proof continuous, and it is the single change that turns the 2029 schedule from alarming to routine. The payoff starts now, not in 2029: Imperva already requires domain revalidation every 99 days for its managed certificates. We walked through the setup in Effortless certificate management with automated CNAME validation.
3. Find your non-SNI traffic before it finds you. Server Name Indication (SNI) is the TLS extension that tells the server which hostname a client is asking for. Clients that do not send it, usually older HTTP libraries, outdated monitoring tools and misconfigured internal services, cannot be served a site certificate (a site with non-SNI connections is not eligible for one), and they are rejected outright once a site moves to SNI-only mode. That is why this step comes before the next one. Non-SNI clients are also invisible unless you go looking. One custom rule with the filter hasSNI == false, set to Alert, logs every non-SNI request as a security event without blocking anything. Leave it running for a week or two, since some of this traffic is periodic, then decide. Imperva Cloud WAF Technical Guide: How to Identify Non-SNI Traffic Before Enabling SNI-Only Mode walks through it step by step.
4. Isolate the blast radius. A certificate shared across your whole estate means one renewal problem is everyone’s problem. Imperva site certificates give each site its own certificate, its own coverage status and up to 50 domains, so one team’s missed renewal does not become another team’s outage. New SNI-only sites have required site certificates since September 13, 2026, and Imperva recommends migrating existing SNI sites off shared account certificates by December 31, 2026, before automatic migration begins in Q1 2027.
5. Connect the certificate system you already run. If your certificates are governed in a Certificate Lifecycle Management (CLM) platform, the system that issues, tracks and renews certificates centrally, or in your own PKI, those renewals should reach your WAF without a person in between. The SSL Integration Center connects that workflow directly to Imperva Cloud WAF. DigiCert Trust Lifecycle Manager and Keyfactor Command are on the supported vendor list, with further CLM integrations in progress.

What Imperva is already doing: 90-day certificates and the R46 root

Imperva-managed certificates have already moved to 90-day validity (with domain validation every 99 days), ahead of the industry deadlines, with renewal and deployment automated end to end. Root trust is moving too: the GlobalSign root transition (R3 to R46) is covered by a cross certificate that Imperva includes by default until the R3 root expires in March 2029, so legacy clients keep working, and action is needed only if you pin to a specific root certificate. The direction of travel is simple. Certificate work becomes something you configure once, not something you do monthly.

The detail lives in the Cloud WAF documentation, and walks the site-certificate path step by step.

Back to that spreadsheet. If it is yours, the right time to retire it is while it still works. If you retired it years ago, the question is whether your automation reaches all the way to your applications, or stops at the CA.

Frequently asked questions about 47-day certificates

When do 47-day TLS certificates take effect?
From March 15, 2029, publicly trusted TLS certificates can be valid for no more than 47 days. The CA/Browser Forum schedule gets there in steps: 200 days from March 15, 2026 (already in force) and 100 days from March 15, 2027.

How often will I need to validate domain ownership?
The period for reusing domain validation follows the same schedule: 200 days from March 2026, 100 days from March 2027 and 10 days from March 2029. In practice that means validating for almost every renewal, which is why an automated method such as CNAME delegation matters.

Do I need to do anything for Imperva-managed certificates?
Imperva renews and deploys its managed certificates automatically, and they already have 90-day validity. What stays with you is domain validation (automatic CNAME validation removes it), moving SNI sites from shared account certificates to site certificates, and updating your trust store if you pin to a root certificate.

What happens to clients that don’t support SNI?
A client that doesn’t send SNI can’t be served a site certificate, and once a site moves to SNI-only mode those connections are rejected. A custom rule with the filter hasSNI == false, set to Alert, shows whether you have any before you switch.

The post 47-Day Certificates Are Coming: Five Things to Do Before They Arrive appeared first on Blog.

Somewhere, an attacker is recording your encrypted traffic. Not breaking it. Recording it. The bet is patient and simple: store ciphertext today, wait for quantum computers to mature, decrypt at leisure. The industry calls it harvest now, decrypt later (HNDL), and it is the rare security threat with a believable deadline attached: data with a ten-year shelf life, encrypted with algorithms on a countdown.

Most quantum-readiness advice hands you a project: audit your cryptography, plan your migration, stand up a working group. Here is what Cloud WAF customers had to do to get quantum-safe TLS on every connection between their users and the Imperva network: nothing.

What shipped: hybrid post-quantum TLS on every Cloud WAF site

Every TLS 1.3 connection from a PQC-capable client to Imperva now negotiates hybrid TLS key agreement: X25519MLKEM768, which runs classical X25519 and quantum-safe ML-KEM-768 together. ML-KEM is the key-encapsulation mechanism NIST standardized as FIPS 203 in August 2024. It is enabled by default on all Imperva sites, with zero configuration and no measurable performance trade-off. If a client supports it, it is on. Your users’ sessions are already protected against the recording attack, and nobody on your team filed a ticket to make that happen. You can see it for yourself: open Chrome DevTools, go to the Security panel, and the connection to any Imperva-protected site lists X25519MLKEM768 as its key exchange. We explained earlier this year why post-quantum cryptography can’t wait; this post is the update now that both legs are covered.

The second leg: post-quantum TLS from Imperva to your origin

A proxy architecture has two connections per request: client to edge, and edge to origin. As of the October 4, 2026 release, Imperva also supports PQC on the Imperva-to-origin leg, so customers whose origin servers support post-quantum key agreement get quantum-safe encryption end to end: from the user’s browser, through the Imperva network, to their own infrastructure. The requirement on your side is one sentence long: an origin that can negotiate the hybrid handshake. In practice, that means OpenSSL 3.5 or later, which offers X25519MLKEM768 by default. Sites created on or after October 4, 2026 get PQC to origin automatically. Existing sites keep their current behavior until you switch it on under SSL/TLS Configuration > Origin connection security, or with the /v3/sites/origin-pqc API. If an origin can’t negotiate the hybrid handshake, the connection falls back to classical TLS without disruption.

The honest scope: what hybrid key agreement covers

Post-quantum TLS is arriving across the industry, and that is a good thing; no vendor should claim the category. What differs is the operational bill. Here the answer is: defaults. No premium SKU, no per-site enablement, no migration project for the edge leg, and, for end to end, an origin-side capability check plus one switch on sites created before October 4, 2026. For regulated sectors already fielding quantum questions from auditors and boards (finance, healthcare, defense), that turns a program into a paragraph in your next review. Behind it sits the Thales portfolio, where post-quantum work spans well beyond the WAF. One limit worth stating plainly: hybrid key agreement protects the confidentiality of each session, which is exactly what a harvest now, decrypt later attack targets. Certificate signatures are a separate, later migration (NIST’s ML-DSA, FIPS 204), because forging a signature needs a quantum computer at the moment of the handshake. Recorded traffic gives an attacker nothing to work with there.

What to do about harvest now, decrypt later

• Nothing, for the client leg. It is already on.
• Check your origin stack for hybrid key-agreement support, and switch on the second leg when it does. That means OpenSSL 3.5 or later. New sites have PQC to origin on by default; existing sites need it switched on once, in the Cloud Security Console or through the API.
• Put one line in your next security review: sessions through Cloud WAF are quantum-safe by default. Boards like sentences that end.

Detail, including how to test PQC and how to switch it on for your origin, is in the Post-Quantum Cryptography (PQC) Support documentation.

The recording attacker is patient. As of now, what they are recording from your traffic is noise with no future.

Harvest now, decrypt later: FAQ

What is a harvest now, decrypt later (HNDL) attack?

An attacker records encrypted traffic today and stores it until a cryptographically relevant quantum computer can break the classical key exchange that protected it. Data that must stay confidential for years is at risk now, even though that quantum computer does not exist yet.

Is Imperva Cloud WAF traffic protected against harvest now, decrypt later?

Yes, for the key exchange. TLS 1.3 connections from PQC-capable clients to Imperva use hybrid X25519MLKEM768 by default on all sites. Connections from Imperva to your origin use it when the origin supports it (OpenSSL 3.5 or later) and PQC to origin is on: by default for sites created on or after October 4, 2026, and opt-in for existing sites.

What is X25519MLKEM768?

It is the hybrid TLS 1.3 key-exchange group that combines classical X25519 elliptic-curve key agreement with ML-KEM-768 (FIPS 203). An attacker has to break both to recover the session key. It follows the hybrid model adopted by Google Chrome and other major browsers, and it is what Chrome DevTools shows when a connection is post-quantum protected.

What happens if a client or origin doesn’t support post-quantum TLS?

The connection falls back to classical TLS key exchange without disruption. PQC is used only when both sides support it, and it requires TLS 1.3. See the Imperva PQC documentation for the handshake scenarios.

The post Harvest Now, Decrypt Later: The Attack You Defend Against by Doing Nothing appeared first on Blog.