What we hold, and what we never take

AutoPQC works by recording how an estate does cryptography. That is a narrower job than it first sounds, and the narrowness is deliberate. Discovery records the existence, configuration and lifecycle of cryptographic objects; it does not record the secrets those objects protect. This article sets out every category of data we hold, why we hold it, and the specific things we refuse to take even when a customer offers them.

#Existence and configuration, not secrets

A cryptographic inventory needs to know that a listener on a given host negotiates ECDHE with a P-256 key, that the certificate presented expires on a given date, that a signing service is provisioned for RSA-2048, and that a particular library version is linked into a build. None of those facts require the private half of a key pair. None of them require the plaintext of anything. The line between metadata about cryptography and the material cryptography protects is the whole of our data model, and every detector is written to stay on one side of it.

We build this way because it is the only defensible position for a vendor in our category. A company that centralised key material for hundreds of estates would become the most attractive single target in each of them. The inventory we hold is sensitive, and we treat it as sensitive, but on its own it does not decrypt anything of yours.

#The categories of data we hold

Everything we hold falls into one of eight categories. The table below states what each category is, why the product cannot work without it, a concrete example, and whether records in that category leave your environment for the AutoPQC control plane.

Two rows deserve emphasis. Detector evidence is bounded by design: a snippet is capped at the smallest fragment that makes the finding reviewable, credential-shaped and token-shaped strings are redacted before the record is written, and the snippet is pruned on the schedule described in Retention and deletion. Scoped discovery credentials are the only secret we ever hold, they are held only because you chose authenticated discovery, and they are revocable by you at any moment without our involvement.

#What we never take

The following list is not a statement of current defaults. It is a set of hard boundaries in how the product is built, and the reason each one exists.

• Private keys and key material. No private keys, no material resident in a hardware security module, no key-encryption or wrapping keys, no seed or recovery material, no PKCS#12 bundles with their passphrases. Discovery reads the public half of a key pair and the configuration around it. If answering a question would require the private half, we do not answer it that way.
• Plaintext of encrypted payloads. We report that a channel, field or volume is encrypted and how. We do not decrypt it, we do not ask you to decrypt it for us, and we do not accept a decrypted copy as a convenience.
• Production personal data as a matter of course. A cryptographic inventory does not need customer records, patient records, transaction rows or message bodies. Where a detector could incidentally read such content, it is either redacted at source or restricted to metadata before it ships.
• Credentials beyond the scoped read-only access agreed in writing. One identity per environment, read-only, defined in a written scope document, revocable at will. No shared administrator accounts, no domain administrator, no standing write access, and no credentials passed to us over chat or email.
• Full packet captures without written scope. A full capture is indiscriminate: it contains everything on the wire, including exactly the material listed above. We work from handshake metadata instead. Where a capture is genuinely the only way to resolve a question, it happens under a named, time-boxed written scope with a stated capture filter, and it is destroyed on completion.

#Where the line falls, in four concrete cases

A TLS endpoint

We record the protocol versions offered, cipher suites, key exchange groups, chain composition and expiry dates. We do not record session keys, and no application data carried over the session is read.

A hardware security module

We record that the module exists, its reported firmware and configuration, the algorithms it is provisioned for, and which services call it. Material inside the module stays inside the module, which is the point of the module.

A source repository

We record which cryptographic libraries and primitives are referenced, at which versions, in which files. Any credential-shaped string a detector encounters is discarded rather than stored, and no repository content is retained beyond the evidence snippet.

An encrypted database column

We record the algorithm, mode, key size and the key management path where configuration exposes it. We do not read the column, and we do not need to in order to score it.

In each case the inventory ends up knowing enough to tell you whether the asset survives a quantum-capable adversary, and not enough to help one. That is the trade we have chosen. It costs us some depth of finding, and we would rather pay that cost than hold your secrets. Where it costs you a resolved finding, Accuracy, false positives, and how we report error explains how the gap is surfaced instead of silently filled.

#Separation, internal access and audit

Holding a category of data is one question. Who can reach it is a separate one, and the answer matters as much as the inventory itself.

• Tenant separation. Every record carries a workspace identifier, and authorisation is enforced at the data access layer rather than in individual queries. Cross-workspace reads are a defect class we test for, not a configuration option.
• Least privilege internally. Engineers hold no standing access to customer inventory data. Access is requested against a named reason, granted for a bounded period, and logged. Approval requirements are set out in the Assurance Center.
• Break-glass leaves a record. Emergency access exists, because an incident at three in the morning is not the moment to discover it does not. Every use writes an immutable entry naming the operator, the reason and the scope, retained for [PLACEHOLDER: break-glass log retention period].
• Your own visibility. Roles control what your people see inside a workspace. Roles and permissions covers the model; Workspaces, teams and projects covers how estates are partitioned.

#Checking what we hold about you

1. 01Export the inventory from the workspace. The export is the same data the interface renders, in machine-readable form, including evidence references. Cryptographic bills of material describes the format.
2. 02Ask for a data map. We will return the categories above with the specific records held for your workspace and the retention clock applying to each. Requests go to /contact.
3. 03Ask us to delete. The procedure, the confirmations you receive and the small set of records we are obliged to keep are in Retention and deletion.