Production Security & Compliance Basics
- Handle secrets in production correctly: injection, rotation, and never-in-git discipline
- Map the PII flows of an LLM application: what enters prompts, logs, caches, and third parties
- Explain data retention and deletion obligations, and design logs/caches that can honor them
- State what SOC 2 and GDPR mean operationally for an engineer shipping an AI feature
- Complete a customer-style security review checklist against your own capstone
| Spaced-rep warm-up: due cards incl. Day 44 auth & Day 132 guardrails | 10 min |
| ELI5 + tech read; write the secrets rules from memory | 15 min |
| Guided: secrets audit + rotation drill + PII map | 40 min |
| Practice: the Meridian questionnaire | 25 min |
| Project: wire CI check, redaction, TTLs; file issues | 20 min |
| Quiz + flashcards | 10 min |
Builds on: Day 44 — Security, authN & authZ · Day 132 — Guardrails, injection & AI security · Day 153 — IaC & environments — config vs secrets · Day 142 — Tracing — privacy & redaction in traces
A shop owner locking up at night runs a ritual, not a vibe: till emptied into the safe, safe combination known by two people and changed when staff leave, doors and windows checked in the same order every time, alarm armed, camera tape dated. None of it is exotic — burglars mostly try doors, and the ritual makes sure no door is accidentally open. And when the insurance inspector visits, the owner doesn't say "trust me" — they show the checklist, the logbook, the rota.
Production security for your AI app is that ritual. Secrets (API keys, DB passwords) live in a safe (a secrets manager or injected environment), never taped under the counter (hardcoded, committed to git). Keys are rotated when people or machines change. Everything travels through locked corridors (TLS). The camera tape is your audit log: who asked what, when, and what the system did. And compliance — SOC 2, GDPR — is the insurance inspector: not a different job, but proof that the ritual exists, runs every night, and leaves evidence. The scary acronyms mostly ask questions you can answer with "here is the checklist, here is the log."
The fastest way to lose an enterprise deal is to fumble the security review. Before any pilot touches real data, the customer's security team sends a questionnaire: where do prompts go? Is our data used for training? How long do you retain logs? Who can access production? Can you delete a user's data on request? FDEs sit in that meeting, and "I'll get back to you" on every row kills momentum. Engineers who design PII-aware logging and rotation-friendly secrets from the start — instead of retrofitting under deadline — are the ones who pass. Day 170 (customer environments) and Day 177's final security gate both build on today.
Guided practice
Secrets audit and rotation drill
20 min- Run the starter scanner over your capstone repo INCLUDING git history (
git log -ppiped through it, or use a real tool like gitleaks if installed). Triage every hit: real secret, test fixture, or false positive. - If anything real ever touched history: rotate that key NOW and note that removal from history alone is not enough — the key must be considered burned.
- Verify runtime injection: confirm the deployed capstone reads all secrets from environment/secret store, none from committed files. Check the Docker image too (
docker history, and inspect for baked-in env values). - Rotation drill: issue a second API key with your provider, deploy it alongside the old one, flip the app to the new key, confirm the canary stays green, revoke the old key. Time yourself — under 15 minutes means rotation is a non-event; write the steps into the runbook.
Map the PII flow and fix the leaks
20 min- In
docs/data_map.md, draw the capstone's data flow as a text diagram: user question → API → [logs? traces? cache?] → model provider → response → [logs? feedback store?]. Mark every node that stores a COPY and its current retention (be honest: "forever" is the default you never chose). - Grep your actual logs and traces from staging for a test user's question text. If the raw question appears verbatim in more than one store, you have found your retention problem.
- Apply two fixes: (a) add a redaction step before logging (emails, phone numbers, names via regex/allowlist — Day 142's redaction pattern) so logs keep structure but drop raw PII; (b) set explicit TTLs on the semantic cache and log retention.
- Answer in writing, from your provider's actual data-use documentation: does the provider train on your API data? What is their retention window? Is a zero-retention option available? Cite the page.
On your own
Face the questionnaire
25 minA fictional enterprise prospect, Meridian Mutual Insurance, sends their standard vendor security questionnaire before your capstone pilot. Answer all twelve rows honestly for YOUR capstone as deployed today — "No / not yet, mitigation planned: X" is an acceptable answer; a false "Yes" is not.
- Is all data encrypted in transit (TLS ≥1.2) and at rest? 2. Where are secrets stored and how often are keys rotated? 3. Which subprocessors receive our data? (Name your model/embedding providers.) 4. Is our data used to train models? 5. What is your log/trace retention period, and is PII redacted? 6. Can you delete all of a named user's data within 30 days? Describe how. 7. Who has production access, and is it audited? 8. Do you have monitoring/alerting and an incident-response runbook? (Point to Days 157–158 artifacts.) 9. What is your deploy process — is there review and rollback? 10. Have you tested against prompt injection and the OWASP LLM Top 10? (Day 133/144 reports.) 11. Do you enforce least-privilege on database and vector-store access? 12. Describe your backup and recovery posture.
Deliver as docs/security_questionnaire.md with a traffic-light summary at top: green (true today), yellow (partial), red (missing). Hints: expect 4–6 greens if you have been doing the capstone gates; that is normal — the red list is your Day 176 hardening backlog.
The security-review pass
Turn today into capstone hardening: (1) secrets scanner wired into CI as a failing check, and the rotation drill documented in the runbook with your timing; (2) PII redaction live in the logging/tracing path, verified by re-grepping staging telemetry for planted PII; (3) TTLs set on cache and logs, recorded in docs/data_map.md; (4) the completed Meridian questionnaire committed with its traffic-light summary; (5) the top two red items converted into GitHub issues tagged for Day 176. The deliverable standard: a real security reviewer could read your three docs (data_map, questionnaire, runbook) and know exactly what your system does with data.
Common mistakes & misconceptions
- Deleting a committed secret and moving on. Git history keeps it and scrapers found it already; a secret that touched a remote repo is burned — rotate it.
- Logging full prompts and completions "for debugging" with no retention or redaction. That is an unbounded PII store you never designed; minimize, redact, and set TTLs.
- Treating compliance as a lawyer problem. Auditors ask for evidence of controls — access lists, change logs, incident records — and only engineering can make those exist.
- Answering a customer questionnaire aspirationally. A false "yes, encrypted at rest" discovered mid-pilot destroys the relationship; honest yellows with dated mitigation plans build trust.
- Forgetting the model provider is a subprocessor. Your customer's data leaves your boundary on every request — know the provider's training/retention terms and disclose them.
- Designing deletion as an afterthought. Scattered, unstructured logs make erasure requests archaeology; consistent user identifiers in structured logs make them a query.
Q1. A teammate accidentally commits an API key, then force-pushes to remove it from history. What is the required next step?
Q2. GDPR's "data minimization" translated into LLM-app engineering means…
Q3. In a customer security review, which answer about model providers is correct and safe?
Go deeper — curated resources
- OWASP cheat-sheet habit — For any security mechanism you touch (session management, key storage, logging), skim the corresponding OWASP cheat sheet before implementing — it is the field-tested checklist your reviewer will grade you against.
- Rotation drill completed and timed; secrets scan in CI
- PII redaction verified against planted data in staging telemetry
- data_map.md and security_questionnaire.md committed, no false greens
- Quiz ≥ 2/3
← Back: Day 44 gave you the auth and least-privilege vocabulary; Day 132's injection threat model explains half the OWASP rows; Day 142's trace redaction and Day 153's secrets handling become enforced policy today.
Forward →: Day 160's designs must speak privacy fluently (the fourth corner of the quadrilemma). Day 170 extends this to customer-controlled environments (VPC, customer-managed keys), and Day 177 re-runs this checklist as the capstone's final quality gate.
Unlocks: D170 Customer Environments