# Remove secrets from code before licensing: the limits > Trying to remove secrets from code before selling it? Before any license, know that scanners miss some, chat and tickets leak keys too, and old keys stay live. By Matt Burns, Vaultfish. Canonical: https://vaultfish.com/answers/remove-secrets-from-code-before-selling Published: 2026-07-09 Updated: 2026-10-14 ## The short answer Remove secrets from code before licensing by scanning, but one scan is not enough. The best scanner reached 75% precision and 88% recall, and faulty patterns missed secrets. Secrets also hide in tools like Slack and Jira. Rotate any leaked credential right away. Ask the buyer how it detects secrets. This page covers the risk and where it sits. It gives no scrubbing method. No buyer I read publishes one for owners to follow. ## Why do secrets matter in a company data license? A company archive often includes the tools where keys end up. [Troveo's business data page](https://www.troveo.ai/business-data) names Slack, Jira and GitHub among the tools it takes. [Mercor's data page](https://www.mercor.com/data/) names Slack, Confluence and GitHub. [GitGuardian's 2026 report](https://www.gitguardian.com/state-of-secrets-sprawl-report-2026) says 32.2% of internal repositories hold at least one hardcoded secret. For public ones, the figure is 5.6%. It also says about 28% of incidents came from collaboration and productivity tools, not code repositories. Both figures come from GitGuardian itself, a security vendor. ## Can a scanner find every secret? No tool in one study did. Basak, Cox, Reaves and Williams compared nine secret-detection tools in [a paper](https://arxiv.org/abs/2307.00714). The best precision was GitHub's scanner at 75%. The best recall was Gitleaks at 88%. The authors trace false negatives to faulty regular expressions, skipped file types and insufficient rule sets. The study dates from 2023. Read the figures as a rough shape and not a current score. ## Does removing a secret from history fix it? [GitHub's documentation](https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning) says secret scanning covers the full Git history on all branches. It also covers issues, pull requests, discussions, wikis and gists. It says removing a secret from history takes a lot of time. It is often unnecessary if you have already revoked the credential. You should rotate the affected credential immediately. GitGuardian reports that 64% of the secrets it found leaked in 2022 were still active four years later. A secret that stays live stays a risk, whoever holds the copy. ## What do the companies say about credentials? [Troveo's page](https://www.troveo.ai/business-data) says people's names, contact details, credentials and client identities are scrubbed. It says [Troveo](/buyers/troveo) handles the anonymization. [micro1](/buyers/micro1) staff said in an undated talk that companies cannot pre-scrub personal information because micro1 transforms it itself. That statement is about personal information and not credentials. I found no published detection method or error rate for secrets from any buyer or marketplace. ## Where does the risk land if one gets through? It depends on the contract. The Sell Traces contributor terms are one published example. They say automated redaction is imperfect and can miss sensitive information. They also make the contributor indemnify Sell Traces (cover its costs) for claims over what a submission contains. Sell Traces is a marketplace for individuals' AI session traces. That is a different product from a company archive. Treat it as an example of where a clause can put the risk. Ask any buyer who scans for secrets, with what tool, and what happens if one gets through. Put the answer in the contract. My [reps and warranties page](/answers/what-reps-and-warranties-does-an-ai-data-buyer-ask-for) lists the promises buyers ask for. The [data readiness checklist](/answers/data-readiness-checklist) and the [managed readiness service](/managed-readiness) both list credentials among the categories to exclude. Talk to a privacy or commercial lawyer in your state before you sign. Figure: scale, Repositories with at least one hardcoded secret: Public repositories 5.6%, Internal repositories 32.2% (emphasized). Internal repositories hold hardcoded secrets far more often than public ones. Source: GitGuardian, State of Secrets Sprawl 2026, self-reported. [Apply to micro1's data partnership (paid link)](https://req.micro1.ai/post/74520e8b-4673-4da5-b855-53609aaf6710?referralCode=f82e519e-5d64-4e0e-9574-760c84371cf2&utm_source=referral&utm_medium=share&utm_campaign=data_referral) ยท [micro1's own data-partnerships page](https://www.micro1.ai/data-partnerships) _Paid link: micro1 may pay us a referral fee if a company we introduce goes ahead with it. You pay nothing extra._ _Vaultfish helps you run the process. We are not lawyers and this is not legal advice. If you need counsel who knows this area, we can point you to one._ ## Sources - [Troveo's business data page](https://www.troveo.ai/business-data) - [Mercor's data page](https://www.mercor.com/data/) - [GitGuardian's 2026 report](https://www.gitguardian.com/state-of-secrets-sprawl-report-2026) - [a paper](https://arxiv.org/abs/2307.00714) - [GitHub's documentation](https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning)