We built a SOC 2 reviewer for AI sessions, and kept AI out of the execution path

The developer team behind Chron, an MCP server that records AI coding sessions to a local SQLite database, has shipped a SOC 2 review layer. The tool scans session history for findings against SOC 2 Trust Services Criteria using pure pattern matching, without any model inference or API calls. It generates reports with severity ratings and stable finding IDs, and supports actions like accept, dismiss, and resolve to manage findings over time.

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.