Harvest Now, Decrypt Later: Why AI Agents Are the Threat No One's Watching
Quick answer: Harvest now, decrypt later (HNDL) is a threat where attackers steal encrypted data today and wait for quantum computers to decrypt it later. AI agents make this worse because every tool call, MCP connection, and agent-to-agent handoff is a new, largely unmonitored place for that data to be intercepted. The fix isn't just a cryptography roadmap. It's controlling what agents are allowed to expose in the first place.
Here's the part of the quantum security conversation nobody's talking about yet.
A breach that happens in reverse
Most breaches announce themselves. A system goes down, a login fails, a file goes missing. HNDL doesn't work that way.
Here's how it plays out: an attacker intercepts your encrypted traffic today. They can't read it. Nothing alerts. No integrity check fails. They just... keep it. And wait for a quantum computer powerful enough to break the encryption protecting it.
That's harvest now, decrypt later, and it's not a future problem. It's happening right now, silently, to any organization moving sensitive data over standard encrypted channels.
Security teams have known about HNDL for a while. But the conversation has almost entirely been about the "decrypt later" half: migration timelines, post-quantum algorithms, Q-Day countdowns. What's been missing is a hard look at the "harvest" half, and specifically, what's changed to make harvesting so much easier.
The answer is agentic AI.
Why agents change the math on harvesting
Old-school HNDL collection needed serious infrastructure. You needed access to internet backbones, undersea cables, or network chokepoints. It was a nation-state game.
Autonomous AI agents blow that cost structure up.
Give an agent tool access, a few API keys, and a task, and it will read files, query databases, call external services, and hand information off to other agents, often with zero human eyes on any individual step. Every one of those handoffs crosses an encrypted channel. Every encrypted channel is a fresh place for someone to sit and collect.
This isn't a hypothetical. It's structural. A workflow that used to mean one encrypted connection between a client and a server can now mean an agent calling a tool, that tool calling another service over Model Context Protocol (MCP), and the result getting routed to a second agent for review, each leg wrapped in TLS, each leg a target.
Security researchers are already flagging this. The proliferation of agentic AI architectures has created dense networks of internal machine-to-machine communication that largely sit outside traditional network security monitoring, and in a multi-agent deployment, dozens or hundreds of these channels can exist at once, each one a potential interception point (Cloud Security Alliance, 18 May 2026).
Builders are seeing it too. As AI architectures get more complex, with agents calling other agents and passing context between systems, the attack surface grows with every communication hop (MindStudio, 4 May 2026).
Two very different sources, a security standards body and an AI infrastructure vendor, landing on the same point: agents don't just process sensitive data. They multiply the number of places it can be intercepted.
What's actually getting harvested
Forget training data sitting in cold storage for a second. The real exposure is in the everyday mechanics of how agents run:
- Tool calls and MCP connections — every invocation carries parameters, credentials, and returned data across an encrypted channel that can be logged today and cracked later.
- Agent-to-agent communication — multi-agent systems pass context, reasoning, and results between components, often carrying the same sensitive information a human email thread would, minus the human oversight.
- Model outputs — proprietary reasoning and sensitive responses generated by the model are explicitly named as HNDL-relevant, right alongside training data, API keys, and cross-boundary agent communications (MindStudio, 4 May 2026).
- Authentication and long-lived credentials — API keys and tokens are valuable on their own if a future attacker can forge or replay them.
Picture a fairly ordinary setup at a healthcare payer today: a claims-processing agent pulls a patient's record from an internal database (tool call #1), calls an eligibility-verification service over MCP to confirm coverage (tool call #2, crossing an organizational boundary), then hands the case to a second agent that drafts an approval or denial explanation referencing the patient's diagnosis and treatment history (agent-to-agent handoff, model output). Each of those three steps is its own encrypted channel, carrying protected health information, and each one authenticates using an API key that lives for months. That's three fresh HNDL collection points in a single, routine claim, none of which existed when a human adjuster handled the same case over one phone call.
None of this needs a working quantum computer today. If an agent is touching healthcare records, legal documents, or financial data, and that data moves over encrypted channels right now, someone storing that traffic today could be reading it in five to ten years. For any enterprise running agents against regulated data, that's a live risk, not a someday risk.
Where the real control point is
Let's be upfront about lane: Enkrypt AI isn't a cryptography or post-quantum migration vendor. If you need a PQC roadmap, that's a different conversation.
But "harvest" isn't purely a cryptography problem. It's a data exfiltration and agent-behavior problem, and that's exactly where runtime controls earn their keep.
The real point of interception isn't only the network wire. It's the agent's own decision about what to send, where, and to whom. That's why the practical control point sits at the tool boundary, not just the transport layer.
- MCP Gateway sits inline between agents and MCP servers, validating tool calls and responses before they execute, screening for data exfiltration, secrets leakage, and connector abuse, and logging every decision for audit.
- Agent Red Teaming tests agent, tool, and MCP configurations against exfiltration and connector-abuse scenarios before they ship, so gaps surface in a test environment instead of in traffic that's already been harvested.
- Agent Risk Taxonomy treats data exfiltration through covert channels and unauthorized data paths as a named, first-class risk category, mapped to frameworks like MITRE ATLAS, so teams know which workflows to lock down first.
None of that replaces a cryptographic migration plan. But if agents are driving the volume of the harvest, cutting what agents are allowed to expose is the fastest way to shrink what's sitting in an adversary's archive, waiting for Q-Day.
The takeaway
The HNDL conversation has mostly been about algorithms, migration windows, and compliance deadlines. Fair enough, those matter.
But agentic AI has quietly turned "harvest" from a nation-state-scale operation into something that happens by default, every time an agent calls a tool, talks to another agent, or returns an output.
Migrate your cryptography. But also ask the more immediate question: what's running through your agents right now, unmonitored, that someone would want to have on hand five years from now?
FAQ
What is "harvest now, decrypt later" (HNDL)?
HNDL is an attack strategy where adversaries intercept and store encrypted data today, holding it until quantum computers become powerful enough to break the encryption protecting it. The breach can happen years before it's discovered.
Why do AI agents make HNDL worse?
Every tool call, MCP connection, and agent-to-agent handoff crosses an encrypted channel. Autonomous agents multiply the number of these channels far beyond what a typical client-server setup would create, giving attackers far more surface area to intercept and store.
Does this mean encryption is broken today?
No. Symmetric encryption like AES-256 is still considered quantum-resistant. The exposure is in the public-key mechanisms (like RSA and ECC) used for key exchange and signatures, which is where post-quantum migration efforts are focused.
Can guardrails alone solve HNDL?
No. Guardrails and runtime monitoring reduce what agents expose in the first place, cutting the volume of sensitive data available to harvest. They don't replace a post-quantum cryptography migration, which addresses the "decrypt later" half of the threat.
How can enterprises start addressing agent-driven data exposure?
Start by mapping where agents call tools, connect to MCP servers, and pass data to other agents. Prioritize monitoring and policy enforcement at those boundaries, and test agent and MCP configurations for exfiltration risk before they go into production.
Sources
.avif)
.svg){kind=small}
