DEV Community: Srinivas Kondepudi

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

Chron Intelligence Phase 1 complete: SOC 2, ISO 27001, EU AI Act, and NIST AI RMF, deterministically, with no AI in the execution path

Srinivas Kondepudi — Thu, 16 Jul 2026 19:25:53 +0000

Phase 1 of Chron Intelligence is complete. Chron now supports four deterministic compliance frameworks for AI coding sessions — SOC 2, ISO 27001, EU AI Act, and NIST AI RMF — with the same finding workflow across all of them.

This post covers how the framework layer works, why we kept AI out of the execution path, and where it's going next.

The problem we are solving

AI coding tools now touch auth code, modify Terraform, handle credentials, change deployment pipelines, and update risk scoring logic. Most teams have no structured record of this. When an auditor asks "what did your AI assistant do to access-control code last quarter?" — the answer is usually silence.

Chron fixes the audit trail. The review layer turns that trail into compliance evidence.

How the review layer works

chron review --framework=soc2
chron review --framework=iso27001
chron review --framework=euaiact
chron review --framework=nist-ai-rmf

Each command scans your Chron session history and flags findings against the selected framework. No model inference. No API calls. Pure pattern matching on structured events Chron already captured — code_change, secret_detected, tool_call.

The rule engine is deterministic: a rule fires if the path contains a keyword or a secret was detected. That is the entire execution path. No model decides what counts.

Four frameworks, same workflow

SOC 2 — 5 rules

Controls: CC6.1, CC6.6, CC6.7, CC7.2, CC8.1

Covers AI touching access-control code, credential detection, infrastructure/deployment changes, logging/monitoring changes, and data retention logic.

ISO 27001:2022 Annex A — 6 rules

Controls: A.8.2, A.8.3, A.8.12, A.8.20, A.8.24, A.8.31

Covers privileged access changes, access restriction code, sensitive data in session, network security config, cryptographic code, and production environment files.

EU AI Act (Regulation 2024/1689) — 6 rules

Controls: Art. 9, Art. 10, Art. 12, Art. 13, Art. 14

Covers risk management/guardrails (Art. 9), data governance and sensitive data (Art. 10), record-keeping/audit logging (Art. 12), transparency/explainability code (Art. 13), and human oversight mechanisms (Art. 14).

NIST AI RMF 1.0 — 7 rules

Controls: GOVERN 1.1/1.2, GOVERN 6.1/6.2, MAP 1.1/5.1, MAP 3.5, MEASURE 2.1/2.5, MEASURE 2.7, MANAGE 2.2/4.1

Covers AI governance policy changes, human oversight code, risk assessment/threat modelling, sensitive data in session, model evaluation pipelines, monitoring/drift detection, and incident response/fallback code.

Finding workflow

Every finding has a stable SHA-256 ID — deterministic from rule_id:session_id. It does not change between runs. You act on it once:

chron review accept abc12345 --note="reviewed with security team, PR #512 approved"
chron review dismiss abc12345 --note="test fixture, not production code"
chron review resolve abc12345 --note="credential rotated, no commit exposure confirmed"

Next run, reviewed findings do not reappear as noise. New findings — from sessions since your last review — surface cleanly. --all shows everything including reviewed items.

HTML evidence report

chron review --framework=nist-ai-rmf --output=report.html

Generates a printable HTML report. Each framework produces the correct cover page: "NIST AI Risk Management Framework (AI RMF 1.0)", "not an AI RMF assessment", Article-specific methodology for EU AI Act, Annex A for ISO 27001. The disclaimer is always on page one: findings are potential review items, not violations.

Why no AI in the execution path

The obvious question: why not ask a model to evaluate findings?

Two reasons.

You cannot audit an AI's reasoning. If a model decides a finding is real or dismissed, there is no inspectable rule to challenge. Human-designed rules are reviewable, editable, and arguable. If a rule fires on a test fixture, you dismiss it with a note. If the rule is wrong, you open an issue.

Models overclaim. A model asked "does this violate CC6.1?" will give a confident-sounding answer. That answer is not evidence. A licensed CPA or ISO 27001 auditor needs to evaluate whether your controls were suitably designed and operated effectively — a judgement call that no model output replaces.

The constraint that keeps this trustworthy: AI explains, never decides. Rules execute deterministically. AI will eventually help generate evidence narratives and answer natural-language questions about your session history — but the findings themselves come from rules a human can read and reason about.

Honest coverage

Chron does not cover every control in any of these frameworks. A full SOC 2 examination covers CC1–CC5 (governance, communication, risk assessment) which require board records and policy documents — not session logs. NIST AI RMF has ~70 subcategories; Chron's rule pack touches 11 of them.

The honest architecture:

Chron today:
  AI session evidence → targeted deterministic controls

Chron next:
  AI session evidence + policy docs + CI/CD + repo evidence → broader coverage
  Each control marked: covered / needs_evidence / manual_review / out_of_scope

CLAIIM:
  organisation-wide evidence + approvals + policies → full governance workflow

Phase 2 adds control maps for every framework — so users can see exactly which controls Chron covers from session logs and which need additional evidence sources.

What's next

Control maps — full list of every control in each framework, classified as covered, needs_evidence, manual_review, or out_of_scope
Session risk scoring — deterministic risk score at session close based on findings, severity, and code-change volume
chron risk --since=30d — top risky sessions, risk reasons, trend view
Multi-session pattern detection — repeated control triggers across sessions
Evidence connect — bring in policy docs, CI/CD events, repo signals to unlock broader framework coverage

Try it

npm install -g chron-mcp

Already installed:

chron update

Add to Claude Code, Cursor, Windsurf, or any MCP-compatible tool. Run chron doctor to verify. Start a session. Then:

chron review --framework=nist-ai-rmf --output=report.html

204 tests. Four frameworks. One workflow. If you're handling AI governance questions in a SOC 2, ISO 27001, EU AI Act, or NIST AI RMF context — I'd like to hear what you're running into.

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

Srinivas Kondepudi — Thu, 09 Jul 2026 20:26:55 +0000

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 to fix the audit trail problem. Today we're shipping the review layer.

What Chron captures

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.

The review command

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.

Scoped to recent sessions

chron review --framework=soc2 --since=30d

Useful for quarterly reviews or pre-audit prep. The --since flag accepts 7d, 30d, or YYYY-MM-DD.

HTML report

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.

The finding workflow

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.

Why no AI in the execution path

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 packs in v0.1.33

SOC 2 — 5 rules

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

ISO 27001:2022 Annex A — 6 rules

Rule	Controls	What triggers it
Privileged access change	A.8.2	`code_change` to admin/superuser/sudo/privilege paths
Access restriction change	A.8.3	`code_change` to auth/iam/rbac/permission/acl paths
Sensitive data detected	A.8.12	Any `secrets_detected` entry
Network security change	A.8.20	`code_change` to firewall/vpc/waf/nsg/ingress paths
Cryptography change	A.8.24	`code_change` to encrypt/crypto/tls/ssl/cipher paths
Production change	A.8.31	`code_change` to production/prod/ paths

Both frameworks produce the same finding workflow — stable IDs, accept/dismiss/resolve, HTML report. The report cover page shows the correct framework-specific disclaimer.

What's next

NIST AI RMF and EU AI Act rule packs
Session risk scoring — computed at session close, visible in chron history
Real-time SIEM alerts when a control fires during a live session
chron ask "which sessions touched auth code last quarter?" — natural language over the audit DB
GRC integrations (Vanta, Drata, Secureframe)

Try it

npm install -g chron-mcp

Already installed? Update in place:

chron update

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
chron review --framework=iso27001

If you're dealing with AI governance questions in your SOC 2 or ISO 27001 audit, I'd like to hear what you're seeing.

Your AI agent just took an action in production. Can you answer five questions about it?

Srinivas Kondepudi — Thu, 02 Jul 2026 20:14:47 +0000

AI agents are moving from answering questions to taking actions.

A deployment agent pushes to staging. A code review agent comments on a pull request. A support agent drafts a response. A finance agent reads a report.

These are all actions. They happened in your environment, on your behalf, triggered by AI. Now ask yourself:

Which agent took this action?
Who is the human accountable for that agent?
Was the action explicitly allowed before it ran?
Which policy governed it?
What tamper-evident proof exists right now?

If any of those answers is "I would have to check logs", you do not have a governance layer for your AI agents. You have AI with an audit trail. That is different.

Why IAM does not solve this

Identity and access management tells you whether a service account has permission to reach a system. It was built for humans and services with static, predictable behavior.

It cannot tell you whether a given action was inside the agent's declared scope. It cannot bind an agent action to a named human who accepted accountability for it. It does not evaluate intent or scope, only whether the credential is valid.

An AI agent with a valid service account token can act far outside what you intended, and your IAM layer will not know the difference.

The gap: IAM governs what a credential can reach. Agent governance governs what an agent may actually do, and who answers if it does something wrong.

What CLAIIM does

CLAIIM is an identity control plane for AI agents. The model is four steps:

1. Governed identity: Each agent is registered with a unique identity, a declared skill set, and a named human accountability anchor, the person who authorized this agent to operate.

2. Policy gate before action: Before the agent acts, it asks the CLAIIM gate. The gate evaluates the requested action against the active policy. It returns ALLOW or DENY with a reason, before execution.

3. Versioned skills and policies: Skills define what an agent is capable of doing. Policies define what it is allowed to do. Both are versioned and locked at evaluation time.

4. Chron: proof after every decision: Every ALLOW and DENY is written immediately to Chron, an append-only audit trail. Agent, anchor, action, policy version, skill version, outcome. Every decision, every time.

A concrete example: the DevOps agent

You have a deployment agent. You want it to deploy freely to staging, but you want production blocked entirely.

In CLAIIM, you define a policy:

# Skills this agent can use
skill: deploy-v2

# What is allowed
allow:
  - deploy:staging
  - deploy:rollback-staging
  - health:check

# What is explicitly denied
deny:
  - deploy:production
  - deploy:rollback-production
  - infra:destroy

When the agent calls the gate, it gets a decision before it does anything:

from claiim import Gate

gate = Gate(agent_id="deploy-bot", token="...")

# Staging deploy, will be allowed
result = gate.check(action="deploy:staging", target="api-v2")
# result.outcome == "ALLOW"
# result.chron_id == "chr_01j..."

# Production deploy, will be denied
result = gate.check(action="deploy:production", target="api-v2")
# result.outcome == "DENY"
# result.reason == "policy:no-prod-v1 -- action not in allow list"

The gate blocks the production deploy before it starts. The agent never calls your deploy infrastructure. Both decisions are in Chron immediately.

The Chron record

outcome	agent	action	anchor	policy	skill
ALLOW	deploy-bot	deploy:staging	s.emp1	no-prod-v1	deploy-v2
DENY	deploy-bot	deploy:production	s.emp2	no-prod-v1	deploy-v2
ALLOW	review-bot	pr:comment	j.smith	review-v2	review-v1
DENY	review-bot	pr:merge	j.smith	review-v2	review-v1

Every row is a decision: who asked, what they wanted, who is accountable, which policy and skill version were active, and what was decided. Append-only. Every time.

One important nuance on prompt injection

CLAIIM does not inspect model reasoning or detect prompt injection. But if a prompt-injected agent tries to call deploy:production, the gate still returns DENY, it does not care why the agent made the request. It evaluates the action against the policy regardless.

This means CLAIIM provides containment even when a model is compromised. It does not prevent the injection. It limits what the injection can actually do.

Installing the Evaluation Preview

CLAIIM runs entirely in your environment. The evaluation path is Docker Compose, under ten minutes to a working gate with proof in Chron.

# 1. Clone the distribution repo
git clone https://github.com/nivaya/claiim
cd claiim

# 2. Generate TOKEN_SECRET (your own, not issued by Nivaya)
cp .env.example .env
echo "TOKEN_SECRET=$(openssl rand -hex 32)" >> .env

# 3. Start the stack
docker compose up -d

# 4. Run the gate rehearsal
bash rehearsal.sh
# Expected: PASS: 13 / FAIL: 0

Image access note: Container images are gated during the controlled preview rollout. Email support@claiim.io with your GitHub username. After access is granted, create a GitHub PAT with read:packages and run docker login ghcr.io before step 3.

The rehearsal script provisions a sample agent, defines what it may and may not do, fires both an ALLOW and a DENY through the gate, and prints the Chron IDs to verify. You see real gate decisions before you write a single line of integration code.

What is in the preview and what is not

Complete and test-covered:

Gate enforcement (ALLOW / DENY)
Chron audit trail (append-only)
Organizational boundaries
Versioned Skills and Policies
Two-person control for privileged changes
Python SDK
Admin UI
Docker Compose install

Not in preview (in progress toward GA):

Kubernetes Helm chart
SAML / OIDC federation
Active-active HA
Signed air-gap bundle for Sovereign deployments

Your data does not leave your environment. Chron records, agent identities, policies, and gate decisions are all stored in your database, not in any Nivaya-hosted system.

Try it

Install guide and preview scope: claiim.io

Preview access: support@claiim.io, email with your GitHub username and we will enable package access.

We hit 3,600+ installs with zero marketing, here's what we learned building Chron

Srinivas Kondepudi — Thu, 02 Jul 2026 18:46:47 +0000

Six months ago I couldn't find a single tool that answered: what exactly did my AI coding assistant do in that session?

Not the output. The actions. The tool calls. The secrets it may have seen. The suggestions I accepted, and the ones I didn't.

So I built Chron.

What drove the traction

The problem is real and getting worse, developers want a record, security teams want visibility, nobody had a tool for both.

SIEM integrations. The moment we shipped chron connect splunk/sentinel/crowdstrike, enterprise security teams took notice. They don't want a new dashboard, they want events in the tools they're already monitoring.

The compliance angle. A community member pointed out Chron directly addresses OWASP AISVS C13 and NIST AI RMF logging requirements. That single comment spread further than anything we wrote.
What surprised us

Cross-platform demand. We built for Claude Code first. The moment we shipped chron connect codex for ChatGPT Codex, weekly installs jumped. People aren't loyal to one AI tool, they need audit coverage across all of them.

Where we are

3,657 installs. Zero marketing. Heading to 4,000.

npm install -g chron-mcp

What problem would make you install an AI audit tool without anyone telling you to?

CLAIIM: Identity and Governance for AI Agents Before They Act

Srinivas Kondepudi — Thu, 25 Jun 2026 19:24:53 +0000

CLAIIM: Identity and Governance for AI Agents Before They Act

AI agents are moving from experiments into real organizational workflows.

They are helping with code review, infrastructure operations, customer support, finance reporting, internal knowledge work, workflow automation, and decision support.

That shift creates a simple but uncomfortable question:

Who is responsible when an AI agent acts?

Most organizations already have controls for humans:

SSO
MFA
IAM roles
privileged access management
approval workflows
audit logs

They also have controls for services:

service accounts
API keys
workload identity
infrastructure logs
SIEM pipelines

But AI agents sit awkwardly between those worlds.

They are not exactly humans.

They are not exactly services.

They can reason, choose tools, call APIs, and act on behalf of people.

And in many systems today, they still operate as “just a token.”

That is the gap CLAIIM is built to close.

What CLAIIM Does

CLAIIM is an identity control plane for AI agents.

It gives each agent a governed identity and checks what that agent is allowed to do before it acts.

The core idea is simple:

Identity before action.
Policy before execution.
Proof after every decision.

With CLAIIM, an organization can answer questions like:

Which agent performed this action?
Which human was accountable for that agent?
Was the action allowed before it happened?
Which policy version governed the decision?
Which skill or capability was active at the time?
What proof exists after the action?

That matters because AI governance is not only about model evaluation or prompt safety.

It is also about operational accountability.

Why Existing Controls Are Not Enough

Traditional IAM answers:

“Can this user or service access this system?”

But agent governance needs to answer more specific questions:

“Can this particular agent, acting for this specific purpose, under this accountable human, perform this action right now?”

That is a different control problem.

For example, a DevOps agent might be allowed to deploy to staging, but not production.

A support agent might be allowed to draft a refund response, but not issue the refund.

A finance agent might be allowed to read reporting data, but not move money.

A code review agent might be allowed to comment on a pull request, but not merge it.

The difference is not only technical. It is organizational.

AI agents need boundaries that reflect real-world responsibility.

The CLAIIM Model

CLAIIM is built around four ideas.

1. Governed Agent Identity

Each agent gets its own identity.

That identity is not just a generic API token. It is tied to the organization, the agent’s allowed capabilities, and the human accountable for its operation.

2. Human Accountability

Every governed agent is anchored to a named human.

That does not mean the human manually approves every action. It means there is a clear accountability chain when the agent acts.

For regulated or sensitive environments, this becomes essential.

3. Policy Before Action

Before an agent performs an action, it asks CLAIIM whether that action is allowed.

CLAIIM evaluates the request against policy and returns an allow or deny decision.

The agent can only proceed if the action is allowed.

4. Chron Proof

Every allow and deny decision is recorded in Chron, CLAIIM’s audit trail.

Chron is designed to preserve evidence of:

the agent
the action
the decision
the accountable human
the policy version
the skill version
the reason for denial, if blocked

This gives teams evidence after the fact, not just logs scattered across tools.

A Simple Example

Imagine a deployment agent.

It can help a team deploy software, but the organization wants clear boundaries.

The policy might be:

allow deployment to staging
deny deployment to production
record every decision
attach the decision to the accountable human and active policy

When the agent tries to deploy to staging, CLAIIM allows it.

When the same agent tries to deploy to production, CLAIIM denies it.

Both decisions are recorded.

That is the point: the agent is useful, but not unbounded.

Why This Matters Beyond DevOps

The same pattern applies across the organization.

In support:

allow drafting a customer response
block sending it without review
record who owned the agent

In finance:

allow reading reports
block payment execution
preserve evidence for audit

In HR:

allow summarizing policy documents
block sensitive employee actions
log the decision path

In legal:

allow document analysis
block external disclosure
preserve chain of custody

The problem is not limited to engineering.

Any place where an AI agent can act, there needs to be identity, policy, accountability, and proof.

Sovereign by Design

CLAIIM is designed to run in the customer’s own environment.

That means:

your database
your policies
your agent records
your audit trail
your infrastructure boundary

Nivaya does not need to receive your agent activity data for CLAIIM to work.

That matters for organizations that care about data residency, regulatory boundaries, internal confidentiality, or customer trust.

Public Preview

CLAIIM is currently in public preview.

The preview is for teams exploring how to govern AI agents before those agents become deeply embedded in business workflows.

It is especially relevant if you are working on:

AI agent platforms
internal copilots
DevOps automation
support automation
finance workflows
regulated AI systems
security and compliance programs

The goal of the preview is simple:

Help teams test the control model early, before agent sprawl becomes another unmanaged identity problem.

Try It

Website: https://claiim.io

Contact: support@claiim.io

If you are already asking questions like:

“Which agents are running in our organization?”
“Who owns them?”
“What are they allowed to do?”
“Can we prove what happened?”
“Can we block risky actions before they execute?”

Then CLAIIM is probably worth a look.

AI agents are becoming actors inside organizations.

They need identity.

They need boundaries.

They need accountability.

They need proof.

That is what CLAIIM is for.

Everyone Is Building AI. Nobody Is Governing It.

Srinivas Kondepudi — Thu, 11 Jun 2026 17:29:05 +0000

Every week there is a new model. A new product. A new funding round.

And almost none of it comes with a serious answer to this question:

Is your AI actually governed?

Not "do you have a policy?", everyone has a policy. I mean: can you prove, from your live systems, which AI tools your employees are actually using, whether sensitive data is reaching consumer AI accounts, and whether your acceptable use policy is being followed in practice?

Most organisations cannot. Most teams cannot. The evidence is not there.

I have been building on this problem for the past couple of years. Four products, one principle:

Is your AI compliant and governed?

Nitivai, connects to your live environment (identity providers, cloud, AI APIs, endpoints) and surfaces your AI governance posture as verifiable evidence, not a questionnaire. Mapped to EU AI Act, ISO 42001, ISO 27001, SOC 2, and NIVAI-AGF.

NIVAI, the independent certification body that published NIVAI-AGF framework, with an auditor pool we just launched.

CLAIIM, sovereign identity and control plane for AI agents. As agentic AI proliferates, the question shifts from "which tools are your employees using" to "which agents are acting on behalf of your organisation, with what permissions, and with what audit trail."

Chron, audit-quality logging for every AI conversation, locally deployed. Your conversations. Your database. Nothing leaving your environment.

The race to build AI is real. The race to govern it has barely started.

And one day, sooner than most teams expect, a user, a customer, a regulator is going to ask: are you feeding my personal data stored in your apps to AI?

What is your answer?

Genuinely curious what the developer community thinks. Are you seeing governance and compliance come up in the products you are building? Or is it still treated as an afterthought?

How to stream Claude Code audit logs into Microsoft Sentinel (with Chron)

Srinivas Kondepudi — Tue, 26 May 2026 15:41:50 +0000

If your team uses Claude Code (or any MCP-based AI tool), those sessions are currently invisible to your security stack. No SIEM events. No audit trail. Nothing.

Chron fixes that. It's an MCP server that logs every AI session to a local SQLite database and can relay structured metadata events to your SIEM. This post walks through the Azure Sentinel integration end to end.

What gets logged

Chron transmits metadata only, never message content:

Event Fields
session_started session ID prefix, AI tool, timestamp, OS
message_logged role (user/assistant), session ID prefix
secret_detected detection type, masked value
Prerequisites

Chron installed (npm install -g chron-mcp or via npx)
Azure subscription with a Log Analytics workspace
App Registration with a client secret
Azure setup (5 steps)

Create a Data Collection Endpoint (DCE) — Azure Portal > Monitor > Data Collection Endpoints > Create
Create a custom table — Log Analytics workspace > Tables > Create > New custom log (MMA-based) — name it ChronEvents_CL, add columns: EventType, SessionIdPrefix, AiTool, OS, ChronVersion, Computer, Role, DetectionType, MaskedValue (all string type)
Create a Data Collection Rule (DCR) — Monitor > Data Collection Rules > Create, point the stream Custom-ChronEvents_CL to your workspace table
Assign role — on the DCR resource, add your App Registration as Monitoring Metrics Publisher
Note down your Tenant ID, Client ID, Client Secret, DCE URL, and DCR Immutable ID (starts with dcr-)

Connect Chron
chron connect sentinel

The CLI prompts for your credentials, authenticates against Azure AD, sends a test event, and patches ~/.claude.json automatically. You should see the test event in Log Analytics within 5-10 minutes (first ingestion into a new custom table can take up to 15 min).

Verify in Log Analytics

ChronEvents_CL
| order by TimeGenerated desc
| take 10

If the table doesn't appear yet, check the DCR > Monitoring tab for ingestion errors. The most common issue is a missing Monitoring Metrics Publisher role on the DCR (not the workspace).

What you get

Once connected, every Claude Code session generates a real-time stream of events in your Sentinel workspace. You can build workbooks, alerts, and hunting queries on top of it — e.g. alert when EventType == "secret_detected", or track AI tool adoption across your org by machine ID.

Issues can be logged here: https://github.com/SirinivasK/chron

How I wired chron into CrowdStrike LogScale - and shipped 5 dashboards with it

Srinivas Kondepudi — Mon, 18 May 2026 15:12:03 +0000

In my first post I wrote about why I built chron, an MCP server that logs every AI conversation to local SQLite. This one is about what I built next: streaming those events into CrowdStrike LogScale so security teams can see AI activity across their org.

The problem with local-only logging
chron stores everything locally. That's good for individuals, your data, your machine, no cloud. But for an org with 50 developers all using Claude or Cursor, "local SQLite per machine" doesn't give anyone a picture of what's happening org wide.

Security teams need a centralized view. And they already have one: their SIEM.

Why LogScale (Humio)
CrowdStrike acquired Humio in 2021 and rebranded it LogScale. It's one of the fastest log ingestion systems available, and it's already deployed at most enterprises that take security seriously. If I could get chron events into LogScale, I'd be sending data somewhere security teams already look.

LogScale has a clean structured ingest API. You POST an array of events, each with a timestamp and key-value attributes. No schema to define upfront, it's schema less by default.

The relay design
I wanted the integration to be genuinely zero-friction for chron's critical path. Logging a message should never slow down because the relay is having a bad day.

The solution: fire-and-forget via setImmediate.

export function emitEvent(payload: ChronEventPayload): void {
const url = process.env.CHRON_LOGSCALE_URL;
const token = process.env.CHRON_LOGSCALE_TOKEN;
if (!url || !token) return;

setImmediate(() =>
fetch(url, {
method: 'POST',
headers: {
'Authorization': Bearer ${token},
'Content-Type': 'application/json',
},
body: buildLogScalePayload(payload),
}).catch(() => undefined)
);
}
setImmediate pushes the fetch to the next iteration of the event loop, after the current operation completes. The .catch(() => undefined) means a failed relay never surfaces as an error. The audit log always writes to local SQLite first. The relay is best effort.

Three event types
chron emits exactly three event types to LogScale:

session_started - when a new AI session begins. Includes the AI tool name and an anonymized machine ID (SHA-256 of hostname, truncated to 16 chars).

message_logged - when a message is recorded. Includes role (user/assistant), timestamp, session prefix. Message content never leaves the machine.

secret_detected - when the auto-scanner finds a credential in a user message. Includes detection type (aws_key, github_token, etc.) and a masked value. The real value stays local.

That last point matters: chron's secret detection is designed to alert without exfiltrating. The masked value in LogScale tells the CISO "a GitHub token appeared in a developer's AI prompt on this machine at this time." The token itself is not in LogScale.

The connect CLI
Getting the credentials set up should be one command, not a documentation page.

chron connect crowdstrike
This prompts for your LogScale URL and ingest token, sends a real test event, validates the HTTP 200 response, and saves the config to ~/.chron/config.json. It also prints the exact env block to paste into ~/.claude.json so the credentials load automatically on every Claude Code session.

Five dashboards, ready to import
The hardest part of a new data source isn't the ingest — it's getting useful queries in front of the people who need them. I shipped five LQL queries and one importable dashboard YAML with chron 0.1.14.

The dashboard covers:

AI tool usage by count (which tools are developers actually using)
Daily active developers by machine
Sessions per developer
Secret detections by type over time
API key alert query for scheduled SOC alerting
Import the YAML into LogScale and all five widgets are live. If you have chron running on even one machine, you'll see data immediately.

What's next
The relay currently supports LogScale and a generic HTTP endpoint (CHRON_RELAY_URL). Splunk, Elastic, and Datadog integrations are on the roadmap, the event schema is the same, just different destination formats.

If you're running LogScale and want to try it:

npx -y chron-mcp
chron connect crowdstrike
Restart Claude Code or Cursor, have a conversation, and watch the events appear in your LogScale stream.

github.com/sirinivask/chron

I built an MCP server to log every AI conversation, here's what I learned

Srinivas Kondepudi — Wed, 13 May 2026 17:47:43 +0000

Every serious system gets audited; databases, code, finances. AI shouldn't be the exception. I'm building the tools to close that gap. chron is the first one.

The problem

I was doing long coding sessions with Claude. We'd work through a problem, make decisions, figure out an approach together. Then the context window fills up. It resets. And suddenly the AI has forgotten everything, but I still need to know what we decided and why.

I wanted a permanent local record. Not stored in some cloud. Not owned by any AI company. Just mine, on my machine, in a format I can actually read.

What is MCP?
MCP (Model Context Protocol) is an open standard from Anthropic that lets you extend Claude with custom tools. Think of it like a plugin system, you build a server that exposes tools, Claude learns to call them, and suddenly your AI can do things it couldn't before.

I'd never built one before. This was my first.

Turns out it's simpler than it sounds. You define a tool with three things:

A name Claude can call
A description Claude reads to know when to use it
An input schema so Claude knows what arguments to pass
That's it. Claude figures out the rest.

What I built
chron; an MCP server that automatically logs every AI conversation to a local SQLite database. Every message. Every timestamp. Fully yours.

npx -y chron-mcp
Run that once in your terminal. It detects which AI tools you have installed, Claude Desktop, Claude Code, Cursor, Windsurf, and configures them automatically. Restart your AI tool. Done. Everything gets logged from that point on, with zero manual steps.

Three things I built that were interesting

Hash chaining

Each message stores a SHA-256 hash that includes the previous message's hash, same idea as a blockchain, but much simpler. It means you can verify the log hasn't been tampered with. If anyone edits an old message, every hash after it breaks.

message 1: hash(content) → abc123
message 2: hash(content + abc123) → def456
message 3: hash(content + def456) → ghi789
Run verify_session and chron walks the chain. Any break means tampering.

Auto-setup

The hardest part of building an MCP server isn't the server, it's getting people to install it. Writing JSON config files by hand is a real barrier.

So npx -y chron-mcp now does it automatically. It reads your filesystem, detects which AI clients are installed, writes their config files, and installs a SessionStart hook in Claude Code so the logging skill loads on every new session. One command, restart, works.

The SessionStart hook

Claude Code has a hook system; shell commands that run automatically at session start. I use this to inject the chron skill instructions so Claude knows to call the logging tools without you doing anything. This was the missing piece. Without it, the MCP server is registered but idle.

What surprised me
The install experience is harder than the feature itself. Getting the MCP server running took a day. Getting it to work without any user configuration took a week.

Also: npm download counts are mostly bots. chron crossed 1,000 downloads in the first week, but honest estimate is maybe 50–150 real humans. Security scanners and registry mirrors download every new package automatically. Worth knowing before you celebrate.

What's next
The data is locked in SQLite right now. The next step is a local web UI — npx chron-mcp --ui opens a browser showing your sessions, messages, and stats. If AI is doing real work, you should be able to read the log without writing SQL.

If you use Claude, Cursor, or Windsurf and you care about keeping a record of your AI conversations, give it a try.

npx -y chron-mcp
GitHub: github.com/sirinivask/chron

I'm happy to answer questions about building MCP servers, it's genuinely worth learning right now.