DEV Community: Srinivas Kondepudi

What Evidence Does an AI Agent Actually Need to Leave Behind?

Srinivas Kondepudi — Wed, 23 Sep 2026 09:28:39 +0000

What Evidence Does an AI Agent Actually Need to Leave Behind?

There is a question that keeps surfacing as AI agents move from answering questions in chat to actually doing things, writing code, modifying configs, calling APIs, deploying services.

The question is not "how do we stop them from acting?"

The question is: what evidence do we need after they act?

The Git Commit Problem

The reflex answer is: just look at the diff.

A Git commit shows you what changed. That used to be enough when a human sat behind every change. The human held the context. You could ask them. The commit message, however brief, was a pointer to a person who understood the decision.

With an AI agent, the commit is often the only artifact. And it hides almost everything that mattered:

What did the user actually ask for?
What did the agent read before deciding what to change?
Which tools did it call, and in what order?
Did it touch secrets, authentication tokens, environment variables, or production config along the way?
Was there a human in the loop, and if so, did they actually review anything, or just click Allow?
Can someone reconstruct the full sequence six months from now when something breaks in production?

A commit hash answers none of those questions.

Why This Is the Practical Governance Problem Right Now

We have spent years building approval workflows for human code changes. Pull requests, code review, change advisory boards, ticket numbers in commit messages. These processes assume a human author who can be questioned, who made a conscious decision, who can explain their reasoning.

AI agents break that assumption quietly.

The agent acts faster than review cycles were designed for. It calls ten tools in thirty seconds. It reads a config file, writes a new one, runs a test, opens a PR, and waits, all before anyone noticed it started. The change looks reasonable. The tests pass. The PR gets merged.

Three months later, something unexpected happens in production. You need to understand what the agent knew, what it read, what choices it made, and what a human approved.

If the only record is the commit, you have nothing.

The Minimum Viable Evidence Set

I am not arguing for heavyweight approval workflows on every AI action. That path leads to agents being so throttled they are useless.

But I do think every meaningful AI action, anything that modifies state outside the agent's own scratchpad, should leave enough evidence to answer questions when it matters.

Here is what that looks like in practice:

1. The original intent

What did the user ask for? Not the agent's interpretation, the actual message. This is the anchor for everything else. If the change cannot be traced back to a human request, that is itself meaningful information.

2. The tool call sequence

Which tools did the agent call, in what order, and what did it pass to them? This is the chain of decisions. A file read that preceded a file write tells you the agent saw the old value before replacing it. A secrets lookup before a config change is a different kind of event than a blind write.

3. What the agent read

Before an agent modifies something, it usually reads something. That read context is often the difference between "the agent made a reasonable change given what it saw" and "the agent made a change that only makes sense if it misread something."

4. Sensitive surface contact

Did the interaction touch authentication, authorization, secrets, infrastructure definitions, or production configuration? These are not just higher-risk changes, they are the category of changes that auditors, security teams, and incident responders will ask about first.

5. Human approval record

Was a human shown anything before the change happened? Did they click through a permission prompt, review a plan, or simply let the agent run autonomously? The presence or absence of human review is material. So is the kind of review, "I saw a one-line summary" is different from "I read the full plan and the diff."

6. Reconstructability

Can someone who was not in the room replay the sequence? Not re-run the agent, but follow the evidence trail and understand what happened. This is the test. If the answer is no, the evidence is insufficient.

Where People Draw the Line

In practice, teams end up in one of a few places:

Git history only. Fast, familiar, already required. Works fine when agents are doing what a junior developer would do and the stakes are low. Fails when something goes wrong and you need to explain the decision chain.

Tool-call logs. A step up. You know what the agent touched. You do not always know why, or what it read, or what the user originally asked for. Better for incident response than for governance.

Approval records. Some teams require a human sign-off checkpoint before the agent can modify certain surfaces — production, secrets, auth config. This is reasonable for high-stakes surfaces. It does not help you reconstruct what happened before the approval, or what the agent read to arrive at its proposal.

Full session traces. The full conversation, user messages, tool calls, reads, writes, tool results, stored with tamper-evident hashes. This is the complete evidence set. It is also the most expensive to store and the most sensitive to handle, because it may contain secrets that appeared in tool results.

The honest answer is that the right level depends on the surface. An agent writing unit tests probably does not need a full session trace. An agent modifying IAM policies probably does.

What Chron Is Doing Here

Chron is an MCP server that creates tamper-evident audit logs of AI sessions — stored locally, on your own machine, in a SQLite database you control.

Every tool call is logged with a cryptographic hash chain. The user's original message is captured. The sequence is reconstructable. The database does not leave your environment.

It crossed 9,000 npm downloads this week, which is a signal that the question this article is asking is not just theoretical. People are encountering it in real work and looking for answers.

Chron's position is deliberately minimal: it records, it does not certify. It does not tell you whether a change was authorized or correct. It gives you the evidence to answer those questions yourself, or to hand to someone else who needs to answer them later.

That boundary - recording vs. certifying - matters. The tool that captures evidence should not be the same tool that decides what the evidence means. Those are different jobs.

The Question Worth Asking Your Team

If an AI agent in your environment made a change right now, something it wrote, deployed, or modified, and three months from now you needed to explain that change to a customer, an auditor, or your own security team, what would you show them?

If the answer is "the commit," that is worth thinking about.

Not because commits are bad. Because they were designed for a world where a human sat behind every change, and that world is changing faster than our evidence practices are.

Chron is available as an MCP server: npx chron-mcp. It works with Claude, Cursor, and any MCP-compatible AI tool. The audit database is yours - local SQLite, no cloud egress.

The AI Race Has a Missing Question: Can We Explain What Our Agents Already Did?

Srinivas Kondepudi — Fri, 18 Sep 2026 16:08:34 +0000

The public conversation around advanced AI often collapses into two positions.

One side says we should slow down.

The other says progress is inevitable, so we should accelerate and compete.

Both arguments matter. But teams deploying AI agents today face a more immediate problem:

Can we explain what the agents already did inside our own environments?

That question is less dramatic than the future of superintelligence. It is also more operationally urgent.

AI coding assistants and autonomous agents are no longer limited to suggesting text in a chat window. They can inspect repositories, execute commands, call tools, modify files, use credentials, interact with ticketing systems, and reach external services.

Once that happens, "we have a policy" is no longer enough.

A team needs to be able to answer basic questions after an incident, review, or audit:

What was the original request?
Which tools did the agent use?
What happened between the prompt and the final answer?
Which files or systems were changed?
Was a risky action approved?
Did a person review the result?
Can someone else reconstruct the sequence later?

The important word is not logging. It is causality.

A repository might show that a file changed. A chat transcript might show that someone asked for help. An access log might show that a credential was used.

But those records often do not explain how the events connect:

Which agent action led to this command, which led to this file write, under which user request, with which approval?

That missing chain is where accountability disappears.

This is not an argument for blocking every action

Human checkpoints matter, especially for irreversible or high-impact actions. But prompting a person for approval on every operation creates its own failure mode: approval fatigue.

Anthropic has written publicly about this tradeoff. Its experience with agent permissions found that people approved the overwhelming majority of prompts, making constant confirmation an unreliable safety mechanism by itself. Their focus is increasingly on technical containment: constraining what an agent can do through boundaries such as sandboxes, virtual machines, and egress controls. Read How we contain Claude across products.

The point is not to eliminate human review.

It is to reserve it for the moments where it matters, then preserve evidence that the review happened.

Governance needs two layers

A useful operating model has two distinct layers.

Preventive controls constrain what an agent can do: scoped credentials, network boundaries, sandboxes, policy enforcement, and approval gates.

Detective controls preserve what the agent did: requests, tool calls, results, files changed, timestamps, decisions, approvals, and evidence of review.

One without the other is incomplete.

Preventive controls can reduce harm, but they cannot explain an action later unless the decision itself is recorded.

Logs can support an investigation, but they cannot prevent an agent from reaching a system it should never have been allowed to access.

This is why the conversation should not be "governance versus innovation." Good governance is part of what lets teams adopt useful agents with confidence.

OpenAI's own discussion of safely operating coding agents describes the same ingredients: technical boundaries, approval decisions, agent-aware telemetry, and the ability to inspect the original request, tool activity, results, and policy decisions when something needs review. Read Running Codex safely at OpenAI.

Build the evidence trail before you need it

The worst time to ask how an AI agent acted is after something went wrong.

By then, the prompt may be gone, the context may have been compacted, tool output may have changed, and the person who ran the session may not remember why a decision was made.

Evidence is cheap to preserve at the moment of action and expensive to reconstruct later.

That is the problem Chron is built around.

Chron is a local-first audit trail for AI-assisted work. It records AI sessions and their events, maintains evidence integrity locally, and helps teams find the sessions that warrant review. It does not certify compliance or replace a human auditor. It gives teams a more defensible starting point: a record of what occurred.

The argument about how quickly AI should progress will continue.

In the meantime, organizations should make sure that the AI already acting in their codebases and environments is not operating in a black box.

Because the question after an incident will not be:

"Was the model powerful?"

It will be:

"What did it do?"

Chron has passed 8,852 downloads. It is still early, local-first, and free to try:

npm install -g chron-mcp

The AI Race Is a Governance Problem Before It Is a Superintelligence Problem

Srinivas Kondepudi — Thu, 10 Sep 2026 09:13:56 +0000

The Long-Term Debate Is Already an Operational Problem

This week, a researcher who said he spent three years working at OpenAI and Anthropic resigned publicly and warned that leading labs are moving too quickly toward systems that may become difficult to control.

His warning is his own assessment, not a prediction anyone can prove today. But it raises a question that engineering teams should not wait to answer:

What evidence do we have of what our AI systems are actually doing?

From Answering Questions to Taking Actions

The long-term debate is about increasingly capable and autonomous systems.

The immediate problem is simpler.

AI tools already inspect repositories, execute commands, call tools, change files, and influence work in real environments. They are moving from "answering questions" to "taking actions."

When that happens, a prompt and a final answer are not enough.

The meaningful security and governance surface is everything in between:

the files an AI inspected
the tools it invoked
the commands it ran
the code it changed
the secrets it encountered
the actions a human reviewed or approved

That is not merely application logging. It is operational evidence.

The Gap: There Is No Default Evidence Trail

Most teams have some combination of chat history, source control, CI logs, and cloud audit logs.

Those are useful, but they are disconnected. They rarely answer one important question cleanly:

What did this AI-assisted task do, why did it do it, and can another person review the path afterward?

That gap matters today, even if you have no view on the most extreme forecasts about AI.

Organizations do not need to wait for hypothetical superintelligence before they make AI actions visible and reviewable.

What an Honest Evidence Trail Looks Like

A trustworthy record needs to be explicit about its boundaries.

If a tool did not observe part of a conversation, it should not recreate it from memory or ask the model to estimate what happened. That would turn self-report into evidence.

Chron v0.1.56 handles this with:

chron attach codex

The command begins recording an existing conversation from the current point onward. It marks the session as partial evidence and keeps the boundary visible in verification and coverage reports.

chron verify <session-id>
chron coverage

The message is deliberately plain:

Chron began recording after this conversation had already started. Earlier turns are outside the evidence boundary.

That is better than a complete-looking record with a hidden gap.

What Chron Is and Is Not

Chron is a local-first audit evidence layer for AI-assisted work. When configured with supported AI tools, it records messages, tool activity, code changes, secret detections, timestamps, and tamper-evident hashes.

It is not an alignment solution.

It is not a compliance certification.

It is not a substitute for human oversight.

It is one practical control: making AI-assisted actions inspectable after they happen.

Accountability Has to Start Somewhere

The AI race may be a global problem. But accountable evidence is something every engineering team can start building now.

npm install -g chron-mcp@latest

Chron is local-first and free to try. The public warnings from AI researchers are worth reading alongside the more practical lessons from real evaluation incidents — they are two sides of the same problem.

As AI gets more capable, "trust us" will not be enough. We need evidence.

My AI audit tool was merging Claude and Cursor sessions. The bug was one UNIQUE constraint.

Srinivas Kondepudi — Mon, 07 Sep 2026 18:12:25 +0000

I maintain Chron, an MCP server that writes an audit log of AI coding sessions to a local SQLite database. Every message gets a timestamp, and every session records which tool produced it: Claude, Cursor, Codex.

A while back I opened the history and found Claude messages and Cursor messages interleaved inside a single session. Two different tools, two different terminals, one session record.

For a tool whose entire job is attribution, that is about as bad as a bug gets.

The setup

The sessions table looked like this:

CREATE TABLE sessions (
  id       TEXT PRIMARY KEY,
  title    TEXT NOT NULL UNIQUE,
  ai_tool  TEXT,
  created_at TEXT NOT NULL,
  updated_at TEXT NOT NULL
);

When a tool starts work it calls init_session with a title and its own ai_tool. If a session with that title already exists, resume it. Otherwise create a new one.

Both Claude and Cursor generate a short descriptive title from the task. Working in the same repo on the same task, they generate the same title. Something like General assistance session.

UNIQUE(title) then guarantees only one row can exist for that title. So the second tool does not get its own session. It resumes the first one. Claude's messages and Cursor's messages land under the same session id, and ai_tool on that session reports whichever tool happened to start first.

The constraint was doing exactly what it was written to do. It was just the wrong constraint. A title was never the identity of a session. The pair (title, tool) was.

Fix attempt one, which does not work

The obvious move:

CREATE UNIQUE INDEX idx_sessions_title_tool ON sessions(title, ai_tool);

This is wrong, and it is wrong in a way that survives a casual test.

ai_tool is nullable. In SQL, NULL is never equal to NULL, and that includes comparisons inside a unique index. The constraint stops constraining the moment the column is NULL:

CREATE TABLE a (title TEXT NOT NULL, ai_tool TEXT);
CREATE UNIQUE INDEX ia ON a(title, ai_tool);

INSERT INTO a VALUES ('Session', NULL);
INSERT INTO a VALUES ('Session', NULL);   -- succeeds

SELECT count(*) FROM a;  -- 2

Two identical rows under a unique index. This is standard SQL behaviour rather than a SQLite quirk, but it is easy to forget the moment you add a nullable column to a composite key.

It mattered here because Chron has legitimate NULL ai_tool rows: sessions created through the library API without a tool set.

The fix

Index an expression instead of the raw column:

CREATE UNIQUE INDEX idx_sessions_title_tool
  ON sessions(title, COALESCE(ai_tool, ''));

NULL collapses to the empty string, which does compare equal to itself:

CREATE TABLE b (title TEXT NOT NULL, ai_tool TEXT);
CREATE UNIQUE INDEX ib ON b(title, COALESCE(ai_tool, ''));

INSERT INTO b VALUES ('Session', NULL);
INSERT INTO b VALUES ('Session', NULL);      -- UNIQUE constraint failed
INSERT INTO b VALUES ('Session', 'claude');  -- ok
INSERT INTO b VALUES ('Session', 'cursor');  -- ok

One row per tool, duplicates within a tool still rejected. That is the property I actually wanted.

The lookup code had to match, of course. Resume was searching by title alone, so even with the right constraint it would have kept finding the other tool's row:

// before
const existing = await db.select().from(sessions)
  .where(eq(sessions.title, args.title));

// after
const existing = await db.select().from(sessions)
  .where(and(
    eq(sessions.title, args.title),
    requestedTool === null
      ? isNull(sessions.ai_tool)
      : eq(sessions.ai_tool, requestedTool),
  ));

A constraint and the query that relies on it are one unit. Changing only one of them just moves the bug.

Dropping a constraint in SQLite

SQLite has no ALTER TABLE ... DROP CONSTRAINT. The inline UNIQUE on title is part of the table definition, so removing it means rebuilding the table:

await client.execute('PRAGMA foreign_keys = OFF');
await client.execute('BEGIN');
try {
  await client.execute(`CREATE TABLE sessions_migration (
    id TEXT PRIMARY KEY,
    title TEXT NOT NULL,     -- no UNIQUE
    ai_tool TEXT,
    ...
  )`);
  await client.execute(
    'INSERT INTO sessions_migration SELECT id,title,ai_tool,... FROM sessions'
  );
  await client.execute('DROP TABLE sessions');
  await client.execute('ALTER TABLE sessions_migration RENAME TO sessions');
  await client.execute('COMMIT');
} catch (e) {
  try { await client.execute('ROLLBACK'); } catch { /* ignore */ }
  throw e;
} finally {
  await client.execute('PRAGMA foreign_keys = ON');
}

Standard shadow-table dance. Nothing surprising.

The migration bug that was worse than the original bug

Here is the part worth the post.

I first wrote the migration guard as: if the composite index does not exist, migrate. It reads perfectly sensibly, and it fails on exactly the databases that need it.

The schema bootstrap runs CREATE UNIQUE INDEX IF NOT EXISTS idx_sessions_title_tool ... before the migration check. On an existing database that still carries the legacy inline UNIQUE(title), that statement succeeds. It creates the composite index on the old table. The old constraint is still sitting there, untouched.

So by the time the migration check runs, the index exists, the guard concludes "already migrated", and it skips. The table keeps UNIQUE(title) forever.

Fresh databases were fine, because they were created correctly from the start. The test suite passed, because tests build fresh databases. Every real user upgrading from an older version would have kept the bug.

The guard has to ask about the constraint, not about a side effect that usually correlates with it. The only way to see the constraint is the stored DDL:

const info = await client.execute(
  "SELECT sql FROM sqlite_master WHERE type='table' AND name='sessions'"
);
const tableSql = String(info.rows[0]?.sql ?? '');
const hasLegacyTitleUnique =
  /\btitle\s+TEXT\s+NOT\s+NULL\s+UNIQUE\b/i.test(tableSql);

if (hasLegacyTitleUnique || compositeIdxMissing) {
  // rebuild
}

Regex against DDL is not elegant. It is, however, the thing that is actually true.

And the test has to start from the old schema, not a fresh one:

// build a legacy database on purpose
await client.execute(`CREATE TABLE sessions (
  id TEXT PRIMARY KEY,
  title TEXT NOT NULL UNIQUE,   -- the old constraint
  ai_tool TEXT, ...
)`);
await client.execute(`INSERT INTO sessions VALUES ('old-claude', 'General assistance session', 'claude', ...)`);

await initDb(dbPath);

const table = await client.execute(
  "SELECT sql FROM sqlite_master WHERE type='table' AND name='sessions'"
);
expect(String(table.rows[0].sql)).not.toMatch(/\btitle\s+TEXT\s+NOT\s+NULL\s+UNIQUE\b/i);

// cursor can now hold the same title
await client.execute(`INSERT INTO sessions VALUES ('new-cursor', 'General assistance session', 'cursor', ...)`);

// but a duplicate within the same tool is still rejected
await expect(client.execute(
  `INSERT INTO sessions VALUES ('dupe-claude', 'General assistance session', 'claude', ...)`
)).rejects.toThrow();

What I took from this

A UNIQUE constraint is an identity claim. UNIQUE(title) asserted "a title identifies a session". That was never true, and the database enforced the false claim faithfully until the day two tools showed up.

Nullable columns in composite unique indexes usually do not do what you want. If the column can be NULL, index an expression.

Migration guards should test for the thing you are fixing. Not for a marker that normally accompanies it. Ordering inside your own bootstrap can invalidate the marker.

A migration test that starts from a fresh schema tests nothing. Construct the old schema, put a row in it, then migrate. This is the one that nearly got me: the fix was correct, the suite was green, and real upgrades would have stayed broken.

That last point is the general shape of the lesson. Green tests told me the bug was fixed. They were testing a database that never had the bug.

Chron is on npm as chron-mcp if you want to look at the code, or run npx chron-mcp to point it at your own AI sessions.

npm Trusted Publishing fails with a 404, and the 404 is lying to you

Srinivas Kondepudi — Sun, 06 Sep 2026 14:43:49 +0000

npm is winding down 2FA-bypass granular access tokens. Since 31 July 2026 they can no longer perform account, organisation, or package management operations, which includes editing trusted publishing configuration. In January 2027 they lose direct publish as well, leaving them able to read private packages and stage a publish that a maintainer then approves with 2FA.

The replacement is OIDC Trusted Publishing, where you register a GitHub repo and workflow on npmjs.com and the workflow authenticates with a short-lived token instead of a stored secret.

I migrated. The release workflow then failed four times in a row, and the error message pointed nowhere near the actual problem.

This is the writeup I wanted to find while debugging it.

The symptom

npm notice publish Signed provenance statement with source and
  build information from GitHub Actions
npm notice publish Provenance statement published to transparency log:
  https://search.sigstore.dev/?logIndex=2685306213
npm error code E404
npm error 404 Not Found - PUT https://registry.npmjs.org/chron-mcp - Not found
npm error 404  'chron-mcp@0.1.55' is not in this registry.

The package exists. It has published versions. I own it. And the registry says it is not there.

Two things in that output are actively misleading, and I chased both.

Red herring one: the provenance step succeeds

Look at the order. Provenance signing works. It reaches sigstore, signs, and posts to the public transparency log. That requires the GitHub Actions OIDC token, so id-token: write is clearly working.

It is very natural to conclude that OIDC is fine and the problem is something else.

It is not the same feature. Provenance signing uses the OIDC id-token to sign an attestation with sigstore. Trusted Publishing uses the OIDC id-token to exchange for a registry auth token. Different mechanisms, different code paths, introduced in different npm versions. One can work perfectly while the other does not exist.

Red herring two: a token that looks leaked

The step environment shows this:

env:
  NPM_CONFIG_USERCONFIG: /home/runner/work/_temp/.npmrc
  NODE_AUTH_TOKEN: XXXXX-XXXXX-XXXXX-XXXXX

That looks like a masked secret. My first theory was that a stale NPM_TOKEN was being injected and overriding OIDC, so I removed it from the workflow and added unset NODE_AUTH_TOKEN.

It made no difference, because that value is not a secret at all. GitHub is not masking anything. Those are real X characters.

actions/setup-node@v4 writes an .npmrc containing //registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}, and then exports a dummy value when you have not supplied one, so that npm does not warn about a missing variable. From src/authutil.ts on the v4 tag:

// Export empty node_auth_token if didn't exist so npm doesn't complain
// about not being able to find it
core.exportVariable(
  'NODE_AUTH_TOKEN',
  process.env.NODE_AUTH_TOKEN || 'XXXXX-XXXXX-XXXXX-XXXXX'
);

Worth knowing that this is version-specific. On main the action has changed to only export the variable when the user actually provided one, so if you are on a newer major you may not see this at all. If you are pinned to v4, you will, and it looks exactly like a leaked credential.

For completeness, a pre-set token would not block OIDC anyway. In lib/commands/publish.js, oidc() is called before credentials are read, and it overwrites the auth token directly:

await oidc({ packageName: manifest.name, registry, opts, config: this.npm.config })

const creds = this.npm.config.getCredentialsByURI(registry)

The actual cause

The workflow pinned Node 20:

- uses: actions/setup-node@v4
  with:
    node-version: 20

Node 20 bundles npm 10.8.2. npm documents the requirement as npm CLI 11.5.1 or later, and Node 22.14.0 or higher.

npm 10 does not have a partial or broken implementation. It has none at all. You can verify this without reading a changelog:

for v in 10.8.2 11.5.0 11.5.1 11.19.0; do
  npm pack npm@$v --silent >/dev/null
  mkdir -p ex-$v && tar xzf npm-$v.tgz -C ex-$v
  echo "npm $v -> $(ls ex-$v/package/lib/utils/oidc.js 2>/dev/null || echo 'NO OIDC')"
done

npm 10.8.2  -> NO OIDC
npm 11.5.0  -> ex-11.5.0/package/lib/utils/oidc.js
npm 11.5.1  -> ex-11.5.1/package/lib/utils/oidc.js
npm 11.19.0 -> ex-11.19.0/package/lib/utils/oidc.js

So npm 10 never attempts the token exchange. It falls back to the _authToken in the generated .npmrc, which resolves to nothing useful, and publishes unauthenticated.

You will notice 11.5.0 has the file too, which is worth explaining rather than glossing over. The OIDC code first shipped in 11.5.0, and the only difference in 11.5.1 is a scoping fix in the same file:

-      let enableProvenance = false     // declared inside the inner block
+    let enableProvenance = false       // hoisted out

In 11.5.0 the provenance-enabling branch sat inside an inner block, so it could not fire correctly. The token exchange itself is byte-identical between the two. That is why npm's documented floor is 11.5.1 rather than 11.5.0, and it is the version to pin. The distinction does not matter for the 404 in this post, because Node 20 gives you npm 10, which has nothing at all.

Why an unauthenticated publish returns 404

This is the part that wasted the most time.

The publish went out with no usable credential at all, and the registry answered 404 rather than 401 or 403. The explanation usually given is that answering 403 would confirm a package exists, letting anyone enumerate private package names by guessing, so the registry collapses "does not exist" and "you may not see this" into one response. I have not found npm stating that intent in those words, so take the reasoning as the community explanation and the behaviour as the observed fact.

The distinction that actually helps you debug is this one:

403 usually means your credential arrived and the identity behind it is not allowed to publish this package. The familiar form is You do not have permission to publish "x". Are you logged in as the correct user?
404 on a package you own usually means the registry never established who you are at all. The credential is missing, empty, or never sent.

So read 'chron-mcp@0.1.55' is not in this registry as a statement about your identity, not about your package name. That is the most useful reframing in this post. I spent a long time re-checking the package name, the scope, and the registry URL, when the message was really telling me the request was anonymous.

The fix, part one

- uses: actions/setup-node@v4
  with:
    node-version: 24
    registry-url: https://registry.npmjs.org

- name: Ensure npm supports OIDC trusted publishing
  run: |
    npm install -g npm@^11.5.1
    npm --version

Node 24 bundles npm 11.19.0, which is already sufficient. The explicit global install is a guard: Node 24.0.0 shipped npm 11.3.0, which is below the threshold, so pinning the major alone is not a guarantee. Printing npm --version into the log means the next person to debug this can rule it out in one glance.

The fix, part two, which the first fix revealed

With authentication working, the error changed. That is progress, even when it is still red:

npm error code E422
npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/chron-mcp -
  Error verifying sigstore provenance bundle: Unsupported GitHub Actions source
  repository visibility: "private". Only public source repositories are
  supported when publishing with provenance.

Provenance requires a public source repository. The repo publishing this package is private, so provenance was never achievable, and --provenance had been wrong from the first commit. It stayed invisible because the auth failure happened first.

The fix is to drop the flag rather than to add --no-provenance. From lib/utils/oidc.js:

const isDefaultProvenance = config.isDefault('provenance')
if (isDefaultProvenance && !ciInfo.CIRCLE) {
  const payload = JSON.parse(/* decoded id-token */)
  if (ciInfo.GITHUB_ACTIONS && payload.repository_visibility === 'public') {
    const visibility = await libaccess.getVisibility(packageName, opts)
    if (visibility?.public) {
      opts.provenance = true
    }
  }
}

npm auto-enables provenance only when the flag was left at its default and repository_visibility is "public". Passing --provenance explicitly sets isDefault to false and forces it on regardless. Omitting it lets npm make the correct decision on its own.

-  npm publish --access public --provenance --ignore-scripts
+  npm publish --access public --ignore-scripts

Green on the next run.

The working workflow

permissions:
  contents: read
  id-token: write     # required for OIDC

steps:
  - uses: actions/checkout@v4

  - uses: actions/setup-node@v4
    with:
      node-version: 24
      registry-url: https://registry.npmjs.org

  - name: Ensure npm supports OIDC trusted publishing
    run: |
      npm install -g npm@^11.5.1
      npm --version

  - run: npm ci
  - run: npm test

  - name: Publish
    run: npm publish --access public --ignore-scripts

No NODE_AUTH_TOKEN. No NPM_TOKEN secret. The Trusted Publisher is configured on npmjs.com under the package's Settings, pointing at the repo and the workflow filename, and both have to match exactly.

Checklist if you hit this

Print npm --version in the job. npm 10 and below will not attempt OIDC at all, and 11.5.1 is npm's documented floor. This is the single highest-value check and it takes one line.
Read a 404 on a package you own as an identity problem, not a naming one. A 403 usually means your credential arrived and was rejected; a 404 usually means it was never established.
Do not treat a successful provenance step as proof that auth works. They are separate features.
NODE_AUTH_TOKEN: XXXXX-XXXXX-XXXXX-XXXXX is a literal placeholder, not a masked secret.
Only use --provenance if the source repo is public. Otherwise omit it and let npm decide.
Check the Trusted Publisher's workflow filename matches the workflow that actually runs the publish.

The general lesson is about error messages that withhold information. The 404 was not a bug. It was the registry saying it did not know who I was, in the least specific way available to it, and I read it literally for far longer than I should have.

From Audit Log to AI Governance Platform. How Chron Is Closing the Gap

Srinivas Kondepudi — Wed, 26 Aug 2026 07:54:48 +0000

The Problem Nobody Talked About

When teams started adopting AI coding tools — Claude, Cursor, Codex, GitHub Copilot, they got productivity. What they didn't get was visibility.

No one could answer: What did the AI actually do? What prompts were sent? What code was changed? Were any secrets exposed?

For developers, this didn't matter much. For a CISO or a compliance officer trying to prepare a SOC 2 audit or respond to an incident? It was a blindspot the size of a barn door.

That's the gap Chron was built to close.

What Chron Does

Chron is an MCP server that sits alongside your AI tool and creates a tamper-evident, locally-stored audit trail of every session.

Every message, every tool call, every code change — logged to a SQLite database on your machine. No cloud. No vendor. Your data stays with you.

npm install -g chron-mcp

Once installed, it plugs into Claude, Cursor, Windsurf, Codex, or any MCP-compatible tool and starts recording immediately.

Maturing Into AI Actions Recording

Chron started as a session logger. It's now becoming something more: a full AI actions recorder.

What that means in practice:

Message logging — every user prompt and AI response, timestamped and hashed
Tool call recording — when the AI reads a file, runs a command, or calls an API, it's logged
Code change tracking — diffs of what was written or modified
Secret detection (DLP) — Luhn, IBAN, API keys, email, phone, internal IPs detected in real time before they leave your terminal
Ed25519 signing — each session gets a cryptographic keypair; the log is tamper-evident by construction
NTP clock attestation — timestamps are anchored to a real time source, not the local clock alone

The result: a chain of custody for every AI interaction in your organisation.

Making CISOs and Teams Aware

The honest reality is: most developers don't think about audit trails. They shouldn't have to.

But when something goes wrong — a leaked credential, an unexpected code change, a compliance question from a regulator — the CISO needs answers fast.

Chron's report command generates evidence packages mapped to frameworks:

# SOC 2 evidence package
chron report --format=soc2

# Activity summary
chron report --since=30d

The SOC 2 report maps Chron's controls to CC6, CC7, and CC8 — the access, change management, and risk mitigation criteria auditors look for. ISO 27001, ISO 42001, EU AI Act, and NIST AI RMF mappings are also included.

SIEM integrations mean the logs can flow to Splunk, CrowdStrike LogScale, or Azure Sentinel, so the security team sees AI activity alongside everything else.

What's Still on the Roadmap

We're not done. The direction is clear: move from individual developer tool to organisational AI auditor platform.

What's coming:

Centralised org dashboard — a CIO/CISO-facing view across all team members' AI activity
Centralised database mode — teams push audit logs to a shared store, not just local SQLite
Policy enforcement integration — tie into CLAIIM, our companion governance layer, for approval tokens and human-in-the-loop gates
Anomaly alerting — flag unusual patterns: after-hours sessions, mass file reads, credential-adjacent prompts
Audit report scheduler — automated weekly/monthly evidence packages for compliance teams

The goal: the moment a regulator or external auditor asks "show me what your AI tools did last quarter," you hit one command and hand them a signed, timestamped, tamper-evident package.

Where We Are

Chron has crossed 8,000 downloads — organic, without a launch campaign. The teams installing it are doing so because they recognise the gap.

Big compliance platforms are now moving in the same direction. We shipped months ahead of them. And the local-first, data-sovereignty-first architecture is something a SaaS compliance cloud simply can't match for regulated industries.

If you're running AI tools in your organisation and don't yet have an audit trail — Chron is the fastest way to get one.

npm install -g chron-mcp

Try it. If it helps you — or if something's missing for your workflow — let us know. Real feedback gets rewarded.

The compliance frameworks were written before AI coding tools existed

Srinivas Kondepudi — Wed, 19 Aug 2026 20:58:05 +0000

ISO 27001, SOC 2, and NIST assume humans made decisions and left a paper trail. That assumption is breaking.

Imagine an auditor sitting across from your engineering team. They're working through your change management controls. They want to know: who approved this code change? What was the review process? Is there evidence that a qualified person made a deliberate decision?

Six months ago, the answer was straightforward: here's the pull request, here's the review, here are the approvals.

Today, the honest answer for many teams is: "We described the problem to Claude, it suggested this implementation, we thought it looked right, and we merged it."

That answer is not covered anywhere in ISO 27001. It barely appears in SOC 2. NIST is only now beginning to grapple with it. And the gap between those frameworks and how engineering teams actually work in 2026 is widening every week.

What compliance frameworks actually assume

ISO 27001, SOC 2 Type II, and NIST SP 800-53 were designed with a set of assumptions that seemed self-evident at the time:

A human made a decision.
That human was authenticated and authorized to make it.
The decision was documented — a ticket, a comment, a change record, a signature.
If something went wrong, you could trace back to who decided what.

These frameworks are not wrong. They describe exactly the kind of accountability that responsible engineering requires. The problem is not the principles — it's that they were operationalized around human workflows. Every control, every audit procedure, every evidence request assumes the actor was a person who left a recognizable trail.

AI coding tools are not authenticated. They don't sign commits. They don't have a name in your issue tracker. The conversation that produced a significant architectural decision might exist for exactly as long as the browser tab stays open.

When an organization gets ISO 27001 certified or completes a SOC 2 Type II audit, the auditors are certifying a snapshot: as of this date, these controls were in place. What they are increasingly unable to assess is whether those controls account for the AI sessions happening every day in the engineering org.

Three gaps that are already present

1. Change management evidence

SOC 2 CC6.6 requires that changes to infrastructure and software are authorized, tested, and documented before deployment. Most interpretations of this control assume a human reviewer in the loop who exercised judgment.

When an AI tool suggests and partially writes a change, the question becomes: what is the evidence of review? "A developer approved the PR" is technically true. But if that review consisted of reading an AI-generated summary of the AI's own change, is that the control your auditor is certifying? What judgment was actually exercised, and by whom?

The auditor question you'll face: "Can you walk me through how this change was reviewed before it was approved?" — and the honest answer involves an AI session that no longer exists.

2. Audit trails and session records

NIST SP 800-53 AU-2 through AU-12 cover audit and accountability: what events are logged, how records are retained, and how they can be reconstructed for investigation.

By default, none of your AI coding sessions are covered by any of this. The conversation where you asked your AI assistant to redesign the authentication flow, the session where you refactored database access patterns, the task that generated your API client library — these produced real changes to production systems, and they leave no audit record whatsoever.

Your git commits are logged. Your database queries are traced. Your API calls are metered. Your CI/CD pipeline has more observability than the AI sessions that increasingly drive what goes through it.

3. Data handling and third-party disclosure

GDPR Article 30 requires records of processing activities. ISO 27001 Annex A.15 covers supplier relationships and information security in them.

In practice, developers regularly paste production schemas, error logs with user context, and system architecture details into AI prompts to get better answers. Some organizations have explicit policies against this. Most do not. Even where policies exist, enforcement is near-zero because there is no log of what was shared and when.

If your organization is SOC 2 certified, your auditors have reviewed your data handling controls. The question is whether those controls — as written and as assessed — account for what your engineers are pasting into their AI sessions every day.

What organizations are doing — and what's missing

Prohibition. Some organizations have banned AI coding tools entirely, citing compliance risk. This is understandable and also losing ground. The productivity differential is real, and enforcement on personal devices is functionally impossible.

Policy without enforcement. More common: "Don't paste customer data into AI tools" lives in the acceptable use policy. There is no technical control, no session record, no way to verify. The policy exists; the assurance does not.

Output review. Some teams have added AI-specific code review steps. This is better than nothing. It partially addresses change management but doesn't touch data handling or audit trail requirements.

What's mostly absent: any systematic approach to capturing what AI tools did, what context they received, and what decisions they influenced. The record of AI involvement in engineering work is today almost entirely missing from compliance evidence packages.

What needs to change — at two speeds

The slow track: framework updates

ISO and NIST revision cycles are measured in years. The NIST AI Risk Management Framework is a meaningful step, but it is not yet integrated into how SP 800-53 controls are assessed in standard audits. Building your compliance strategy around waiting for it is not a viable approach.

The fast track: interim controls

Treat AI sessions as auditable activity. Decide — explicitly — whether AI coding sessions are in scope for your audit and accountability controls. If they are, log them. If they are not, document why not and what compensating controls exist.
Define AI involvement in your change management policy. What does adequate review of an AI-generated change look like? Does it differ from review of human-written code? Every team operating under SOC 2 or ISO 27001 needs a written answer before their next audit.
Update your data classification policy to cover AI context. Which data classifications may be used as prompt context? This belongs alongside your existing data handling controls — and should be technically enforced where possible.
Include AI providers in your vendor and subprocessor inventory. If your team uses an AI provider's API, that provider is a data processor under GDPR and potentially a subservice organization under SOC 2. Most compliance programs have not updated their vendor inventories to reflect this reality.

The question coming for every engineering org

Compliance frameworks will update. They always do, eventually. The organizations that will be best positioned are the ones that start treating AI tool usage as an auditable activity now, before they are formally required to.

The question an auditor will eventually ask is not complicated: "Show me what your AI tools did, what they had access to, and how you controlled it."

Most engineering teams cannot answer that today. Building the answer is not a compliance checkbox exercise — it is engineering discipline catching up to how the work actually happens.

The frameworks weren't wrong. They just couldn't see this coming. Neither could most of us.

If you found this useful, I'd be curious what your team's approach has been — especially if you've been through a SOC 2 or ISO audit recently. The practical experience is ahead of where the guidance is.

What did your AI actually do last week? Nobody knows.

Srinivas Kondepudi — Fri, 14 Aug 2026 21:41:41 +0000

Think back to the last AI-assisted coding session you had. You asked Claude or Codex or Cursor to help with something. It worked. You shipped it.

Now answer this: what exactly did it say? What did you ask, what did it propose, what did you approve? Can you reconstruct the reasoning chain, or is it gone the moment you close the tab?

Every other tool in your stack has an audit trail. Your git commits are logged. Your deploys are timestamped. Your database queries are traced. Your API calls are observable.

Your AI coding sessions, where increasingly consequential decisions are made, produce no persistent record whatsoever.

That's the gap Chron was built to close. And based on what's happened in the past few months, a lot of developers had the same feeling.

~7,500 downloads
v0.1.52 current version
5 AI clients supported

What Chron actually is
Chron is an MCP server that sits between you and your AI tools and logs every exchange, timestamped, cryptographically signed, stored in a local SQLite database that lives on your machine. No cloud. No subscription. No data leaving your environment.

One install. Then every Claude Code session, every Cursor agent run, every Codex task, every Gemini CLI interaction is captured automatically. You don't change how you work.

$ npm install -g chron-mcp
then restart your AI client
That's it. From that point, chron history shows you everything:

chron history
$ chron history
2026-08-14 09:12 claude 14 msgs · 8min Refactor auth middleware
2026-08-13 22:47 codex 22 msgs · 31min Review vendor onboarding policy
2026-08-13 18:03 cursor 9 msgs · 12min Add rate limiting to API routes
2026-08-12 14:55 claude 41 msgs · 1h4m Chron release gate — v0.1.50
4 sessions · 127 messages · 2.1h tracked

What changed between 0 and ~7,500 installs
The early versions were minimal: log the session, store the messages, expose a CLI. The core thesis was right, but the friction was real, developers had to manually configure each AI client and write instruction files by hand.

The last three months were about eliminating that friction entirely. Here's what shipped:

// Zero-friction install
npm install -g chron-mcp now configures everything, MCP server entries for every AI client you have installed, global instruction files (~/CLAUDE.md, ~/.cursor/rules/chron.mdc, ~/AGENTS.md), and permission fixes. The only required manual step is restarting your AI client, so it picks up the new MCP server.

// Session boundary integrity
The most important fix wasn't a feature, it was correctness. Early versions had a bug where resume latest would attach new, unrelated work to an old session from hours ago, polluting the audit trail. The fix introduced a three-guard system: a 30-minute time window, title pattern matching for compaction recovery, and same-tool scoping. Your sessions are now distinct records, not one long accumulation.

// Doctor, self-diagnosing setup
chron doctor now catches real-world problems that were previously invisible. The most important: when you have Chron configured in both user scope (npx -y chron-mcp) and local scope (a dev path), Claude picks the local one, it fails, and sessions silently don't log. Doctor now parses ~/.claude.json directly, detects the conflict, and prints the exact fix:

chron doctor
$ chron doctor
! Claude Code chron configured in conflicting scopes
user scope: npx -y chron-mcp
local scope: node /Users/you/chron/dist/index.js ← remove this
Fix: claude mcp remove chron -s local

// Multi-client project bootstrap
When Chron's MCP server starts inside a real project directory, it now automatically writes AGENTS.md and .cursor/rules/chron.mdc into that project. Codex and Cursor pick these up on the next session start. No manual chron connect needed per project.

// STORAGE
Local SQLite
All data stays on your machine. No accounts, no cloud sync, no telemetry.

// INTEGRITY
Ed25519 signatures
Sessions are cryptographically signed. Tamper-evident by default.

// PATTERNS
Behavioral detection
SIEM-compatible patterns flag prompt injection, credential exposure, scope creep.

// RISK
Attention scoring
Sessions get a deterministic risk score based on content, tool calls, and patterns.

// EXPORT
SIEM integration
Forward events to Splunk, Microsoft Sentinel, or CrowdStrike LogScale.

// CLIENTS
All major AI tools
Claude Code, Cursor, Codex, Gemini CLI, Claude Desktop — one install covers all.

The thing about ~7,500 downloads
I expected the early adopters to be security-conscious teams or compliance-driven orgs. They're not, or at least, that's not the majority. The bulk of installs are individual developers who want to know what their AI tools did.

The instinct driving it isn't compliance. It's the same instinct that makes you run git log before a release or check your query logs when something's slow. You want to know. The AI is making real changes to real code, and the conversation that produced those changes is currently ephemeral.

Chron makes it permanent. Not for auditors, for you.

Chron records. It does not certify. The record is yours, and it stays on your machine.

What's next
The logging layer is stable. The next layer is enforcement, runtime ALLOW/DENY gates that sit on top of the Chron proof and let teams define what AI tools are and aren't allowed to do. That's being built as CLAIIM, a companion project. Chron is the "what happened" record; CLAIIM is "was it authorized."

For now: if you're using any AI coding tool and you don't have a session log, you're flying blind. The install takes 30 seconds.

$ npm install -g chron-mcp
v0.1.52 · Node 18+
Start logging your AI sessions
Local-first · No accounts · Works with Claude, Cursor, Codex, Gemini

GitHub: https://github.com/nivaya/chron
npm: chron-mcp

If Chron helped your team, we want to hear from you with a reward in return

Srinivas Kondepudi — Sun, 09 Aug 2026 19:15:24 +0000

We want to hear how Chron is working in your workflow — and we'll thank you properly for sharing.

No form. No survey. Just a real answer to one question:

What does Chron catch that you would have otherwise missed?

That's it. One sentence or five paragraphs — whatever you have.

Why we're asking

Chron just crossed 6,000 downloads. We know it's running in real teams, on real codebases, in real compliance workflows. But download numbers don't tell us what actually matters to people using it.

We're building the next layer — evidence connectors, board-ready intelligence reports, a live UI — and the most useful thing you can give us right now is a real story. Not a feature request. A story.

What you get for sharing

We don't think "thank you for your feedback" is enough. So here's what we're offering:

1. We feature you.
If you share a case study (your org, your workflow, what Chron surfaced), we'll feature it in our next article — with full credit to you and your team. Public signal for your work.

2. We gift you a coffee.
For any substantive feedback — one paragraph minimum — we'll send you a Buy Me a Coffee gift directly. Small, but real.

3. Early access to NitivAI.
If you're dealing with compliance at scale — SOC 2, ISO 27001, EU AI Act — and want early access to the commercial governance layer we're building on top of Chron, tell us. We'll move you to the front of the list.

You can get one, two, or all three. Your call.

Two ways to share

Public: Open a thread in GitHub Discussions — your story becomes part of the community record and helps the next person deciding whether Chron is worth trying.

Private: DM @sirinivask here on dev.to, or reach out directly if you'd prefer the conversation stays internal. Enterprise workflows often can't go public — that's fine.

Chron is local-first. Your audit trail lives on your machine. No cloud, no vendor lock-in. If that's been useful to you, we'd love to know how.

→ github.com/sirinivask/chron

We crossed 6,000 downloads. Here's what we shipped to get there.

Srinivas Kondepudi — Mon, 03 Aug 2026 09:39:55 +0000

Tuesday morning. Your SOC 2 auditor emails you.

"Can you provide evidence of human review for all AI-assisted code changes in the last 90 days — which files were modified, what prompts were used, and whether any credentials were visible in context?"

You open your IDE. Git log? Commits are there. PR history? Reviews too. But the AI session itself — the conversation, the code it proposed, whether it saw your .env file, which compliance controls it touched — gone.

That gap is why I built Chron.

What Chron is

Chron is an MCP server that runs alongside your AI coding tool. Every message, every code change, every detected secret — locally timestamped, hash-chained, and stored in a SQLite database you own. No cloud. No data sharing. Works offline.

# Install once
npm install -g chron-mcp

# Check setup
chron doctor

Works with Claude Code, Cursor, Windsurf, Continue.dev — any MCP-compatible tool.

The last four releases: answers to questions auditors actually ask

v0.1.39 — "Which sessions are worth reviewing first?"

$ chron risk --since=30d

SESSION           SCORE  BAND      SIGNALS
a1b2c3d4          87     critical  secrets·auth·infra
e5f6g7h8          52     high      auth·findings(2)
i9j0k1l2          28     review    code_changes

The attention score: deterministic 0–100 per session. No ML, no API calls. Pure signal from what actually happened: secrets detected (+25), auth code changed (+15), infra modified (+12), open compliance findings (+8 each). A security lead can triage 90 days of AI sessions in under a minute.

v0.1.40 — "Can I get a one-pager for this audit?"

$ chron dashboard --since=30d --output=q3-audit.html

✓ Written: q3-audit.html
  8 sessions · 4 open findings · 1 critical · 2 high
  Coverage: 6 controls covered · 3 needs evidence

Five sections in a single static HTML file — no server, no login, no port: executive summary, sessions ranked by risk score, findings grouped by framework (SOC 2 / ISO 27001 / EU AI Act / NIST AI RMF), a control coverage map, and contextual next actions. Open in a browser. Print to PDF. Attach to the audit package.

v0.1.41 — "Walk me through this specific session."

$ chron dashboard --session=a1b2c3d4

✓ Written: chron-session-a1b2c3d.html
  Score: 87/100 (critical) · 3 findings · tamper: ✓ ok

The session detail report: attention score breakdown, full timeline with code diffs, secrets with masked values, compliance finding cards with pre-built accept/dismiss CLI commands, which controls the session touches, and a tamper evidence bar (hash chain + NTP clock + Ed25519 signature).

An auditor can open one file and understand what happened, why it matters, which policies it touched, and what action remains — without accessing any internal system.

v0.1.42 — "Is this a one-off, or a pattern?"

$ chron patterns --since=30d

Chron Patterns  last 30d · 8 sessions

●●●● HIGH    Repeated auth/access-control code modified
             4 sessions touched these paths
             · auth, login, rbac, permission…
             Sessions: a1b2c3d4  e5f6g7h8  +2 more

●●●○ MEDIUM  Recurring SOC 2 finding unresolved
             soc2.cc6_1.ai_access_control_change in 2 sessions

●●●○ MEDIUM  Findings unresolved for 28+ days
             3 open findings across 2 sessions

4 patterns detected  2 high  2 medium

Six pattern types: repeated secret exposure, repeated code-signal category changes (auth, infra, AI governance, monitoring), recurring unresolved findings, high-attention recurring sessions, stale findings (configurable: --stale=21).

--json outputs { patterns, session_count } — already shaped for SIEM ingestion in the next release. Pattern IDs are stable keys (repeated_auth_access_control_code_modified, recurring_finding:soc2.cc6_1.*) so SIEM rules can match without parsing titles.

One-off findings are noise. Patterns are risk. This command tells you which is which.

The number

We crossed 6,000 downloads this week. As of publishing: 6,139.

No fundraise. No acquisition. No VC backing. Just a CLI that answers a question nobody had an answer for, installed by 6,000+ developers who needed an audit trail for their AI coding sessions.

What's next

v0.1.43 — SIEM Risk Events: emit pattern_detected, high_attention_session, attention_score_computed events into your pipeline
v0.1.44 — Evidence Connectors: chron evidence import to link policy documents to coverage gaps
Phase 3.5 — Policy Evidence Registry: map your policies to the controls Chron already tracks

Try it

npm install -g chron-mcp
chron doctor

# After a few AI sessions:
chron risk
chron patterns --since=30d
chron dashboard --output=report.html

GitHub: https://github.com/sirinivask/chron

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

Srinivas Kondepudi — Mon, 27 Jul 2026 18:06:28 +0000

When 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

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

chron verify 8f3a
# ✓ hash chain intact — 14 events, no tampering detected

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

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

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

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

8f3a7c9e  claude-code  API refactor         [ATTENTION: 86]  ●●●●
3d0a5f22  claude-code  Auth middleware fix  [ATTENTION: 72]  ●●●○
b91c2a11  cursor        Contract review       [ATTENTION: 12]  ●○○○

chron risk --since=30d

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

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

Source and docs: github.com/SirinivasK/chron

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

CLAIIM: Governing AI Agents Before They Act

Srinivas Kondepudi — Mon, 20 Jul 2026 08:34:38 +0000

Building AI agents is becoming easier.

Running them safely once they can take real action is the harder problem.

The moment an agent can deploy, approve, investigate, escalate, refund, send, export, or trigger a workflow, the question changes from:

Can the agent complete the task?

to:

Should this agent be allowed to take this action, under whose accountability, and what proof will exist afterward?

That is the problem we are building CLAIIM around.

CLAIIM is a self-hosted governance and accountability layer for AI agents. It is designed for teams that want AI agents to operate inside real organizational boundaries, not just inside a prompt or a notebook.

The core idea is simple:

Give every agent a governed identity.
Bind that agent to a named human accountability anchor.
Check actions against policy before they run.
Record every ALLOW and DENY decision in Chron.
Keep the data in the customer's environment.

This is not about adding another dashboard after the agent acts. It is about putting a control point before execution.

Why this matters now

Most organizations already know how to govern humans.

They have identity providers, access reviews, privileged access workflows, audit logs, separation of duties, and change approval processes.

But AI agents often enter the organization through a different path:

a shared API key
a service account
a workflow token
a CI/CD secret
a browser session
a tool wrapper

That is enough to make something work. It is not enough to prove that it was governed.

When an AI agent takes an action, a security or compliance team will eventually ask:

Which agent was it?
Who owned that agent?
What was it allowed to do?
Which policy applied?
Was the decision made before execution?
Was the action allowed, denied, or approved by a human?
Can we prove that later?

If the answer is buried in logs written by the agent itself, the organization has a weak chain of custody.

CLAIIM is our attempt to make that chain explicit.

What we have added recently

Over the last few weeks, CLAIIM moved from a working governance prototype toward a more serious public-preview product.

Evaluation and offline licensing

CLAIIM now has an evaluation mode with clear limits.

No license file means the system runs as an evaluation instance. The UI shows the evaluation state, the remaining evaluation window, and the active limits.

For design partners and paid deployments, CLAIIM supports offline license files. The license is verified locally. There is no phone-home requirement in the runtime.

That matters for the kind of organizations we are building for. If the product claim is "your environment, your database," licensing should not quietly become a cloud dependency.

Guided rehearsals

One problem with governance products is that they can sound abstract until someone sees the loop.

So we added guided rehearsals in the product UI.

The current rehearsal templates cover:

DevOps agent: staging deploy allowed, production deploy blocked
Support agent: escalation allowed, sensitive data access blocked
Finance agent: report access allowed, payment initiation blocked

Each rehearsal provisions real CLAIIM entities:

organization boundary
accountability anchor
skill
policy
agent identity
ALLOW gate call
DENY gate call
Chron proof

These are not fake frontend animations. They run through the real backend APIs and real policy gate.

Chron proof export

After a rehearsal or real gate decision, CLAIIM can produce a proof report from Chron.

The important part of the report is plain English:

This report shows that before this agent took any action, it was required to identify itself, name a human accountable for its behavior, and pass a policy check. The allowed action proceeded. The denied action was blocked before any system was touched. Every decision is timestamped and cannot be altered.

That paragraph is the product.

The UUIDs, policy IDs, timestamps, and hashes matter. But the buyer needs to understand the governance outcome first.

Production readiness work

We have also been hardening the platform for enterprise-style evaluation:

rate limiting on sensitive API paths
security headers
clearer RBAC roles
SSO first-login least privilege
persistent SAML service-provider keys
Kubernetes/Helm deployment chart
production Kubernetes runbook
external PostgreSQL deployment path
license secret mounting in Kubernetes
health probes and resource defaults

This is not glamorous work, but it matters.

If a large enterprise asks whether CLAIIM can be deployed safely in their environment, the answer cannot be "run this demo script and trust us."

The product direction: Agent Chain of Custody

The more we test CLAIIM, the more one phrase keeps standing out:

Agent Chain of Custody

Single-agent governance is only the first step.

Real AI work is becoming delegated:

Human objective
  -> main agent
    -> research agent
    -> coding agent
    -> test agent
    -> review agent

Without a governance layer, that delegation becomes invisible.

With CLAIIM, we want the chain to be visible:

Human -> Main Agent -> Subagent -> Scoped Action -> Policy Decision -> Chron Proof

That means tracking:

who delegated the task
which subagent received it
what scope it was given
what risk level applied
what policy decided
whether a human checkpoint was required
what evidence was produced
what proof exists afterward

This is where we think the category is going.

AI agents will not stay as single isolated scripts. They will become multi-agent workflows. The governance model has to follow that shape.

What we are building next

The next pieces are focused on making CLAIIM more useful for serious evaluations.

SIEM export

Chron remains the source of truth, but security teams need events in their existing SOC pipeline.

SIEM export is now available. It is a signed webhook export for Chron decisions:

ALLOW
DENY
agent identity
action type
accountability anchor
policy version
skill version
deny reason
Chron hash metadata where available

It is disabled by default. No outbound traffic occurs unless the customer explicitly enables it.

Chain of Custody MVP

The first Chain of Custody version will be deliberately small:

parent agent
subagent
delegated task ID
risk level
scope
allowed scoped action
denied out-of-scope action
Chron proof report showing the chain

The goal is not to build a full agent orchestration engine.

The goal is to prove governed delegation.

Runtime credential governance

Eventually, an approved action should not just pass policy. It should also receive only the credentials needed for that approved action.

That points toward:

scoped credential grants
credential injection after policy ALLOW
revocation without breaking unrelated agents
tool-level enforcement
secrets kept out of agent context

This belongs in CLAIIM, but it should support the governance story rather than replace it.

Workflow lifecycle control

Long-running agents also need operational state:

active
paused
approval required
cooldown
disabled
rollback requested

We see this as a future layer around governed execution. CLAIIM should know not only whether an action is allowed, but whether the workflow itself is in a state where action is permitted.

What CLAIIM is not trying to be

CLAIIM is not trying to replace agent frameworks.

Use LangGraph, CrewAI, custom Python, internal orchestration, MCP servers, browser agents, or whatever runtime fits your team.

The governance question sits around those systems:

Before this agent acts, does the organization know who it is, what it can do, who is accountable, and what proof will exist?

That is the layer CLAIIM is focused on.

A simple mental model

If you are evaluating production AI agents, think of the stack like this:

Agent runtime: how the agent reasons and executes
Workflow layer: how long-running work is coordinated
Credential layer: what secrets and tools the agent can access
Governance layer: whether the action is allowed before execution
Proof layer: what evidence exists afterward

CLAIIM is focused on the governance and proof layers first, with runtime security and workflow control coming in as the product matures.

Why public preview matters

This space is still early.

The vocabulary is forming in public. People are talking about agent identity, delegated authority, approval gates, credential isolation, workflow lifecycle, audit receipts, and chain of custody because the same pressure is appearing in different organizations.

That is a good sign.

It means the problem is real.

Our job with CLAIIM is to turn that problem into a product that security, platform, compliance, and business teams can actually use.

Not just another agent demo.

A governed execution layer.

Identity before action.

Policy before execution.

Proof after every decision.

If you are working on production AI agents and want to compare notes, I would be happy to talk.

Public preview: https://claiim.io

Contact: support@claiim.io