Last Updated: 2026-03-05
Status: ACCEPTED
Owner: Security Engineering

Defines mandatory controls for secrets, access, route protection, and auditability across all SIN-Solver deployments.

Reference certificate name (internal artifact): "SIN-Solver / Platform-Registry: Certificate of First-Party Ownership & Operational Control". The enforcement input for domain allowlisting and platform metadata is config/platforms-registry.json.

• SSOT: config/platforms-registry.json is the only machine-enforced source used for allowlisting and policy decisions.
• platform_id naming:
  • Runtime platform ids must match the code (services/.../survey-platforms.js and handlers). Example: dataannotation (not dataannotation-tech).
  • Any legacy ids that appear in screenshots/certificates are documentation-only labels unless explicitly supported in code.
• ownership_scope meaning: first-party platform inventory is the only accepted source.
• first_party: internal inventory classification tracked in config/platforms-registry.json; external terms and compliance gates still apply.
• Blacklisted platforms and domains in the registry must be denied by launcher and network policy even if legacy code paths remain in the repo.

• Store secrets ONLY in approved secret stores or protected .env files
• NEVER commit plaintext credentials, tokens, or private keys to version control
• Rotate high-value credentials on incident or quarterly cadence
• Redact secret-like fields in logs and API error payloads

• Environment variables (.env files - NOT committed to git)
• HashiCorp Vault (for production secrets)
• Cloud provider secret managers (AWS Secrets Manager, GCP Secret Manager)

• ❌ Hardcoded API keys in source code
• ❌ Committed .env files
• ❌ Plaintext passwords in configuration files
• ❌ Tokens in version control history

Some legacy non-root documentation previously included speculative "bypass" narratives. This repo is a production codebase and must remain compliant:

• We do not implement, document, or endorse identity/KYC bypass, credential theft, or unauthorized access.
• Any security testing notes must stay defensive: threat modeling, detection awareness, logging, allowlisting, and auditability.
• Operator documentation should focus on verifiable service contracts and safe operational controls.

• Enforce least privilege for all runtime services and VM tenants
• Each persona (jeremy/gina/simone/markus/rico) has isolated credentials
• No cross-persona access without explicit authorization

• Restrict network egress to approved domains and providers:
  • *.iproyal.com (proxy provider)
  • outlier.ai, dataannotation.tech (allowlisted worker platforms)
  • prolific.com (survey platform)
  • api.nvidia.com (NIM inference)
  • api.anthropic.com (Claude fallback)
  • generativelanguage.googleapis.com (Gemini fallback)
• Block all other outbound traffic by default

• Require authenticated access for all mutating control routes
• Platform login credentials stored per persona
• Session tokens encrypted at rest

• SIN-Authenticator/authd is the only approved issuer for workflow-scoped, subject-scoped, and executor-scoped grants in the alpha backbone.
• Every grant must bind to tenant_id, team_id, optional run_id, and a concrete subject_scope.
• Grant lifecycle is mandatory: issue, refresh, expire, revoke, and audit events must be recorded in the control plane.
• HF executors must reacquire scoped grants after restart; no long-lived broad bearer tokens may be stored as workflow truth on VM-local disk.
• Approval decisions must enforce execution through grant state and workflow state together; approval metadata alone is insufficient.

• High-risk state changes require valid X-HITL-TOKEN
• Missing/invalid token must return explicit policy denial (HTTP 403)
• Token validation paths must be covered by automated tests

• Account registration changes
• Proxy configuration updates
• Payment method modifications
• Platform credential updates
• Worker start/stop/restart commands

• Tokens generated per deployment environment
• 24-hour expiration for session tokens
• Immediate revocation on security incident
• Alpha backbone executor grants should default to short TTLs and rotate per workflow/run boundary whenever practical.

• Run vulnerability scans in CI for:
  • Python dependencies (pip-audit, safety)
  • Node.js dependencies (npm audit, yarn audit)
  • System packages (Trivy, Clair)
  • Docker images (Trivy)

• Pin workflow actions to specific SHA hashes
• Pin critical runtime dependencies to exact versions
• Document exception waivers with:
  • Owner name
  • Justification
  • Expiry date

• Verify package signatures where available
• Use lockfiles (requirements.txt, package-lock.json, yarn.lock)
• Monitor for compromised packages (Snyk, Dependabot)

• Preserve forensic logs for:
  • Worker actions (task start, completion, failure)
  • Policy decisions (accept, deny, rate limit)
  • Authentication events (login, logout, token refresh)
  • Configuration changes (proxy, credentials, platform)

{
  "timestamp": "2026-03-05T12:34:56Z",
  "level": "INFO",
  "event": "TASK_COMPLETION",
  "persona": "jeremy",
  "platform": "outlier",
  "task_id": "abc123",
  "value_earned": 2.45,
  "duration_ms": 568,
  "trace_id": "uuid-v4"
}

• Keep NotebookLM evidence artifacts synced for governance audits
• Screenshots of task completion (for earnings verification)
• Telemetry DB (runtime-telemetry.sqlite3) - DO NOT DELETE

• Every production-relevant change must have a lastchanges.md entry
• Use conventional commits (feat:, fix:, security:)
• Link commits to issues/tasks

• Assessment answers: NIM-assisted drafts, human-reviewed before submission
• No automated submission during assessment phase
• Credentials: Per-persona email/password

• UK profiles ONLY (DE on waitlist)
• Payment: Wise GB-IBAN required
• 2FA: Manual SMS interception (no automation)

• One proxy per persona (no sharing)
• Sticky sessions (24h rotation)
• IP verification before each session
• Automatic failover on proxy failure

1. STOP all worker operations immediately
2. ISOLATE affected VM/persona
3. ROTATE all exposed credentials
4. PRESERVE forensic evidence (logs, telemetry)
5. NOTIFY security team via Telegram
6. DOCUMENT incident in SECURITY.md

# Rotate all credentials
./scripts/rotate_credentials.sh --persona jeremy --all

# Rotate specific credential
./scripts/rotate_credentials.sh --persona jeremy --platform outlier

# Extract logs for persona
sqlite3 output/runtime-telemetry.sqlite3 \
  "SELECT * FROM execution_logs WHERE persona='jeremy' ORDER BY timestamp DESC LIMIT 100;"

# Check for anomalies
grep -r "ERROR\|WARN\|SECURITY" output/worker_jeremy.log

• All proxies active and healthy
• No credential leaks in logs
• Telemetry DB integrity verified
• Telegram alerts functional

• Vulnerability scan report reviewed
• Dependency updates applied
• Access logs reviewed
• Certificate expiration monitored

• High-value credentials rotated
• Security baseline reviewed
• Penetration test results reviewed
• Compliance audit completed

• Primary: Security Engineering Team
• Escalation: Platform Infrastructure Lead
• Emergency: Telegram bot alerts
• Audit: Governance Team

Source: Migrated from 03_INFRASTRUCTURE/SECURITY.md
Related: ENVIRONMENT.md, DEPLOYMENT.md, knowledge.md