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

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

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

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 [email protected] 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: [email protected], email with your GitHub username and we will enable package access.