DEV Community: Srinivas Kondepudi

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.