DEV Community

Cover image for Your AI agent just took an action in production. Can you answer five questions about it?
Srinivas Kondepudi
Srinivas Kondepudi

Posted on

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

#ai #security #governance #devops

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:

  1. Which agent took this action?
  2. Who is the human accountable for that agent?
  3. Was the action explicitly allowed before it ran?
  4. Which policy governed it?
  5. 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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)