# We built a SOC 2 reviewer for AI sessions, and kept AI out of the execution path > Source: > Published: 2026-07-09 20:26:55+00:00 We built a SOC 2 reviewer for AI sessions — and kept AI out of the execution path AI coding tools now touch auth code, modify Terraform, handle credentials, and change deployment pipelines. Most teams have no record of this. For teams under SOC 2, that gap is becoming a real problem. We built [Chron](https://www.npmjs.com/package/chron-mcp) to fix the audit trail problem. Today we're shipping the review layer. Chron is an MCP server. It sits in every AI conversation and records structured events to a local SQLite database: `code_change` — file path, operation (create/edit/delete), diff`tool_call` / `tool_result` — what tools the AI invoked`secret_detected` — masked credential or PII (no plaintext stored)Every message is hash-chained. Sessions can be Ed25519 signed. Nothing leaves the machine. After a few weeks of use you have a tamper-evident history of everything your AI coding assistant did. ``` chron review --framework=soc2 ``` This scans your session history and flags findings against SOC 2 Trust Services Criteria. No model inference. No API calls. Pure pattern matching on the structured events Chron already captured. Sample output: ``` Chron Review SOC2 162 session(s) reviewed 7 findings across 2 controls This report identifies AI-session evidence that may require control-owner review. It is not a certification of compliance or evidence of any violation. CRITICAL CC6.1, CC6.6 e252bc5e SIEM integrations sprint A sensitive credential or secret was detected in an AI session. • secret_detected: env_value (SPLU****oken) • secret_detected: password (PASS****234!) Suggested: Confirm no plaintext credential was committed to version control HIGH CC6.1 12b9bc1e Auth refactor — JWT migration AI modified code in an access-control-sensitive path. • code_change: src/auth/jwt.ts • code_change: src/auth/session.ts Suggested: PR approval with human reviewer ``` Severity is per secret type — `private_key` and `credit_card` are critical, API keys are high, email addresses are medium. Not everything Chron detects warrants the same response. ``` chron review --framework=soc2 --since=30d ``` Useful for quarterly reviews or pre-audit prep. The `--since` flag accepts `7d` , `30d` , or `YYYY-MM-DD` . ``` chron review --framework=soc2 --output=review.html ``` Generates a printable HTML report with finding cards, severity badges, evidence lists, and suggested review actions. The disclaimer is on the cover page — it is not a compliance certification. Findings have stable IDs across runs (SHA-256 of rule + session). The default view shows only open findings. You act on them as you review: ``` # Accept — reviewed, risk accepted chron review accept abc12345 --note="approved by security team, PR #441" # Dismiss — not applicable chron review dismiss abc12345 --note="test fixture, not production code" # Resolve — evidence gathered chron review resolve abc12345 --note="credential rotated, no commit exposure" # See everything including reviewed findings chron review --all ``` Next time you run `chron review` , accepted and dismissed findings don't reappear as noise. New findings — from sessions since your last review — surface cleanly. The obvious question: why not just ask Claude "is this a SOC 2 violation?" Two reasons. First, it would overclaim. A model asked "does this violate CC6.1?" will give you a confident-sounding answer. That answer is not evidence. A licensed CPA conducting a SOC 2 Type II examination needs to evaluate whether your controls were *suitably designed and operated effectively over the audit period* — a judgment call that requires sampling, period evidence, and professional opinion. No model output replaces that. Second, you can't audit an AI's reasoning. If a model decides a finding is real or dismissed, there's no inspectable rule to challenge. Human-designed rules are reviewable, editable, and arguable. If the `auth` path keyword fires on a test fixture you don't care about, you can dismiss it with a note. If the rule is wrong, you can open an issue. The constraint that keeps this trustworthy: **AI explains, never decides.** Rules execute deterministically. AI will eventually help generate evidence narratives and answer questions about your session history — but the findings themselves come from rules a human can read and reason about. | Rule | Controls | What triggers it | |---|---|---| | Access control code | CC6.1 | `code_change` to auth/iam/rbac/jwt/oauth paths | | Credential detected | CC6.1, CC6.6 | Any `secrets_detected` entry | | Infrastructure change | CC7.2, CC8.1 | `code_change` to terraform/k8s/docker/pipeline paths | | Monitoring change | CC7.2 | `code_change` to logging/monitoring/alerting paths | | Data handling change | CC6.1, CC6.7 | `code_change` to encryption/gdpr/retention paths | `chron ask "which sessions touched auth code last quarter?"` — natural language over the audit DB ``` npm install -g chron-mcp ``` Add the MCP server to Claude Code, Cursor, Windsurf, or any MCP-compatible tool. Run `chron doctor` to verify setup. Start a session. Then: ``` chron review --framework=soc2 ``` 4,107 installs. If you're dealing with AI governance questions in your SOC 2 audit, I'd like to hear what you're seeing.