@cubis/foundry 0.3.83 → 0.3.84

package/workflows/skills/sanitize-pii/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "pii-detection-log-output",
-    "title": "Detect PII in application log output",
-    "description": "Given log samples containing various PII types, the skill should identify each instance, classify it, and recommend redaction approaches.",
-    "prompt": "Review these application log samples for PII exposure and recommend sanitization:\n\n```\n2025-01-15 10:23:45 INFO  UserService: Created user john.doe@example.com with ID 12345\n2025-01-15 10:23:46 DEBUG PaymentService: Processing payment for card ending 4242, full number 4111111111111111, CVV 123\n2025-01-15 10:23:47 ERROR AuthService: Login failed for user SSN=123-45-6789, IP=192.168.1.100\n2025-01-15 10:23:48 INFO  OrderService: Shipping to John Doe, 123 Main St, Springfield IL 62704, phone (555) 123-4567\n2025-01-15 10:23:49 WARN  APIGateway: Rate limit exceeded for API key sk_live_abc123def456ghi789\n```",
-    "assertions": [
-      {
-        "type": "content_matches_regex",
-        "value": "email|john\\.doe@|email address",
-        "description": "Must identify email address PII in the UserService log line"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "credit card|card number|PAN|4111|CVV|payment card",
-        "description": "Must identify full credit card number and CVV as critical PII"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "SSN|Social Security|123-45-6789",
-        "description": "Must identify SSN as critical PII requiring immediate remediation"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "redact|mask|filter|sanitiz|replace|\\*{3,}|\\[REDACTED\\]",
-        "description": "Must recommend specific redaction or masking approach"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "API key|sk_live|secret|credential|token",
-        "description": "Must identify the exposed API key as a secret/credential leak"
-      }
-    ]
-  },
-  {
-    "id": "gdpr-data-masking",
-    "title": "Design GDPR-compliant data masking for a non-production environment",
-    "description": "Given a database schema with PII fields, the skill should produce a GDPR-compliant masking strategy for creating safe non-production datasets.",
-    "prompt": "Design a GDPR-compliant data masking strategy for our staging environment. Here is the database schema:\n\n```sql\nCREATE TABLE users (\n  id SERIAL PRIMARY KEY,\n  email VARCHAR(255) NOT NULL,\n  first_name VARCHAR(100),\n  last_name VARCHAR(100),\n  date_of_birth DATE,\n  phone VARCHAR(20),\n  ssn_encrypted BYTEA,\n  address_line1 VARCHAR(255),\n  city VARCHAR(100),\n  postal_code VARCHAR(10),\n  country VARCHAR(2)\n);\n\nCREATE TABLE orders (\n  id SERIAL PRIMARY KEY,\n  user_id INT REFERENCES users(id),\n  total_amount DECIMAL(10,2),\n  shipping_address TEXT,\n  payment_token VARCHAR(255)\n);\n\nCREATE TABLE support_tickets (\n  id SERIAL PRIMARY KEY,\n  user_id INT REFERENCES users(id),\n  subject VARCHAR(255),\n  body TEXT,\n  agent_notes TEXT\n);\n```\n\nStaging must have realistic data for testing but no real PII. We serve EU customers.",
-    "assertions": [
-      {
-        "type": "content_matches_regex",
-        "value": "GDPR|Article|regulation|data protection|lawful",
-        "description": "Must reference GDPR requirements for data masking"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "email.*mask|mask.*email|fake.*email|synthetic.*email|anonymiz",
-        "description": "Must specify masking strategy for email addresses"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "format.preserv|tokeniz|synthetic|faker|fake data|realistic",
-        "description": "Must recommend format-preserving masking or synthetic data generation"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "free.text|support_ticket|body|unstructured|ticket.*body|agent.*notes",
-        "description": "Must address free-text fields (support ticket body, agent notes) as requiring NLP-based or full replacement masking"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "referential integrity|foreign key|user_id|relationship|consistent",
-        "description": "Must address maintaining referential integrity across masked tables"
-      }
-    ]
-  }
-]

package/workflows/skills/sanitize-pii/examples/01-log-pii-detection.md

@@ -1,146 +0,0 @@
-# Example 1: Detecting and Remediating PII in Application Logs
-
-## User Prompt
-
-> Our compliance team flagged that our application logs might contain PII. Review these log samples and tell us what to fix:
->
-> ```
-> 2025-03-10 09:15:22 INFO  [UserController] User registered: email=sarah.jones@company.com, name=Sarah Jones, DOB=1990-05-15
-> 2025-03-10 09:15:23 DEBUG [PaymentService] Charging card 4532015112830366 exp 12/26 for user_id=8842
-> 2025-03-10 09:15:24 ERROR [AuthService] Failed login attempt: username=admin, password=P@ssw0rd123, IP=203.0.113.42
-> 2025-03-10 09:15:25 INFO  [OrderService] Shipping order #9921 to 742 Evergreen Terrace, Springfield, IL 62704
-> 2025-03-10 09:15:26 WARN  [APIGateway] Rate limited: user_agent=Mozilla/5.0, client_ip=198.51.100.23, api_key=ak_prod_7f3a9b2c1d
-> 2025-03-10 09:15:27 INFO  [SupportBot] Ticket #4412 from John Smith (SSN: 987-65-4321): "I need to update my bank account to 021000021-1234567890"
-> ```
-
-## Expected Response
-
-### PII Detection Report
-
-#### Findings Summary
-
-| # | Log Line | PII Type | Sensitivity | Severity |
-|---|----------|----------|-------------|----------|
-| 1 | UserController | Email, full name, date of birth | High | High |
-| 2 | PaymentService | Full credit card number, expiration | Critical | Critical |
-| 3 | AuthService | Plaintext password | Critical | Critical |
-| 4 | OrderService | Physical address | Medium | Medium |
-| 5 | APIGateway | IP address, API key | Medium | Medium |
-| 6 | SupportBot | SSN, full name, bank routing + account number | Critical | Critical |
-
----
-
-#### Finding 1: User Registration Log (HIGH)
-
-**Location:** `[UserController]` — user registration flow
-
-**PII detected:**
-- Email address: `sarah.jones@company.com`
-- Full name: `Sarah Jones`
-- Date of birth: `1990-05-15`
-
-**Risk:** Email + name + DOB is sufficient for identity theft and social engineering. Violates GDPR data minimization principle.
-
-**Remediation:**
-```javascript
-// BEFORE (leaking PII)
-logger.info(`User registered: email=${user.email}, name=${user.name}, DOB=${user.dob}`);
-
-// AFTER (redacted)
-logger.info(`User registered: user_id=${user.id}`);
-```
-
-Log only the internal user ID. If email is needed for debugging, use a truncated hash: `email_hash=${sha256(user.email).slice(0,8)}`.
-
----
-
-#### Finding 2: Credit Card in Payment Log (CRITICAL)
-
-**Location:** `[PaymentService]` — payment processing
-
-**PII detected:**
-- Full credit card number: `4532015112830366`
-- Expiration date: `12/26`
-
-**Risk:** This is a PCI DSS violation. Logging full card numbers can result in fines up to $500,000 per incident and loss of payment processing privileges.
-
-**Remediation:**
-```javascript
-// BEFORE (PCI violation)
-logger.debug(`Charging card ${cardNumber} exp ${expiry} for user_id=${userId}`);
-
-// AFTER (PCI compliant)
-logger.debug(`Charging card ending ${cardNumber.slice(-4)} for user_id=${userId}`);
-```
-
-Additionally, change log level from DEBUG to INFO for payment events and never log expiration dates.
-
----
-
-#### Finding 3: Plaintext Password in Auth Log (CRITICAL)
-
-**Location:** `[AuthService]` — authentication flow
-
-**PII detected:**
-- Plaintext password: `P@ssw0rd123`
-
-**Risk:** Passwords must never be logged under any circumstances. If logs are compromised, all passwords logged this way are exposed. This also violates every security compliance framework.
-
-**Remediation:**
-```javascript
-// BEFORE (catastrophic)
-logger.error(`Failed login: username=${username}, password=${password}, IP=${ip}`);
-
-// AFTER (safe)
-logger.warn(`Failed login attempt: username=${username}, IP=${ip}`);
-```
-
-Remove the password parameter entirely from all logging code paths. Add a log sanitizer that blocks any field named `password`, `passwd`, `secret`, or `token`.
-
----
-
-#### Finding 4: Physical Address (MEDIUM)
-
-**Location:** `[OrderService]` — shipping flow
-
-**Remediation:** Log only order ID and shipping status. If address debugging is needed, log city/state only.
-
-#### Finding 5: IP Address and API Key (MEDIUM)
-
-**Location:** `[APIGateway]` — rate limiting
-
-**Remediation:** IP addresses are PII under GDPR. Hash or truncate IPs in logs. Redact the API key to last 4 characters.
-
-#### Finding 6: SSN and Bank Account (CRITICAL)
-
-**Location:** `[SupportBot]` — ticket ingestion
-
-**Remediation:** Implement PII scrubbing on all free-text input before logging. Use regex patterns to detect and redact SSN, bank account numbers, and credit card numbers from support ticket bodies before they reach the logging pipeline.
-
----
-
-### Systematic Remediation Plan
-
-**1. Build a centralized log sanitizer middleware:**
-```javascript
-const PII_PATTERNS = {
-  ssn: /\b\d{3}-\d{2}-\d{4}\b/g,
-  credit_card: /\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b/g,
-  email: /\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b/g,
-  bank_account: /\b\d{9}-\d{7,17}\b/g,
-};
-
-function sanitizeLog(message) {
-  let sanitized = message;
-  for (const [type, pattern] of Object.entries(PII_PATTERNS)) {
-    sanitized = sanitized.replace(pattern, `[REDACTED:${type}]`);
-  }
-  return sanitized;
-}
-```
-
-**2. Add pre-commit PII scanning** using `detect-secrets` or a custom regex scanner.
-
-**3. Configure structured logging** so PII fields can be programmatically redacted rather than relying on string matching.
-
-**4. Audit all existing log statements** across all services for PII exposure patterns.

package/workflows/skills/sanitize-pii/examples/02-gdpr-data-masking-strategy.md

@@ -1,204 +0,0 @@
-# Example 2: GDPR-Compliant Data Masking for Staging Environment
-
-## User Prompt
-
-> Design a GDPR-compliant data masking strategy for our staging database. Schema:
->
-> ```sql
-> CREATE TABLE customers (
->   id SERIAL PRIMARY KEY,
->   email VARCHAR(255) UNIQUE NOT NULL,
->   first_name VARCHAR(100),
->   last_name VARCHAR(100),
->   phone VARCHAR(20),
->   date_of_birth DATE,
->   national_id VARCHAR(20),
->   address TEXT
-> );
->
-> CREATE TABLE medical_records (
->   id SERIAL PRIMARY KEY,
->   customer_id INT REFERENCES customers(id),
->   diagnosis TEXT,
->   treatment TEXT,
->   doctor_notes TEXT,
->   created_at TIMESTAMP
-> );
->
-> CREATE TABLE payments (
->   id SERIAL PRIMARY KEY,
->   customer_id INT REFERENCES customers(id),
->   card_last_four VARCHAR(4),
->   amount DECIMAL(10,2),
->   billing_address TEXT
-> );
-> ```
->
-> We have 200,000 customer records. Staging must be realistic for QA testing but contain zero real PII. We serve EU customers.
-
-## Expected Response
-
-### GDPR-Compliant Data Masking Strategy
-
-#### Regulatory Context
-
-Under GDPR, copying production personal data to non-production environments without a lawful basis violates:
-- **Article 5(1)(b)** — Purpose limitation (staging is not the original collection purpose)
-- **Article 5(1)(c)** — Data minimization (full production data exceeds what testing requires)
-- **Article 25** — Data protection by design and by default
-
-The masking strategy must ensure that masked data cannot be re-identified, even when combined across tables.
-
-#### Field Classification and Masking Rules
-
-**customers table:**
-
-| Field | PII Type | Sensitivity | Masking Strategy | Example |
-|-------|----------|-------------|------------------|---------|
-| id | Pseudoidentifier | Low | Preserve (FK integrity) | 12345 → 12345 |
-| email | Direct identifier | High | Format-preserving synthetic | sarah.jones@gmail.com → user_12345@masked.test |
-| first_name | Direct identifier | High | Faker-generated, locale-aware | Sarah → Emilia |
-| last_name | Direct identifier | High | Faker-generated, locale-aware | Jones → Bergström |
-| phone | Direct identifier | High | Format-preserving random | +44 20 7946 0123 → +44 20 7946 9876 |
-| date_of_birth | Quasi-identifier | Medium | Year-preserving randomization | 1990-05-15 → 1990-08-22 |
-| national_id | Direct identifier | Critical | Full replacement | AB123456C → XX000000X |
-| address | Direct identifier | High | Faker-generated, same country | 42 Oxford St, London → 17 Elm Road, Bristol |
-
-**medical_records table:**
-
-| Field | PII Type | Sensitivity | Masking Strategy |
-|-------|----------|-------------|------------------|
-| id | Internal key | Low | Preserve (FK integrity) |
-| customer_id | Reference | Low | Preserve (matches masked customer) |
-| diagnosis | Special category (Art. 9) | Critical | Replace with synthetic medical terms from codebook |
-| treatment | Special category (Art. 9) | Critical | Replace with synthetic treatment descriptions |
-| doctor_notes | Free-text with embedded PII | Critical | Full replacement with synthetic clinical notes |
-| created_at | Temporal | Low | Preserve (needed for testing time-based logic) |
-
-**payments table:**
-
-| Field | PII Type | Sensitivity | Masking Strategy |
-|-------|----------|-------------|------------------|
-| id | Internal key | Low | Preserve |
-| customer_id | Reference | Low | Preserve (matches masked customer) |
-| card_last_four | Partial identifier | Medium | Random 4 digits |
-| amount | Financial | Low | Preserve (needed for testing calculations) |
-| billing_address | Direct identifier | High | Faker-generated, same country as customer |
-
-#### Implementation: Masking Pipeline
-
-```python
-# masking_pipeline.py — using Faker for synthetic data generation
-
-from faker import Faker
-import hashlib
-import psycopg2
-import json
-
-fake = Faker(['en_GB', 'de_DE', 'fr_FR', 'es_ES'])  # EU locales
-
-def deterministic_seed(original_value, salt):
-    """Ensure same input always produces same masked output
-    for referential integrity across tables."""
-    return int(hashlib.sha256(f"{salt}:{original_value}".encode()).hexdigest()[:8], 16)
-
-def mask_customer(row, salt):
-    seed = deterministic_seed(row['email'], salt)
-    fake.seed_instance(seed)
-
-    return {
-        'id': row['id'],  # preserve for FK integrity
-        'email': f"user_{row['id']}@masked.test",
-        'first_name': fake.first_name(),
-        'last_name': fake.last_name(),
-        'phone': fake.phone_number(),
-        'date_of_birth': row['date_of_birth'].replace(
-            month=fake.random_int(1, 12),
-            day=fake.random_int(1, 28)
-        ),
-        'national_id': f"XX{fake.random_int(100000, 999999)}X",
-        'address': fake.address(),
-    }
-
-def mask_medical_record(row, salt):
-    seed = deterministic_seed(str(row['id']), salt)
-    fake.seed_instance(seed)
-
-    synthetic_diagnoses = [
-        "Condition Type A - Grade 2",
-        "Condition Type B - Mild",
-        "Condition Type C - Under observation",
-    ]
-    synthetic_treatments = [
-        "Standard treatment protocol Alpha",
-        "Medication regimen Beta - 30 day course",
-        "Monitoring protocol Gamma - quarterly review",
-    ]
-
-    return {
-        'id': row['id'],
-        'customer_id': row['customer_id'],  # FK preserved
-        'diagnosis': fake.random_element(synthetic_diagnoses),
-        'treatment': fake.random_element(synthetic_treatments),
-        'doctor_notes': f"Synthetic clinical note: {fake.paragraph(nb_sentences=3)}",
-        'created_at': row['created_at'],  # preserve timestamps
-    }
-```
-
-#### Referential Integrity Guarantees
-
-- **Customer IDs are preserved** — all FK references in `medical_records` and `payments` remain valid
-- **Deterministic seeding** — running the pipeline twice on the same data produces identical masked output
-- **Cross-table consistency** — a customer's masked name is the same whether accessed via `customers` or joined through `payments`
-
-#### Free-Text Field Handling
-
-Free-text fields (`doctor_notes`, `diagnosis`, `treatment`, `billing_address`) require special attention:
-
-1. **Simple replacement** (recommended for staging): Replace entire text with synthetic content. Fastest and most reliable.
-2. **NLP-based entity recognition**: Use spaCy or Presidio to detect and replace named entities within the text. Preserves structure but risk of missed entities.
-3. **Template-based generation**: Create domain-specific templates and fill with synthetic data. Good balance of realism and safety.
-
-**Recommendation for medical records:** Use full replacement (option 1) because medical free text often contains patient names, family member names, and location references that NER may miss.
-
-#### Pipeline Execution
-
-```bash
-# 1. Snapshot production database (encrypted, access-logged)
-pg_dump -h prod-db.internal -U readonly -Fc appdb > /secure-tmp/prod_snapshot.dump
-
-# 2. Restore to isolated masking environment (no network access to production)
-pg_restore -h masking-db.internal -U admin -d masking_appdb /secure-tmp/prod_snapshot.dump
-
-# 3. Run masking pipeline
-python masking_pipeline.py --source masking_appdb --target staging_appdb --salt $(openssl rand -hex 16)
-
-# 4. Validate: assert no real PII remains
-python validate_masking.py --db staging_appdb --original-emails /secure-tmp/original_emails.hash
-
-# 5. Delete production snapshot
-shred -u /secure-tmp/prod_snapshot.dump
-```
-
-#### Validation Checks
-
-After masking, run these automated assertions:
-
-- No email in staging matches any production email
-- No phone number in staging matches any production phone
-- No national_id in staging matches any production national_id
-- No doctor_notes contain any production customer name
-- All FK relationships remain valid
-- Row counts match between production and staging
-- Amount distributions are statistically similar (for realistic testing)
-
-#### GDPR Compliance Checklist
-
-- [x] No direct identifiers in staging environment
-- [x] Quasi-identifiers randomized to prevent re-identification
-- [x] Special category data (medical) fully replaced
-- [x] Free-text fields fully replaced (not pattern-masked)
-- [x] Masking is irreversible (no mapping table stored)
-- [x] Production snapshot deleted after masking
-- [x] Audit trail of masking pipeline execution
-- [x] Documented in DPIA (Data Protection Impact Assessment)