We're Enabling SaaS for CLAIIM. Sovereignty Still Matters.

Trying an AI governance product should not require a production deployment decision on day one.

That is why we are enabling SaaS for CLAIIM: to give teams an easier way to explore the product, experiment with agent workflows, and understand where runtime governance fits before committing to a deployment.

But easier access should not make deployment control an afterthought.

SaaS is an easier way to start. Sovereignty remains a design priority.

This is a direction update, not a general-availability announcement or a promise that every hosting and residency option is already available.

The problem is bigger than another AI chat interface

An organization might use several AI tools across engineering, operations, and internal workflows. Giving everyone another place to chat does not, by itself, govern what those agents can do.

The harder questions begin when an agent wants to act:

• Who is accountable for this agent?
• What authority has it been delegated?
• Which policy applies to this action?
• Can it proceed, must it stop, or does it need human approval?
• What was actually observed afterward?

CLAIIM is the runtime governance layer for AI agents: establishing who is acting, what they may do, whether an action can proceed, and what evidence remains afterward.

The distinction matters: control the agent's capabilities and execution paths, not merely its conversation.

A prompt asking an agent not to deploy to production is an instruction. A deployment endpoint that rejects requests without the required authorization is a boundary.

What we want SaaS to make easier

Before a team evaluates governance infrastructure, it needs to see the workflow.

Our goal with SaaS is to reduce the setup needed to explore agent identities, skills, policies, approvals, and the evidence trail in the CLAIIM console.

A useful first experiment does not need production credentials. Start with a synthetic workflow and ask:

1. Can we identify the acting agent and the accountable human?
2. Can a policy distinguish routine work from sensitive work?
3. Can a sensitive request enter an approval workflow?
4. Can we follow the decision and recorded outcome afterward?

That gives developers and security teams something concrete to evaluate together, before connecting a real customer database or a deployment system.

It also makes an important conversation possible early: where should this run when it becomes part of our production environment?

A concrete example: an agent requests a deployment

Consider an agent preparing a release. The following is a conceptual workflow, not an SDK example or a claim that every deployment platform is integrated:

Agent requests an action
        |
        v
Resolve identity, delegated scope, and applicable policy
        |
        v
Runtime decision: ALLOW / DENY / HOLD
        |
        +-- DENY: reject the governed request
        |
        +-- HOLD: require the configured human approval
        |
        +-- ALLOW: permit the controlled execution path
                         |
                         v
                 Record the observed result

In CLAIIM, configured HOLD actions support human approval, including one-person or ordered two-person approval. That does not mean every action requires a human; the applicable policy determines when approval is needed.

There is another qualification that should never disappear in a product demo: an ALLOW or DENY decision is not automatically enforcement.

If the agent can bypass the governed path using another credential or an unrestricted network route, the organization has a policy decision, not a complete execution boundary. Stronger enforcement depends on the surrounding credential, tool, and infrastructure controls too.

Likewise, an HTTP success response is not independent proof that the intended downstream state exists. A recorded outcome and a verified outcome are different things.

Our governing rule is:

CLAIIM must never represent a decision as enforcement, or a reported outcome as verified evidence.

SaaS does not change that rule.

Sovereignty is more than a hosting label

For us, sovereignty means taking deployment and operational authority seriously. It requires concrete answers about:

• Where governance data is stored and processed.
• Who administers the deployment and can access its records.
• How credentials and sensitive inputs are handled.
• Which external services receive data.
• How retention, export, and deletion work.
• What happens when the governance service is unavailable.

Those are evaluation questions, not a list of capabilities we are claiming every SaaS configuration already satisfies.

A hosted trial may be a useful place to learn with synthetic data. Production adoption needs a separate assessment of the deployment, data flows, and enforcement paths involved.

Sovereign deployment remains a priority as we enable SaaS. Convenience should help a team discover the product, not silently decide its long-term trust model.

The console operates the governance layer

The CLAIIM console brings together agents, organizations, skills, policies, grants, governance packs, gateway configuration, users, access, approvals, Chron evidence, proof exports, and settings.

These screens help teams inspect and operate governance. They are not the boundary on their own.

The product direction remains:

The Runtime Gate is the product. The Console operates it. The Workspace is an optional experience built on it.

That keeps us focused on governed actions and evidence rather than competing to become everyone's universal AI interface.

Easier to try. Deliberate about trust.

We want teams to reach their first useful governance experiment sooner, then make an informed decision about production deployment.

That is the purpose of enabling SaaS for CLAIIM.

Make AI easy to try. Keep authority yours.

If you are evaluating agent governance, what would you test first: delegated authority, approval workflows, execution boundaries, or the evidence trail?

Learn more at claiim.io.