Skip to main content

Track O: Operations & Compliance

Progress: 0/32 tasks complete (0%)

Operations and compliance tasks derived from SDD Section 11 (Security Requirements), Section 14 (Operational Requirements), and the security requirements table (SR-01 through SR-08). These tasks ensure the security layer is deployable, auditable, and mappable to compliance frameworks.

Status Summary​

SectionDoneTotalStatus
O.1 Deployment Configuration011Pending
O.2 SOC 2 Evidence Collection012Pending
O.3 OWASP LLM Top 10 Mapping09Pending

O.1 Deployment Configuration​

Production deployment setup for all security layer components following SDD Section 14.1 and 14.2.

  • O.1.1 Create config/security-gate.default.yaml — default configuration with all values from SDD Section 14.2: fail_mode: closed, scan_timeout_ms: 500, max_input_bytes: 1048576, circuit breaker thresholds (failure_threshold: 5, failure_window_seconds: 60, cooldown_seconds: 30), audit retention days per event type
  • O.1.2 Register SecurityGateHook in CODITECT hook system — add entry to settings.local.json H.P.005-HOOKS section; PreToolUse with matcher "*" and priority 100 (before all other hooks); PostToolUse with matcher "Bash|Write|Edit|WebFetch|Task" and priority 10; PreAgentStart with priority 100
  • O.1.3 Configure security-gate.manifest.json — hook manifest with all three event registrations, handler paths, timeout_ms, blocking: true; stored at hooks/security-gate/security-gate.manifest.json
  • O.1.4 Configure migrate_security_schema.py deployment step — run schema migration script before hook activation; creates four new tables in org.db; idempotent (safe to re-run); validates table creation with SELECT COUNT(*) FROM sqlite_master WHERE type='table' AND name='security_audit_events'
  • O.1.5 Configure MonitorDashboard as systemd service or LaunchAgent — ai.coditect.security-dashboard.plist for macOS (matching coditect-context-watch daemon pattern); systemd unit for Linux deployments; process supervisor auto-restart on crash (RTO: 60s per SDD Section 14.4)
  • O.1.6 Configure AlertDispatcher webhook integrations — per-tenant webhook URL configuration in tenant_security_configs.alert_webhooks; support Slack, Discord, PagerDuty formats per SDD Section 3.5; validate webhook reachability on config save
  • O.1.7 Extend backup-context-db.sh to include security.db — add ~/.coditect-data/context-storage/security.db to the existing backup routine that pushes to gs://coditect-cloud-infra-context-backups; security JSONL file (~/.coditect-data/security/events.jsonl) also backed up as canonical event log
  • O.1.8 Configure get_security_db_path() in scripts/core/paths.py — returns get_coditect_data_path() / "context-storage" / "security.db"; consistent with ADR-118 database architecture; security.db is regenerable (JSONL is canonical)
  • O.1.9 Configure per-environment policy files — config/security-gate.production.yaml (fail_mode: closed, all checks enabled, webhook alerts active), config/security-gate.development.yaml (fail_mode: open, audit mode, no webhooks, extended logging)
  • O.1.10 Document disaster recovery procedures per SDD Section 14.4 — MonitorDashboard crash (60s RTO, process supervisor restarts); org.db corruption (4h RTO, restore from GCS backup); rule file corruption (15min RTO, git checkout HEAD -- hooks/security-gate/rules/); complete SecurityGateHook failure (blocks all tools by design, bypass requires explicit admin action + audit log entry)
  • O.1.11 Validate production deployment checklist — verify all eight functional security requirements from SDD Section 11.1 are satisfied: SR-01 (all tool calls intercepted), SR-02 (CRITICAL always BLOCKs), SR-03 (secrets redacted from outputs), SR-04 (fail-closed default), SR-05 (100% audit coverage), SR-06 (kill switch 5s SLA), SR-07 (tamper-evident audit log), SR-08 (tenant data isolated in all queries)

O.2 SOC 2 Evidence Collection​

Evidence artifacts and controls required for SOC 2 Type II audit coverage. Each item produces a concrete artifact that can be submitted to auditors.

  • O.2.1 Document audit log retention policy — formal written policy specifying retention periods per event type: TOOL_BLOCKED/TOOL_REDACTED/SCAN_FAILED/AGENT_START_BLOCKED/TENANT_OVERRIDE: 1 year; TOOL_WARNED: 90 days; TOOL_ALLOWED: 30 days; KILL_SWITCH_ACTIVATED: 5 years; reference SDD Section 3.6 and config/security-gate.default.yaml
  • O.2.2 Configure tamper-evident audit log — enable SQLite WAL mode on org.db; document NO UPDATE/DELETE grant policy on security_audit_events table; write ADR documenting decision to use org.db (irreplaceable database) for security audit records per SDD Section 1.4
  • O.2.3 Implement audit export endpoint for SOC 2 evidence — GET /api/v1/security/export?format=ndjson&from_ts=...&to_ts=...; produces complete event records with all AuditEvent fields per SDD Section 5.2 OpenAPI schema; validate export includes all required fields: event_id, event_type, timestamp, tenant_id, session_id, action_taken, risk_score, reasoning, matched_rule_ids, scan_duration_ms
  • O.2.4 Document access control for security events — only authenticated users with security:read role can call GET /api/v1/security/events; only users with security:admin + MFA can call POST /api/v1/security/gateway/{tenant_id}/kill; document role assignments and authorization enforcement code paths
  • O.2.5 Document secret non-logging policy — formal policy: matched text and evidence snippets NEVER appear in application logs or metrics; only rule_ids and primary_threat category appear in log lines; security_audit_events.reasoning stores sanitized description, not raw matched text; write test T.3.5 as automated evidence
  • O.2.6 Implement monitoring alert evidence — configure alerts from SDD Section 9.2 with documented conditions, severity, and routing: SecurityGateCircuitOpen (PagerDuty, CRITICAL), SecurityGateAuditDbDown (PagerDuty, CRITICAL), SecurityGateScanTimeout (Slack, HIGH), SecurityGateHighBlockRate (Slack + tenant webhook, HIGH), SecurityGateKillSwitchUsed (PagerDuty + all tenant admins, HIGH)
  • O.2.7 Document incident response runbook — formalize the three SDD Section 14.3 runbook procedures into a standalone operations document: SecurityGateCircuitOpen, SecurityGateAuditDbDown, SecurityGateHighBlockRate; include escalation paths, resolution SLAs, post-incident review requirements
  • O.2.8 Document change management for security rules — all rule changes must be made via pull request to hooks/security-gate/rules/; PR must include test fixtures for new rules (positive and negative cases); review required from security track lead; changes can be rolled back via git revert; this process is the Change Management control for SOC 2 CC8.1
  • O.2.9 Document encryption at rest policy — if org.db encryption is enabled, security_audit_events.reasoning is encrypted at rest; document whether encryption is enabled in current deployment; document key management approach (matches existing org.db encryption posture per ADR-118)
  • O.2.10 Create SOC 2 control mapping table — map each of the eight functional security requirements (SR-01 through SR-08) to SOC 2 Trust Service Criteria; expected mappings: SR-01/SR-04 → CC7.1 (threat detection), SR-05/SR-07 → CC7.2 (audit logging), SR-02/SR-03 → CC7.3 (boundary protection), SR-06 → CC7.4 (incident response), SR-08 → CC6.6 (logical access)
  • O.2.11 Generate initial audit export for baseline evidence — run export for 30-day period post-launch; validate NDJSON output contains all required fields; store as baseline evidence artifact in internal/compliance/soc2-evidence/
  • O.2.12 Document security layer availability SLA — 99.9% hook availability per SDD Section 11.2; document measurement method (hook invocation success rate from security_gate_tool_calls_total metric); document what constitutes an availability incident (circuit breaker OPEN for > 5 minutes)

O.3 OWASP LLM Top 10 Mapping​

Explicit mapping of security layer controls to the OWASP Top 10 for Large Language Model Applications (2025 edition). Each item documents coverage or acknowledged gap.

  • O.3.1 LLM01 — Prompt Injection: document coverage — PatternEngine rules PI-001 through PI-010 directly address direct and indirect prompt injection; PreToolUse hook intercepts injection attempts before tool execution; PreAgentStart hook catches system prompt injection at session initialization; coverage: STRONG
  • O.3.2 LLM02 — Sensitive Information Disclosure: document coverage — PostToolUse output scanner applies SD-* and PII-* rules to all tool outputs before returning to agent context; secrets replaced with [REDACTED:<rule_id>] tokens; matched text never written to logs (SR-05 / T.3.5); coverage: STRONG
  • O.3.3 LLM03 — Supply Chain Vulnerabilities: document coverage — lauty1505/clawguard trojanized fork detected and excluded during research phase; all three retained repos are MIT-licensed and code-reviewed; pattern YAML files are version-controlled with PR review gate (O.2.8); ongoing gap: no automated dependency scanning for transitive Python dependencies in security layer venv
  • O.3.4 LLM04 — Data and Model Poisoning: document gap and partial coverage — PatternEngine PI rules detect attempts to inject new instructions into agent context via tool inputs; system prompt injection blocked by PreAgentStart hook; gap: no detection of long-term context poisoning via org.db manipulation or session log injection; document as known gap for future sprint
  • O.3.5 LLM05 — Improper Output Handling: document coverage — PostToolUse scanner validates all tool output content before it is returned to agent; PII and secrets redacted; structured output validation (Pydantic models) ensures AuditEvent fields are typed; coverage: MODERATE (covers secret/PII leakage; does not cover XSS or injection in UI rendering of agent output)
  • O.3.6 LLM06 — Excessive Agency: document coverage — DC-* destructive command rules explicitly block irreversible operations (rm -rf /, DROP TABLE, mkfs, dd, disk format); CONFIRM action for MEDIUM-severity detections requires human approval before execution; kill switch provides emergency halt for entire tenant; coverage: STRONG for known destructive patterns; gap: novel chained tool call sequences not covered by current static patterns
  • O.3.7 LLM07 — System Prompt Leakage: document coverage — PI-H-002 (system_prompt_reveal) pattern detects attempts to reveal system prompt via tool calls; PreAgentStart hook scans system prompt itself for injected reveal instructions; coverage: MODERATE; gap: no detection of gradual information extraction via multiple low-risk tool calls that individually do not trigger patterns
  • O.3.8 LLM08 — Vector and Embedding Weaknesses: document gap — current security layer operates on tool call inputs/outputs (text layer); does not inspect embedding vectors or similarity search results; no coverage for adversarial embedding attacks or data poisoning via vector store; document as out-of-scope for current implementation; note as future track item
  • O.3.9 LLM09 — Misinformation: document gap — current security layer does not evaluate factual accuracy of agent outputs; this is a model-level concern handled by Anthropic/LLM providers per SDD Section 2.2 (out of scope); document that misinformation detection is explicitly excluded from scope; reference SDD Section 2.2 for boundary rationale