Harvest Now, Decrypt Later: Which Agent Records Actually Need Protection?

Decentralised News · Editorial by Heath Muchena · Evidence reviewed 11 November 2026. Original DN analysis and local instrument; field testing is claimed only where expressly reported.

Find the encrypted copy before estimating exposure

An agent’s activity can leave many records: public transactions, private prompts, customer files, signed approvals, model logs, database backups and network traffic. Calling all of them “quantum-exposed transaction data” combines different problems and makes the resulting number hard to interpret.

The first question is whether the specific copy is confidential and encrypted. If a wallet address, amount or message is already public, a future computer does not need to decrypt it. If a confidential file is encrypted before being placed in public storage, the ciphertext is a different object and needs its own cryptographic review.

DN thesis: a useful historical-exposure record begins with a data copy, its confidentiality requirement and its complete key path. Counting bytes on a public ledger cannot substitute for that inventory.

NIST describes harvest-now-decrypt-later risk as the collection of encrypted data that could retain value until an adversary can break its protection. NIST also emphasizes uncertainty about when a cryptographically relevant quantum computer will exist. This article uses the first observation to organize an inventory without pretending to resolve the second. [1]

Three categories that should not be added together

A single workflow can produce all three. A public payment may reference a private invoice; the invoice may be stored in an encrypted backup; an approval signature may authorize the transaction. Keep linked records without collapsing their protections into one label.

DN’s existing Bitcoin Q-Day Ledger addresses a different question about cryptocurrency cryptography and exposure. The inventory here concerns the continuing secrecy of data copies. It should not be used to infer a wallet’s resistance to signature forgery.

The data cipher is only part of the key path

A system may describe its storage as AES-encrypted. AES is a symmetric cipher; NIST’s standard defines 128-, 192- and 256-bit key variants. That identifies an important component, but the label alone does not describe how the system obtains, protects or distributes the data key. [2]

Ask how the encryption key reaches the service that uses it. Is it established through a public-key exchange? Is it wrapped for a recipient using a public-key mechanism? Are copies stored in a backup or recovery system with another protection scheme? A claim about the data cipher should not conceal an unresolved dependency elsewhere in that chain.

NIST’s ML-KEM standard illustrates the distinction. A key-encapsulation mechanism establishes shared key material that can then be used with symmetric cryptography for tasks such as encryption. The KEM and the bulk-data cipher perform different jobs. Replacing or evaluating one component does not, by itself, describe the entire implementation. [3]

The worksheet therefore asks for a confidentiality key-establishment or wrapping dependency. It allows unknown, a recorded classical public-key dependency, a recorded PQC or hybrid dependency, or a claimed symmetric-only path. These are inventory labels. None receives an automatic “safe” result.

Transport, storage and backups can disagree

Consider a hypothetical agent that uploads customer documents over an encrypted connection and stores them in a database. The network connection, live database, nightly backup, disaster-recovery copy and diagnostic export may use different keys and mechanisms. One successful migration does not establish that all copies have migrated.

A transport protocol name is also insufficient detail. TLS 1.3 defines a handshake and key schedule, including key-exchange modes and traffic-key derivation. Identifying “TLS” or even a version does not record every negotiated parameter, implementation choice or surrounding storage dependency. Preserve the relevant configuration evidence. [4]

For each copy, identify the owner who can answer configuration questions and the reference that supports the inventory entry. A vendor announcement can establish that a feature exists. It does not establish that the organization enabled it on the relevant endpoint, that both sides negotiated it or that historical copies used the same configuration.

GAO’s public migration review discusses the importance of cryptography inventories, including the limitations of incomplete discovery and the need for continuing manual and automated work. The federal findings should not be converted into a statistic about private agent systems. They support the practical point that inventory coverage itself needs examination. [5]

Use the DN Encrypted Record Confidentiality Inventory

Enter one record-class or data-copy alias. Choose its data state and the recorded key dependency. Add the confidentiality and retention expiry dates, an owner reference and a configuration-evidence reference. Both expiry dates mean 00:00 UTC at the start of the entered date, an exclusive boundary. Finally, distinguish unknown historical capture, possible capture without confirmation, and capture supported by an incident reference.

No record prepared. Example inputs are illustrative.

The tool makes no network requests, inspects no files and performs no cryptographic test. Use aliases rather than real customer records, secrets or key material. The downloaded JSON contains the input fields, so treat the export according to the sensitivity of those aliases and references.

Public plaintext is labeled as already public, outside the encrypted HNDL category. Signature-only records are directed to a separate integrity review. For an encrypted copy with a continuing confidentiality requirement, the dependency label determines the next inventory question. Missing evidence remains visible rather than being converted into a reassuring score.

A worked example without a quantum countdown

Suppose an encrypted agent backup’s confidentiality requirement expires at 00:00 UTC on 11 November 2036, while planned retention expires at 00:00 UTC on 11 November 2038. Preparing the record on 11 November 2026 yields a ten-year calendar confidentiality horizon and two additional calendar years of planned retention after that horizon.

If the key path contains a recorded classical public-key dependency, the result directs the owner to review that long-lived ciphertext dependency. It does not say the record will be decrypted in ten years. No quantum-arrival assumption enters the calculation.

The excess-retention field is a planning question, not an instruction to destroy the record. There may be operational, contractual or legal reasons to retain it. The point is to make the two dates explicit so an authorized owner can examine whether the data needs to be kept, kept confidential or managed under a different policy.

Now change the data state to public plaintext. The tool changes the classification to already public. A future confidentiality date cannot make publicly readable information encrypted. The relevant review becomes present disclosure and inference risk, not future cryptanalysis.

Historical capture is a separate evidence question

Possible exposure and confirmed capture should not share a label. An externally accessible communication path can justify considering collection risk without proving that an adversary retained a particular session. A documented incident can support a stronger capture statement, but its scope still needs to be identified.

The instrument requires an incident-reference alias when “confirmed” is selected. It does not open or verify the incident record. This prevents an empty confirmation field from passing as documented evidence while preserving the distinction between a reader’s claim and DN’s own investigation.

Changing protection for future communications does not retroactively change the bytes already collected by another party. Likewise, deleting a local copy does not establish deletion of external copies. These are reasons to preserve historical configuration and incident evidence rather than reporting only the latest system setting.

For a historical cohort, define the collection window, data classes, endpoints and configuration versions before estimating coverage. If the volume of captured ciphertext is unknown, publish that absence. Multiplying total blockchain storage by a guessed sensitivity percentage would not answer the historical-capture question.

Decision table for the next review

What an automatic update should change

Maintain a versioned record per data class and protection boundary. A new configuration can supersede a current entry while leaving the historical entry intact. If a backup service remains on an older path, keep that exception visible instead of marking the whole workflow migrated.

Separate source-review dates from environment-review dates. This article’s 11 November 2026 source check concerns the cited standards and guidance. It is not a verification date for a reader’s infrastructure. The record-creation timestamp likewise indicates when the worksheet was built, not when the configuration was independently tested.

The stable export identifier is dn.encrypted-record-inventory.v1. Preserve the data-state label, dependency, dates, evidence gaps and limitations when an agent summarizes the record. Extracting only the remaining-day count would turn an inventory horizon into a misleading countdown.

For operational memory retention and deletion behavior, see DN’s Agent Memory Benchmark. A system’s ability to forget a live memory and the confidentiality of an old encrypted copy are related governance concerns with different evidence requirements.

Methodology and limits

Both dates are exclusive expiry boundaries at 00:00 UTC. Remaining confidentiality days are the nonnegative calendar-day difference between that expiry date and the record date; they are calendar counts, not exact remaining hours. An expiry equal to the record date has already occurred. Retention beyond confidentiality is the nonnegative difference between the two expiry dates. The JSON explicitly records exclusive_start_of_utc_date. These fields describe user assumptions, not legally required retention periods.

The tool validates real calendar dates and requires an incident reference for a confirmed-capture claim. It does not estimate quantum capability, attack cost, key strength, system coverage or the likelihood that any record has been harvested. An expired confidentiality horizon means only that the entered date has passed; the underlying policy may need correction.

Migration planning requires qualified review of cryptographic protocols, implementations, key management, compatibility and recovery. A local inventory helps identify the questions and accountable owners. It cannot certify the answers.

Frequently asked questions

Is public blockchain metadata a harvest-now-decrypt-later problem?

Readable metadata is already public. Encrypted content or an encrypted off-chain record connected to it is a separate object that can require a confidentiality review.

Does AES encryption settle the quantum question?

The cipher label does not describe the full key path. Record establishment, wrapping, storage and recovery dependencies as well.

Does a PQC or hybrid label prove safety?

No. The deployed configuration, implementation and remaining dependencies still require review.

Can this tool tell me when quantum computers will break my records?

No arrival date or compromise probability is calculated. The date fields describe your confidentiality and retention requirements.

Primary sources

1. NIST: What Is Post-Quantum Cryptography?.
2. NIST FIPS 197: Advanced Encryption Standard.
3. NIST FIPS 203: ML-KEM.
4. RFC 8446: TLS 1.3.
5. GAO-27-108740: Quantum Computing — Federal Actions Needed to Prepare for Emerging Cyber Threat.

Corrections and change log

11 November 2026 — v1.0: introduced copy-specific classification, confidentiality and retention dates, dependency evidence and explicit exclusion of quantum-timeline estimates. Send primary-source or calculation corrections to press@decentralised.news. This edition contains no paid security rating.