From 02ba241aadac59dc6a1f7288e723bfd332ed6bc4 Mon Sep 17 00:00:00 2001 From: Arun Kumar Thiagarajan Date: Sat, 27 Jun 2026 23:08:49 +0530 Subject: [PATCH 1/2] docs(security): add data privacy & compliance section Adds a Data Privacy & Compliance section to security-and-hardening: PII/sensitive classification, data minimization + purpose, retention/deletion paths (incl. backups), data-subject rights (GDPR/CCPA), consent for third-party/vendor sharing, and data residency. Complements the hardening content (can an attacker read it) with the privacy question (should we hold it, and for how long). --- skills/security-and-hardening/SKILL.md | 34 +++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/skills/security-and-hardening/SKILL.md b/skills/security-and-hardening/SKILL.md index 2ddd1352d..acf291380 100644 --- a/skills/security-and-hardening/SKILL.md +++ b/skills/security-and-hardening/SKILL.md @@ -1,6 +1,6 @@ --- name: security-and-hardening -description: Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. +description: Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when collecting, storing, retaining, deleting, or sharing personal data, or addressing privacy/compliance (GDPR/CCPA). --- # Security and Hardening @@ -353,6 +353,27 @@ git diff --cached | grep -i "password\|secret\|api_key\|token" **If a secret is ever committed, rotate it.** Deleting the line or rewriting history is not enough — assume it's compromised the moment it reaches a remote. Revoke and reissue the key first, then purge it from history. +## Data Privacy & Compliance + +Securing data is "can an attacker read it?" Privacy is "should *we* even hold it, and for how long?" — a separate question that hardening doesn't answer. The cheapest data to protect, breach, and comply over is the data you never collected. Treat personal data as a liability to minimize, not an asset to hoard. + +**Know what you hold.** You can't protect or honor a deletion request for data you can't find. Classify fields as you add them: + +| Class | Examples | Handling | +|---|---|---| +| **Non-personal** | Aggregates, anonymized counts | Normal handling | +| **Personal (PII)** | Name, email, IP, device/user IDs | Minimize, access-control, include in export/delete | +| **Sensitive** | Health, finance, location, biometrics, gov IDs, anything about minors | Extra basis to collect, stricter access, often encryption + audit logging | + +**Operating rules:** +- **Minimize and set a purpose.** Collect a field only against a stated use. "It might be useful later" is not a purpose — it's latent breach scope. Don't log PII into telemetry (the `observability-and-instrumentation` skill makes the same point from the ops side). +- **Set retention up front, then actually delete.** Every personal-data store needs a TTL and a working deletion path — including backups, caches, search indexes, and analytics copies. Data with no expiry is a breach scheduled for later. +- **Support the data-subject rights your jurisdiction requires** (GDPR/CCPA and kin): export, correct, and delete on request. These are engineering features — design the schema so a user's data is *findable* and *erasable*, not smeared irreversibly across systems. +- **Get consent before collection or third-party sharing**, and make it auditable. Sending PII to an analytics/ad/LLM vendor is "sharing" — the user's choice gates it, and the vendor needs a data-processing agreement. +- **Localize defaults, don't hardcode one region's law.** Data-residency and rules differ by user location; make the policy a configurable boundary, not an assumption. + +When data crosses a trust boundary, validate it as untrusted (see Input Validation above); when a privacy incident exposes personal data, the breach-notification clock is part of the postmortem — follow the `debugging-and-error-recovery` skill. + ## Securing AI / LLM Features If your app calls an LLM — chatbots, summarizers, agents, RAG — it inherits a new attack surface. Map it to the [OWASP Top 10 for LLM Applications (2025)](https://genai.owasp.org/llm-top-10/): @@ -405,6 +426,9 @@ container.textContent = await llm.reply(userMessage); - [ ] No secrets in code or version control - [ ] Sensitive fields excluded from API responses - [ ] PII encrypted at rest (if applicable) +- [ ] Personal data is classified, collected against a stated purpose, and minimized +- [ ] Personal data has a retention limit and a working deletion path (incl. backups/indexes) +- [ ] Export/delete (data-subject) requests are supported where required; sharing with third parties has consent ### Infrastructure - [ ] Security headers configured (CSP, HSTS, etc.) @@ -438,6 +462,9 @@ For detailed security checklists and pre-commit verification steps, see `referen | "Threat modeling is overkill here" | Five minutes of "how would I attack this?" prevents the design flaws no control can patch later. | | "It's just LLM output, it's only text" | That "text" can be a SQL statement, a script tag, or a shell command. Treat it like any untrusted input. | | "The audit passed, so the dependency is safe" | Audits match known advisories. They do not detect a newly malicious package or make unreviewed install scripts safe to execute. | +| "Collect it now, we might need it later" | Data you don't hold can't be breached, subpoenaed, or mis-deleted. "Might need it" is breach scope, not a purpose. | +| "We'll handle deletion requests manually" | Manual erasure misses backups, caches, and analytics copies. If the schema can't find a user's data, you can't honor the request — design for it. | +| "Compliance is legal's problem, not ours" | Export, deletion, retention, and consent are schema and code. Legal can't bolt them on after you've smeared PII across ten systems. | ## Red Flags @@ -451,6 +478,9 @@ For detailed security checklists and pre-commit verification steps, see `referen - Server fetches user-supplied URLs without an allowlist (SSRF) - LLM/model output passed into a query, the DOM, a shell, or `eval` - Secrets, PII, or the full system prompt placed inside an LLM context window +- Personal data collected with no stated purpose, retention limit, or deletion path +- PII sent to analytics/ad/LLM vendors with no consent or data-processing agreement +- "Delete my account" that only flips a flag while the personal data lingers in stores and backups ## Verification @@ -465,3 +495,5 @@ After implementing security-relevant code: - [ ] Rate limiting active on auth endpoints - [ ] Server-side URL fetches validated against an allowlist (no SSRF) - [ ] LLM/model output validated and encoded before use (if AI features present) +- [ ] Personal data is classified, minimized to a stated purpose, and has a retention limit +- [ ] Deletion and export requests work end-to-end (including backups, caches, and analytics copies) From 7e824bb94952d3e7917a5d4781d4c8793ca9c98e Mon Sep 17 00:00:00 2001 From: Arun Kumar Thiagarajan Date: Fri, 10 Jul 2026 09:39:04 +0530 Subject: [PATCH 2/2] fix(security): trim frontmatter description to clear eval routing regression The privacy trigger phrase used generic verbs (collecting, storing, retaining, deleting, sharing) that pulled the security skill's routing rank above other skills on unrelated prompts. Replacing with a tight 'personal data or privacy compliance' phrase preserves discoverability without over-triggering. --- skills/security-and-hardening/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/skills/security-and-hardening/SKILL.md b/skills/security-and-hardening/SKILL.md index acf291380..be62067d8 100644 --- a/skills/security-and-hardening/SKILL.md +++ b/skills/security-and-hardening/SKILL.md @@ -1,6 +1,6 @@ --- name: security-and-hardening -description: Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when collecting, storing, retaining, deleting, or sharing personal data, or addressing privacy/compliance (GDPR/CCPA). +description: Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when personal data or privacy compliance (GDPR, CCPA) is involved. --- # Security and Hardening