Orkena
Demo

▸ ESSAY

What is a Governed Agent Runtime — Orkena

Uday, Founder, Orkena · 2026-08-16 · 12–15 min read

What is a Governed Agent Runtime

A category note, written from the seat of trying to sell this into a bank.

Uday, Founder, Orkena — 2026-08-16

The gap

Every regulated institution that has attempted to put AI agents into production has hit the same wall. The wall has three names, depending on who's asking.

The Chief Risk Officer calls it "we cannot prove what the agent did."

The Chief Compliance Officer calls it "we cannot satisfy Article 12, or DORA, or the internal model-risk policy, with a chat history."

The Head of Platform Engineering calls it "we glued five things together and now we own the seams."

They are describing the same defect from three angles. The defect is that agent workflows execute in a probabilistic runtime that was never designed to produce the deterministic evidence that regulated institutions require of any consequential system. What ships today are frameworks (LangGraph, CrewAI, AutoGen), model providers (Anthropic, OpenAI, Bedrock), observability platforms (Datadog, Weights & Biases, Arize), and governance dashboards (Credo AI, ValidMind). Every one of these is real. None of them, individually or together, produces the artifact a supervisor asks for: proof that the agent was authorized to do what it did, at the moment it did it, in a form that survives adversarial inspection.

Regulation is arriving on this gap. DORA is already in force in the EU as of January 2025. The EU AI Act's Annex III high-risk provisions apply from December 2027. ISO/IEC 42001 exists. NIST's AI Risk Management Framework exists. What all of these require, in their own vocabulary, is the same thing: a durable, verifiable trail that shows the agent's decision, its authorization, and its execution — bound together, tamper-evident, and reproducible on an examiner's machine without depending on the vendor being available.

This is not a small ask. And it is not one that a wrapper around a language model can meet.

The category the market keeps trying to invent

Because the gap is real and expensive, the market has proposed several category names for what fills it. Each is a partial answer:

  • AI Observability — sees what happened. Cannot prevent what should not.
  • AI Governance Platform — codifies the policy in a dashboard. Cannot enforce it in the transaction.
  • AI Compliance Suite — produces reports for the auditor. The reports are not the evidence.
  • AI Trust & Safety — screens outputs after generation. Too late for irreversible actions.
  • Agent Framework — makes the graph runnable. Assumes governance is somebody else's problem.
  • Model Gateway — sits in the inference path. Governs the model call, not the action the model triggered.

Each of these exists for a reason and does its job. None of them is the substrate for a regulated agent deployment. The substrate has to combine the runtime and the governance in one system, because the moment you separate them, the seam is where the assurance leaks.

We call this substrate a Governed Agent Runtime.

What a Governed Agent Runtime is

A Governed Agent Runtime is a runtime that executes agent workflows and enforces your controls as part of that execution — rather than reporting on them afterwards. Four properties define the category:

1. Authorization before execution, not observation after.

Every action an agent proposes — tool call, model call, credential use, edge traversal — is evaluated against policy-as-code before it reaches a system of record. A denial is a control that fired, not an incident that was noticed. The industry convention has been to observe and report; the regulated convention has to be to authorize and prevent. The two are not the same, and observability, no matter how thorough, cannot become authorization.

2. Evidence in the same transaction as the action.

The audit record is committed atomically with the step that produced it, into an append-only hash-chained ledger. There is no window in which an action exists without its evidence, and no path by which the record can be edited afterwards. If an examiner asks "did this happen, and was it authorized?", a runtime answers with a signed byte-string; a dashboard answers with a query. The two are not the same.

3. Reproducibility of any run, exactly.

Runs are event-sourced. Every non-deterministic interaction — model responses, tool results, timestamps — is captured. Any run can be replayed step by step; any run can be forked from any checkpoint to test what a different decision would have produced. This is not a "developer feature"; it is the primary artifact model-risk officers need to interrogate a decision after the fact. If you cannot show a regulator the exact conditions under which a decision was made, you do not have a case.

4. Change control gated by evaluation.

No version reaches production without passing its regression evaluation suite. When the system proposes a new operating rule for itself, from consolidated memory or self-learning, that rule stays inert until it passes the same suite and a human declines to veto it. This is what "controlled updates to an AI system" means when the language model is behind the interface; it is the equivalent of a change-advisory-board process, mechanized.

These four properties are what distinguish a Governed Agent Runtime from every category above. Each of them, taken alone, exists somewhere in the market. Bought and integrated separately, the six-to-twelve months of integration is the price you pay for the honesty of admitting they are not one system. The bet Orkena is making is that regulated institutions cannot afford that price for a technology this consequential, and that the category has to be built as one substrate.

The couplings that have to be in one system

The technical case for building a Governed Agent Runtime as a single system, rather than as an integration project, comes down to four couplings that cannot be broken without producing a seam:

  • Authorization and execution. If the policy engine is a network hop from the executor, the policy engine can be down, degraded, or bypassed. In a runtime, the authorization is a function call in the same process as the execution; the two cannot come apart.
  • Execution and evidence. If the audit log is a separate service, the log can be lost, delayed, tampered with, or diverge from the execution. In a runtime, the ledger commit and the execution commit are in the same transaction; there is no window in which the two can disagree.
  • Evidence and verification. If the audit log is a proprietary database, the auditor takes the vendor's word for it. In a runtime that produces signed hash-chained bundles with a dependency-free verifier, the auditor runs verify.py bundle.zip on their own machine and gets a byte-level answer.
  • Change and evaluation. If model updates ship without regression tests, drift is measured in production, not prevented. In a runtime where promotion is gated on evaluation, every version deployed has demonstrably passed its regression suite; you have a paper trail for every change.

Each coupling is achievable in code. None of them is achievable across a vendor boundary. That is the technical argument for the category.

What Orkena is, in this frame

Orkena is a Governed Agent Runtime — a single Python-and-TypeScript system that combines a durable executor, an in-process Cedar-native policy engine (Cedar's Rust evaluator via cedarpy bindings, schema-validated packs), a hash-chained per-tenant audit ledger with Ed25519-signed anchors, an offline verification bundle, evaluation-gated promotion, and cross-run memory consolidation with human veto. It ships today as a single Helm chart into customer VPC and air-gapped environments; a managed, region-pinned tier follows (2027+), at feature parity with the self-hosted modes.

It is not a wrapper around LangGraph, though LangGraph graphs can be imported. It is not an observability platform, though it emits OpenTelemetry. It is not a compliance dashboard, though it produces mapping evidence for DORA, EU AI Act Annex III, ISO/IEC 42001, and NIST AI RMF. It is the runtime you deploy agents onto when a regulator will eventually ask what the agent did, on what authority, and how you know.

What Orkena is not

Category clarity is easier when the boundary is explicit. Orkena is deliberately not several things:

  • Not a model provider. Orkena is model-agnostic across Anthropic, OpenAI, Azure OpenAI, and other providers. Bring your keys.
  • Not an observability replacement. Orkena integrates with your existing OTel + Datadog + Grafana stack. The ledger is not a log.
  • Not a compliance certifier. Orkena produces the runtime controls and the evidence that your certification and supervisory processes require. Certification is between you and your auditor.
  • Not a low-code agent builder for citizen developers. Orkena is sold to platform engineering, compliance, and risk teams; it is a system of infrastructure, not a democratization play.
  • Not a self-serve product. Contracts start at six figures. There is no free tier and no signup.

What has to change for this category to be real

Categories are not created by press releases. They are created when three things happen: buyers describe their problem using the category vocabulary, analysts define the category in their coverage, and vendors compete inside the category rather than around it.

None of these have happened yet for Governed Agent Runtime. Gartner's coverage is currently distributed across "AI TRiSM," "AI Governance Tools," and "Enterprise AI Assistant Platforms." Forrester has a "Trusted AI" cluster in the AI Landscape but not a Wave. IDC covers "AI Governance and Compliance." The vocabulary is fragmented.

For the category to consolidate, three things have to happen in the next twelve to eighteen months:

  1. Analysts have to coin or adopt the terminology. This is achieved by producing a category note, briefing the analysts personally, and having them find the framing useful enough to reuse. That work is starting.
  2. Reference buyers have to publicly use the vocabulary. This is achieved by shipping the category with a small number of design partners who face real regulatory examinations, and letting those examinations validate the category. That work is starting.
  3. Competitive vendors have to accept the framing. This is achieved by defining the category tightly enough that only vendors who do the four couplings above can claim membership. Vendors that do observability, or governance dashboards, or wrappers around a framework, will not fit — which is the point.

None of these are guaranteed. Categories fail more often than they succeed. But the regulatory pressure is real, the technical case is defensible, and the alternatives are visibly not working for the institutions that need this.

The honest state of the runtime today

Orkena is a pre-launch runtime, in engineering-prototype state, seeking a small number of design partners for 2026. The core substrate — durable executor, policy engine (Cedar-native via cedarpy, evaluated in-process at p50 110 µs / p99 352 µs), hash-chained ledger, signed anchors, offline verifier, evaluation-gated promotion, memory consolidation with veto — is functional and tested. The three-region high-availability posture is validated in a controlled test environment. The two self-hosted deployment modes (customer VPC, air-gap) are validated in dev; the managed (SaaS) tier is planned for 2027+.

What has not yet happened: no external audit has yet been completed against SOC 2, ISO 27001, or any other framework — a Type I audit is planned. No reference customer has yet run Orkena in production. Analyst coverage is not yet in place. The Cedar-native policy evaluator landed on 2026-08-16 (BE-17, cedarpy 4.8.7 over Cedar's Rust engine); the measured run above predates it and will be republished.

The honest register for Orkena today is: an engineering-first runtime, technically credible, seeking the pilots that will convert credibility into evidence. That is what a design-partner programme is for.

The reader you are

If you are a Chief Compliance Officer at a regulated institution, and the question in your head is "how do we put agents into production with the audit posture our supervisor will accept," the category above is what you are looking for. Whether Orkena is the vendor of that category for you is a conversation. Any of the alternatives — building it yourself, waiting for the market to consolidate, or accepting that agents cannot be deployed into regulated workflows this year — is also a valid answer, depending on your timelines.

If you are an analyst covering AI governance, and you are looking for the framing that separates the runtime substrate from the surrounding tools, the four couplings above are the load-bearing argument. It is deliberately narrow and deliberately falsifiable.

If you are a technical evaluator considering building this internally, the honest answer is that any single component — a durable executor, a policy engine, an audit ledger — is achievable. The hard problem is the integration and the deployment-mode parity across SaaS, VPC and air-gap. The bet Orkena is making is that the integration is more valuable than the components.

The next thirty minutes to a demo will tell you which of the above you are, and whether the runtime is real.

Contact: info@orkena.com · book a walkthrough at orkena.com/contact

Related reading on this site:

This is a category note. It represents the author's view on the state of the market as of the date above; it will be revised as regulation, analyst coverage, and vendor positioning evolve. Comments to info@orkena.com are read and often used to sharpen the argument.