Secrets in the archive: credentials, keys and card numbers

Every company archive contains secrets. Not trade secrets, but the literal kind: a staging password pasted into a channel, an API key committed to a repository, a card number typed into an email to a vendor. Nobody meant to leave them there, and most people have forgotten they exist. Any responsible data licence has to find them and take them out.

People share credentials the fastest way available, especially under pressure. A new hire cannot log in, so someone drops the password in a direct message. A deploy is failing, so an engineer pastes the full error log into a ticket, environment variables and all. The office manager emails the company card details to a supplier because the supplier's payment portal is down.

None of this is unusual. It happens at well-run companies as much as at chaotic ones. Over several years, the result is a scattered layer of sensitive values buried inside otherwise ordinary records.

The places they tend to collect include:

• Chat messages and threads, especially in engineering and operations channels
• Code repositories, including configuration files, test fixtures and old commits that were later "fixed"
• CI and deployment logs attached to tickets or pull requests
• Email threads with vendors, banks, payment processors and IT providers
• Spreadsheets and docs used for onboarding, expenses or account setup
• Screenshots and PDFs, such as a photo of a card or a scanned identity document

Commit history deserves a special mention. Removing a key from the latest version of a file does not remove it from the history. Anyone reviewing the repository's past versions can still see it.

Most identifiers in a licensed dataset are replaced with consistent tokens. A person becomes PERSON_014 everywhere they appear, which keeps conversations and projects coherent for training. Secrets are handled differently. Credentials, API keys, card numbers and government ID numbers are removed outright.

The reason is simple. A token for a person carries useful structure: it tells a model that the same individual wrote this message, owns that ticket and approved this pull request. A token for a password carries nothing a model needs. There is no learning value in knowing that the same database password appeared in four places. There is only risk if anything about the original value survives. So the safest treatment is also the most useful one: take it out and leave a neutral marker showing that something was removed. For the general distinction, see tokenization vs. redaction.

No single technique catches everything, so detection is layered. In general terms, the layers look like this.

Format matching finds values with a recognizable shape. Many API keys and access tokens follow documented patterns. Card numbers have a fixed length range and a checksum that can be verified, which separates real card numbers from random strings of digits. Many government ID formats are also structured.

Context matching catches secrets that have no fixed format. A random-looking string next to words like "password", "secret", "token" or "login" deserves a closer look, as does any line in a configuration file that assigns a value to a credential-sounding name.

Randomness checks look for long strings that are statistically unlike normal text or code, which is a common property of keys and generated passwords.

Images and documents need their own pass. Text in screenshots and scanned PDFs is extracted and checked the same way, and faces, logos and signatures are blacked out. We cover that part in faces, logos and signatures.

Layering matters because each method has blind spots. Combined, and followed by human review of samples, they produce a much safer result than any one of them alone.

Removing secrets from the licensed copy protects the dataset. It does not protect your live systems. If a key was pasted into chat three years ago and never rotated, it may still work today, whether or not anyone ever licenses the data.

So treat a data licence, or a wind-down, as a prompt for basic hygiene:

• Rotate API keys and service credentials that may have been shared in chat or committed to code
• Revoke access tokens for integrations you no longer use
• Cancel or replace any company card whose details have been emailed or messaged
• Close cloud accounts and resources that are no longer needed

None of this depends on a licence going ahead. It is simply good practice, and it means that even an overlooked fragment would point to something that no longer works.

Before anything is delivered, the seller reviews an anonymized sample. That review is a chance to confirm that the tokenization reads sensibly and that nothing sensitive slipped through. If a secret turns up, it is a signal to adjust the rules and run the pass again, not a one-off fix.

No third party touches the raw data at any stage. The raw archive is deleted within 30 days of sign-off as a contract obligation, and a deletion certificate is issued. The licence itself forbids any buyer from attempting to re-identify, contact or profile anyone in the data. The full pipeline is described on our trust page.

Secrets are in every archive, usually in more places than anyone expects. They are removed rather than tokenized, found by several overlapping methods, and checked again in the sample you review. Rotating your own credentials is a sensible step alongside all of it.

If you are considering a licence and want to talk through how your archive would be handled, book a short call.