CLAIIM: Governing AI Agents Before They Act

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: [e-mail]