DEV Community

Srinivas Kondepudi
Srinivas Kondepudi

Posted on

From AI logger to AI governance layer, what 5,600 downloads taught us about Chron

#ai #security #devtools #audit

ChronWhen we shipped Chron six months ago, the pitch was simple: every AI conversation should leave a timestamped, tamper-evident record. Developers installing AI coding tools had no answer to the question "what did the AI actually do?" Chron was that answer.

5,600 installs later, the question has changed.

It's no longer "did we log it?" — most teams using Chron have solved that. The new question is: which sessions should I look at first?

That question is harder, and it's where Chron is heading next.

What Chron does today

Chron is an MCP server that runs locally alongside Claude Code, Cursor, Windsurf, and Codex. Every message, every file change, every tool call gets logged to a local SQLite database with a precise timestamp and a tamper-evident hash chain.

chron history
Enter fullscreen mode Exit fullscreen mode 
8f3a7c9e  claude-code  API refactor         2026-07-19  14 events
b91c2a11  cursor        Contract review       2026-07-18  8 events
3d0a5f22  claude-code  Auth middleware fix   2026-07-17  31 events
Enter fullscreen mode Exit fullscreen mode 
chron verify 8f3a
# ✓ hash chain intact — 14 events, no tampering detected
Enter fullscreen mode Exit fullscreen mode

On top of that, chron review runs a deterministic compliance analysis across four frameworks:

  • SOC 2 — access control changes, secret exposure, infrastructure modifications
  • ISO 27001 — cryptography changes, access management, incident handling
  • EU AI Act — risk management, data governance, human oversight
  • NIST AI RMF — AI policy changes, model evaluation, incident response 
chron review --framework=soc2 --output=evidence.html
Enter fullscreen mode Exit fullscreen mode

The output is a printable HTML evidence package — not a compliance opinion, but session evidence a control owner can actually use.

The coverage map: honest about what Chron sees

One of the things we deliberately got right: Chron doesn't claim to "cover" a framework. It covers specific controls that are observable from AI session activity. Everything else — policy documentation, physical access, contractual obligations — requires evidence from other sources.

chron review --framework=nist-ai-rmf --full-map
Enter fullscreen mode Exit fullscreen mode 
NIST AI RMF — Full Control Coverage Map

  Covered by session evidence (12)
  ────────────────────────────────
  GOVERN 1.1   AI policy and governance changes    rule: nist-ai-rmf.govern.ai_policy_change
  MAP 3.5      Sensitive data in AI sessions       rule: nist-ai-rmf.map.sensitive_data_in_session
  MEASURE 2.7  AI monitoring modifications         rule: nist-ai-rmf.measure.ai_monitoring_change
  ...

  Needs additional evidence (28)
  ────────────────────────────────
  GOVERN 2.1   Organizational roles defined        source: policy_docs
  MAP 2.2      Scientific findings documented      source: policy_docs
  ...

  Manual review required (18)
  ────────────────────────────────
  GOVERN 3.1   Feedback mechanisms in place        human judgement required
  ...

  Out of scope (8)
  ────────────────────────────────
  GOVERN 5.2   Organizational policies current     not observable from session logs
Enter fullscreen mode Exit fullscreen mode

66 NIST AI RMF subcategories. 12 covered by Chron session evidence. 54 classified honestly. The disclaimer at the top of every report: "Covered does not mean compliant."

What's coming next: Attention Score

At 5,600 installs, the missing piece is triage.

When you have 200 sessions logged, you don't need a list — you need a signal. Which of these sessions involved something worth a second look?

The next release adds an Attention Score to every session: a deterministic 0–100 score computed from three signal categories.

Secret exposure — was a credential, API key, or token detected in the session? (+30)

Sensitive code changes — did the AI modify auth, production config, infrastructure, or AI oversight code? (up to +30, based on path patterns)

Open compliance findings — does this session have unresolved findings from chron review? Severity-weighted, capped at +30.

The result is visible everywhere you already look:

chron history
Enter fullscreen mode Exit fullscreen mode 
8f3a7c9e  claude-code  API refactor         [ATTENTION: 86]  ●●●●
3d0a5f22  claude-code  Auth middleware fix  [ATTENTION: 72]  ●●●○
b91c2a11  cursor        Contract review       [ATTENTION: 12]  ●○○○
Enter fullscreen mode Exit fullscreen mode 
chron risk --since=30d
Enter fullscreen mode Exit fullscreen mode 
Sessions requiring attention  (last 30 days)

  1.  8f3a7c9e  claude-code  API refactor         Score: 86
      ↳ secret detected in session
      ↳ auth code modified (3 files)
      ↳ 2 unresolved SOC 2 findings (1 critical)

  2.  3d0a5f22  claude-code  Auth middleware fix  Score: 72
      ↳ access control code modified
      ↳ production config changed
      ↳ 1 unresolved ISO 27001 finding
Enter fullscreen mode Exit fullscreen mode

No AI in the scoring path. Pure path matching + database queries. Same session, same score, every time.

Why this matters now

The compliance question used to be "do we have logs?" Most teams can answer that today.

The question in 2026 is "did the AI touch anything that warrants a review?" That's a triage problem, not a logging problem. Attention Score is the answer.

After that: a static local dashboard — chron dashboard — that generates an HTML snapshot with session list, scores, top reasons, open findings, and framework coverage. No server, no cloud account, no new dependencies. Same personality as the rest of Chron.

Chron is available on npm:

npm install -g chron-mcp
chron-mcp   # auto-configures Claude Code, Cursor, Windsurf
Enter fullscreen mode Exit fullscreen mode

Source and docs: github.com/SirinivasK/chron

Chron logs every AI conversation to a local SQLite database you own. Nothing leaves your machine.

Top comments (4)

Collapse
 
alexshev profile image
Alex Shev •

That move from logger to governance layer is the interesting part. Logging tells you what happened; governance changes what is allowed to happen next. The hard product question is where to draw the line between passive observability and active control.

Collapse
 
sirinivask profile image
Srinivas Kondepudi •

Exactly the right question, Alex. We keep them as separate layers by design.

Chron stays purely in the observability lane, tamper-evident logs, chain of custody, audit reports. It never blocks, never intervenes. An auditor can trust it precisely because it has no control plane.

CLAIIM (our companion platform, still in preview) sits above it as the governance layer, approval tokens, policy enforcement, human-in-the-loop gates. It can act on what Chron sees.

The line we draw: observability must be unconditional to be trustworthy. The moment your audit log is also your policy enforcer, the temptation to tune it for compliance theatre grows. Keeping them separate means the log is always honest, even when the policy failed.

Collapse
 
alexshev profile image
Alex Shev •

That separation makes sense. An audit layer loses trust the moment it can also steer the system it is auditing. Keeping Chron observational and putting enforcement in CLAIIM gives you a cleaner chain of custody and a clearer blame boundary.

Thread Thread
 
sirinivask profile image
Srinivas Kondepudi •

absolutely