The assurance layer for AI execution
K3rnel is governance software for AI agents that touch money, records and infrastructure. Operations and risk teams use it to set the rules an agent must satisfy, block anything that does not, and produce a signed, replayable record of every action taken.
Private beta · Apache-2.0 open core · Cloud, VPC or on-premise
Operations and risk teams watch runs, write the policies those runs are checked against, and pull the signed record of any action after the fact.
Monitor
Govern
Workspace
Northwind Bank · Production
Assurance posture across every automated workflow.
Runs certified
+12.4% · vs last week
Certified rate
+0.6 pts · vs last week
Actions refused
+38 · none reached production
Median run time
−7.2% · vs last week
Every certified run is replayable for 7 years.
| Workflow | Business unit | Outcome | Started | Time |
|---|---|---|---|---|
| process_refund@3 | Northwind Bank | Certified | 14:22:07 | 1.9s |
| claims_intake@7 | Meridian Health | Running | 14:21:54 | — |
| reply_router@2 | Acme Retail | Refused | 14:20:31 | 0.4s |
| update_address@2 | Northwind Bank | Certified | 14:19:02 | 0.4s |
| issue_credit@1 | Acme Retail | Needs approval | 14:18:12 | 0.3s |
| disburse_payout@4 | Northwind Bank | Certified | 14:16:47 | 2.4s |
Monitor
Govern
Workspace
Runs / process_refund@3
Certified run · Northwind Bank · Production
A refund request arrived from the customer support inbox for order #18223.
The request matched process_refund, version 3 — the version currently approved for production.
Amount of $240.00 is within the $500 auto-approval limit for this account tier. Payee matched the account on file.
$240.00 returned to the original payment method. No other account field was written.
Confirmation sent to the address on the account. Run sealed and certificate written.
Monitor
Govern
Workspace
Govern / Policies
Rules every run is checked against before it is allowed to act.
| Policy | Applies to | Approver | Limit | Status |
|---|---|---|---|---|
| Refund ceiling | process_refund | Auto | $500.00 | Active |
| Named approver above ceiling | process_refund | Risk & Controls | $500.00+ | Active |
| Payee must match account | All payment workflows | Auto | — | Active |
| No writes outside the request | All workflows | Auto | — | Active |
| Business hours only | disburse_payout | Auto | 09:00–17:00 | Active |
| Bulk credit review | issue_credit | Finance | 25 / day | Draft |
WHEN a refund is requested AND amount is over $500.00 THEN hold for a named approver ELSE refuse, and record why
A policy that cannot be evaluated is treated as a failure. There is no configuration in which an unchecked run proceeds.
Monitor
Govern
Workspace
Certificates / cert_8f31…
Re-run a past execution and compare it against the original.
| Field | Result |
|---|---|
| Workflow version | Identical |
| Inputs | Identical |
| Policy decisions | Identical |
| Actions taken | Identical |
| Timestamp | Differs — expected |
An execution you cannot reproduce is a description of what happened. One you can re-run is evidence.
The pattern is always the same: a task that is repetitive enough to automate, and consequential enough that someone will eventually ask what happened.
Financial services
Healthcare and insurance
Customer operations
Internal platform
Write limits, scopes, approvers and time windows once. They are enforced on every run — there is no path that skips them.
Route anything above a threshold to a named person or team. The run holds rather than proceeding and being reversed later.
Every run ends with a signed record of the workflow, its version, the decision reached and the actions taken.
Re-execute any past run and get the same result, so an incident review shows what happened instead of estimating it.
Export runs, decisions and certificates over any date range for auditors, regulators or a customer's security team.
Scope who can author workflows, who can change policy and who can approve. Changes to policy are themselves recorded.
SAML and OIDC single sign-on with directory-based provisioning, so access follows the systems you already run.
Managed cloud, your own VPC, or fully on-premise and air-gapped, for workloads that cannot leave your network.
Keep the agent framework and models you already use. K3rnel sits between what you built and the systems it acts on.
The creative, risky work happens once — before anything touches your systems. What runs afterwards is ordinary, reviewable software.
A model reads your intent once, offline, and produces a fixed plan you can open and read. It is a document, not a conversation — the same input yields the same plan, and the plan is what ships.
Before a single action is taken, the plan is checked against your policies and constraints. Anything that cannot be shown to hold is refused outright rather than attempted and rolled back.
Only the plan that passed runs, and it runs deterministically. Every execution ends by writing a signed certificate recording exactly what was approved and what happened.
Prompt an agent, watch it work, and the demo is genuinely impressive. Put it in front of a customer's money and the question changes shape entirely. Not can it do this, but what exactly will it do, who approved that, and what happens the day it is wrong.
The industry's answer so far has been to watch more closely. Log every step, score every output, add a guardrail model to check the first model, and escalate when confidence drops. All of it is inspection after the fact — a way of noticing that something went wrong slightly faster than a customer would have.
Inspection cannot produce a guarantee. If the decision about what an agent may do is made in the same breath as the doing, there is no earlier moment to point at and no artefact to review. Nothing can be signed, because there was never a fixed thing to sign.
So move the decision. Let the model do its thinking once, up front, and commit the result to something concrete enough to be read, checked and approved. Then let ordinary software carry it out. The creativity stays; the uncertainty leaves the runtime.
K3rnel is not a framework you rebuild on top of, and not a model you swap in. It is a layer your existing agents call through — so the systems on the far side only ever see verified, attributable actions.
Whatever you already build with. K3rnel does not ask you to change how your agents are written.
Intent is fixed into a plan, the plan is checked, and only what passed is carried out.
Every run produces a durable record: what was approved, what ran, and the result.
Databases, payment rails, ticketing, internal APIs — reached only through actions that were verified first.
No. K3rnel sits between what you already built and the systems it acts on. Your agents keep their framework, their prompts and their tools.
What changes is the boundary: instead of an agent reaching your database directly, it reaches it through a plan that was verified first.
Not on the path that decides whether something is allowed to happen. The model does its work up front, when the plan is compiled.
That is the whole point. A run that depends on a model responding correctly under load, in the moment, is a run you cannot make promises about.
It is refused. K3rnel fails closed: an error, a timeout, an unclear result and a genuine policy violation all end the same way, with the action not taken.
Refusals are recorded as first-class outcomes with a reason attached, so a rejected run is something you can investigate rather than something you have to reconstruct.
The plan that ran, its version, when it ran, the decision that was reached, and a signature over all of it.
It is designed to be useful to somebody who was not there and does not trust you — an auditor, a regulator, a customer's security team.
The ability to re-run a past execution and get the same result, rather than an approximation of it.
In practice that is the difference between explaining an incident and arguing about it. You can show what happened instead of describing what probably happened.
Private beta. We are working with a small number of design partners running real workloads rather than opening a self-serve signup.
If your agents are close to touching something that matters, we would like to hear what you are trying to put into production.
Uncertainty is not a reason to proceed carefully. It is a reason to stop. Errors, timeouts and ambiguous results all resolve to the action not being taken — there is no configuration that makes the risky outcome the default.
There is no path where a plan runs because it looked fine, or because the check was slow, or because someone needed it shipped today. The verification step is not advisory and cannot be turned off for convenience.
An execution you cannot reproduce is a story, not a record. Runs are deterministic and signed so that months later, to someone who was not there, the evidence still holds up.
We are working with a small number of teams whose agents are about totouch something that matters. If that is you, get in touch.