Secrets and keys — what never goes in a prompt
خفیہ معلومات اور کلیدیں — پرامپٹ میں کبھی نہ ڈالیں
32 min read
Three ways to see it
A secret is any value that grants access. API keys, database passwords, JWT signing tokens, AWS access keys, customer access tokens, OAuth client secrets, NADRA citizen IDs in test data, real bank account numbers, encryption keys. Anything that, if pasted on a billboard, would force your team to change something. Secrets do not belong in prompts. They do not belong in source code committed to a repo. They do not belong in chat logs. They live in one place: a secret manager. Everything else is a copy that can leak.
Three discipline layers, smallest to biggest. Layer one: .env files. A .env file holds key=value pairs and is loaded into the process at runtime. The .env file is on .gitignore so it is never committed. Your code reads os.environ['SBP_API_KEY'] instead of hard-coding the value. The .env file lives only on machines that need it. This is the bare minimum every junior engineer must learn before they touch production. Layer two: a secret manager service like AWS Secrets Manager, HashiCorp Vault, or 1Password Connect. Secrets are fetched at startup, never written to disk, rotated centrally. Layer three: short-lived credentials that the service issues per request, so even a leaked credential expires in minutes.
What to do if you ever paste a secret by accident. First, do not delete the chat — it lives in vendor logs regardless. Second, rotate the secret immediately at its source: regenerate the API key, force a password change, revoke the token. Third, audit what was done with it during the window of exposure. Fourth, file an incident report with your security team within the hour. Fifth, retrain the team member with the incident as a case study, not as a punishment. Nobody who pastes a secret into a prompt does it twice if the team handles the first time with dignity.
Quick check
Quick check: what makes modern AI different from a rule-based program?
The why-tree
Why-tree level one: why do leaked secrets matter even on a 'trusted' vendor? Because the threat model is not the vendor itself — it is the vendor's employees, the vendor's subprocessors, the vendor's future training corpus, the vendor's possible breach in three years. Once a secret leaves your machine, you lose control of every downstream copy.
Try this with Claude
AI-edge prompt: 'Here is a code snippet I want to debug [paste with placeholders only]. Walk through what the code does, what could be failing, and where to put logging. Do NOT ask me to share the actual API keys, passwords, or real database URLs — those will remain as placeholders.' This phrasing makes the model your accomplice in not leaking secrets, not your enemy.
Sources
Sources and further reading. OWASP, Secrets Management Cheat Sheet (cheatsheetseries.owasp.org). OWASP LLM Top 10, LLM06 Sensitive Information Disclosure. AWS Secrets Manager documentation. HashiCorp Vault documentation. 1Password Connect documentation. Pakistan PECA 2016 (sections on unauthorised access and data interception). Pakistan PDPA 2023 (personal data definitions and breach notification). NADRA Ordinance 2000.