Aller au contenu principal

Coaching — Secrets & Credentials

Why it's risky​

Secrets are values that grant access to systems: API keys, OAuth tokens, AWS access keys, database passwords, SSH private keys, JWT signing keys, webhook signing secrets, certificate private keys.

Sending a secret to a public LLM is equivalent to publishing it on the open internet:

  1. Permanent compromise — once a secret reaches a third-party system, you must assume it is leaked. Rotation is the only safe response.
  2. Auto-completion attacks — secrets in conversation history can be regurgitated by future prompts ("complete the AWS key starting with AKIA...").
  3. Logging & retention — even with no-train policies, secrets often survive in operational logs for 30-90 days.
  4. Lateral movement — a leaked database password becomes a doorway to PII, IP, and customer data simultaneously.

Examples​

"This script fails — can you debug it?
 export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
 export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
 aws s3 cp ./data s3://prod-bucket"
"Why is my Postgres connection failing?
 postgres://app_user:T0p$ecret123@db.internal.acme:5432/prod"

Best practice​

  • Never paste secrets — paste the schema — describe the kind of credential ("an AWS key in ~/.aws/credentials") without the value.
  • Use environment variable names, not values — $AWS_ACCESS_KEY_ID instead of the literal key.
  • Redact before sending — replace with <REDACTED> or a placeholder like <AWS_KEY>.
  • Rotate immediately if leaked — assume any secret sent to a public LLM is compromised; rotate within 24h, audit access logs.

Alternative phrasing​

❌ Risky:

"My AWS S3 sync fails: aws s3 cp with key AKIAIOSFODNN7EXAMPLE and secret wJalrXUtnFEMI/..."

✅ Safe:

"My AWS S3 sync fails with AccessDenied even though my IAM user has s3:PutObject on the bucket. The key is loaded via ~/.aws/credentials. What permissions am I missing?"

References​