Enterprise AI control & assurance

Keep your AI.
Control what it can do.

EcoKure is an independent control and verification layer for AI-enabled systems. Add deterministic checks, bounded authority and auditable evidence to the applications, agents and workflows you already run, without replacing them.

  • Patent-pending DTL
  • Model-agnostic
  • Decisions you can replay
See EcoKure in action →
Loading Zenya’s 3D avatar…
Meet Zenya.Your EcoKure guide

The problem

A confident answer is not
permission to act.

AI can now take actions across payments, records, infrastructure and code. A model's confidence tells you how sure it is. It does not tell you whether the output is correct, or whether anyone authorised the action.

  1. 1Generate

    A model drafts an answer or proposes an action.

  2. 2Validate

    Independent, deterministic checks confirm what can be confirmed, and say clearly what can't.

  3. 3Authorise

    A policy, and a person when needed, decides whether this action may happen here and now.

Most AI safety tooling stops at step 1 or 2. EcoKure is built around keeping step 3 separate.

How EcoKure works

Four steps at every
sensitive action boundary.

  1. 01AI proposes

    A model, agent or workflow asks to do something: read a record, pay an invoice, run a tool.

  2. 02EcoKure evaluates

    It checks the request against policy, scope, evidence and who holds authority.

  3. 03Allow, deny or escalate

    Clear cases are decided. Uncertain or high-consequence ones go to a person, or EcoKure abstains.

  4. 04The decision is recorded

    What was checked, what was decided and its limits are kept for replay and review.

This is the design. How much of it is live depends on the integration path. Some verifiers and gateway components are still at pilot or development stage, and the Gateway page shows which.

EcoKure Control Tower

See the whole system,
and what each part does.

Follow each request from your AI to your systems. Select any part to see its job, what it holds, and what it will never do.

Illustrative · synthetic stream
Control Tower · demo workspace

Select a part of the system

Every request takes the same path.

The stream below replays synthetic requests. Watch which parts each one passes through, and where it stops.

Decisions0
Allowed0
Denied0
Escalated0
Abstained0

Counts from this demo stream only.

Recent decisions in the demo stream
TimeSystemRequestDecisionWhy

A demonstration of the architecture with synthetic requests. It is not a customer deployment, a live feed or a measured result. How it connects to your systems →

Enterprise integration

Works with what
you already use.

You keep your applications, models, data and workflows. EcoKure sits at the points where an AI-driven request turns into a real action, and checks it before it reaches your APIs, databases and tools.

  • Model-agnostic: it checks the action, not the model
  • Your data stays under your ownership and control
  • Start with one workflow, not a platform migration
  • Customer-controlled deployment is part of the design
See the three integration paths →
Where EcoKure sits Existing AI models, agents and enterprise applications send proposed actions to the EcoKure verification and authority boundary. It checks policy, identity, evidence and approval, then allows, denies or escalates the action before it reaches existing APIs, databases and tools. Every decision is recorded. YOU KEEP AI models Agents & copilots Business applications Workflows & scripts proposed action EcoKure boundary verification & authority Policy Identity & scope Evidence Approval Allow · Deny · Escalate Decision record · replayable only permitted actions pass YOU KEEP Enterprise APIs Databases Tools & services Payments & records
Your models, data and workflows stay where they are. EcoKure adds a checked decision point in front of the actions that matter.

Integration paths

One architecture.
Three ways to connect.

Not sure which? Start in evaluation mode, add the SDK at one call site, or put the Gateway in front of many agents and tools. All three use the same checks and produce the same evidence.

A request within policy: all three paths let it through and keep a record.A request outside policy: the SDK check and the Gateway refuse it. Evaluation mode lets it run, and records that it would have refused.

ALLOWDENY YOUR APPLICATION call site without a check · not covered AI agent EcoKure check Yoursystems receivednot reached EVIDENCE ALLOW · record keptDENY · outside policy · record kept request
Inside your code

Path 1

API / SDK integration

Developers call EcoKure verification and authorisation checks at chosen points inside existing software.

Best for engineering teams adding checks at specific points inside their own software.

Integration kit available · pilot stage

Read the integration kit →
ALLOWDENY Agent AI agent Agent EcoKuregateway direct route removed Yoursystems receivednot reached EVIDENCE ALLOW · record keptDENY · outside policy · record kept request
In the path

Path 2

Enterprise Gateway

EcoKure sits between AI-driven workflows and sensitive execution interfaces such as tools, APIs and consequential operations, and mediates every call through it.

Best for platform, security and AI teams that want one enforcement point across many agents and tools.

Mediation tested in the lab · enterprise gateway in development

Explore the Gateway →
WOULD ALLOWWOULD DENY runs as normal AI agent EcoKure · observing Yoursystems ranran anyway EVIDENCE Would have allowed · record keptWould have denied · record kept request
Beside the path

Path 3

Evaluation mode

EcoKure evaluates selected workflows alongside production and records what it would have decided, with no change to execution.

Does not prevent anything. Observation only.

Best for teams that want to see what EcoKure would decide before changing anything in production.

Usable for pilots

How a pilot starts →

Illustration only. It shows where each path places the decision, not a recorded run.

Industry demonstrations

One architecture. Many industries.
Verifiable decisions.

The same mechanisms of scope, deterministic checks, independent approval and recorded evidence, shown in different settings. Each card says honestly how far the example has been taken.

How to read our labels

  • PublishedEvidence you can open, and often run, on this site.
  • Recorded exampleA real run, captured. Not a live query.
  • Internal lab testTested by us. The public write-up isn't out yet.
  • Synthetic scenarioA worked example of the mechanism on made-up data.
  • ConceptA part that still has to be built.
Illustration

Public knowledge

A researched answer, held until a person signs it

Recorded example

HOLDMachine checks passed. Held for human review.
Case detail
The problem
An AI answer combines a sourced fact with a calculation. A confident model is not the same as a checked answer.
Proposed action
Publish "The Eiffel Tower is 330 m, about 1,083 ft" as a reusable answer.
What can be checked independently
The arithmetic is recomputed exactly in your browser; the source sentence is re-read on recompute.
Illustration

Financial services

A payment run that tries to pay an invoice twice

Synthetic scenario

DENYDeterministic match against the paid ledger. Payment withheld.
Case detail
The problem
An automated accounts-payable agent queues an invoice that the ledger already shows as paid.
Proposed action
Pay invoice INV-2207 (synthetic) a second time.
What can be checked independently
Matching rule, ledger snapshot hash and decision record.
Illustration

Healthcare

A clinical assistant reaching outside its patient scope

Synthetic scenario

ESCALATEOut of scope. Request blocked and routed to a named clinician.
Case detail
The problem
An assistant scoped to one patient episode requests a record belonging to a different patient.
Proposed action
Read record P-0093 (synthetic) for a session scoped to P-0041.
What can be checked independently
Scope grant, request and escalation record.
Evidence on this site
None yet. This is a worked example on synthetic data, not a deployment.
Illustration

Energy & infrastructure

A cheaper grid dispatch that fails a contingency check

Synthetic scenario

ABSTAINConstraint could not be shown to hold. No automatic approval.
Case detail
The problem
An optimiser proposes a lower-cost dispatch. Under one line outage the plan overloads a transformer.
Proposed action
Apply dispatch plan D-17 (synthetic) to the next interval.
What can be checked independently
Constraint set, the failing contingency and the abstention reason.
Evidence on this site
None yet. This is a worked example on synthetic data, not a deployment.
Illustration

AI agents

An isolated worker that can propose but cannot commit

Internal lab test

DENYThe worker holds no signing authority. Proposal queued for an independent approver.
Case detail
The problem
A coding agent drafts a change. It must not sign, merge or execute the change itself.
Proposed action
Commit and sign a generated change from inside the sandbox.
What can be checked independently
Capability grant, denied call and signed approval receipt.
Evidence on this site
Tested internally. The public write-up is not published yet.
Illustration

Government

A retrieval agent retrying a denied resource another way

Concept ? not built

DENYThe earlier denial binds every route to the resource, provided no bypass path exists.
Case detail
The problem
After one denial, an information-retrieval agent tries a different tool to reach the same restricted file.
Proposed action
Fetch restricted document R-12 (synthetic) via an alternative connector.
What can be checked independently
Denial record and the second, refused route.
Evidence on this site
None. The gateway route this case needs is not built yet.

Every case uses synthetic data and none is a customer deployment. "Synthetic scenario" means a worked example of the mechanism; "Concept" means a component it needs is still to be built.

Lighthouse · reuse economics

Don't repeat the work.
Recheck the evidence.

When an answer has been checked, the next person who asks shouldn't pay for the whole investigation again. Lighthouse keeps the checks, sources and recompute recipe with the answer. Revalidating is then mostly arithmetic and re-reading, and the review status stays visible throughout.

Lighthouse recordRecorded example · not a live query
Awaiting human review

Question

“How tall is the Eiffel Tower, calculate 330 × 3.28084 and then write a short brief.”

Candidate answer

The Eiffel Tower stands 330 metres tall including its antenna1. That is about 1,083 feet2.

Captured
18 Oct 2026
Produced by
JARVI3 search
Machine checks
4 of 4 passed
Human sign-off
Not signed
Record ID
Not recorded in this example
Content digest SHA-256, computed in your browser
computing…
  1. Machine checks passed
  2. Awaiting human review
  3. Approved & signed

Not signed. Nobody has approved this answer yet. Other possible outcomes are Rejected, or Expired if a source changes and the answer needs revalidating.

CheckEngineWhat was testedResult
Factual supportATLASEach claim in the brief against the cited sourcesPass 4 claims supported
CalculationSIGMA330 × 3.28084 in exact rational arithmeticPass 2706693/2500; SuperMath and an exact re-run agree
Citation mappingHERALDEvery figure in the brief maps to a checked resultPass All figures trace
Source still currentrecomputeRe-read the cited sentence on toureiffel.parisPass Still states 330 m at last recompute
Human sign-offreviewerAn authorised person accepts this exact evidence versionPending Not signed

Not covered by this record: whether the answer may be reused under a given policy. That is decided at sign-off, not by the machine checks.

Visitors can't approve or reject records. Only authorised reviewers can sign, and a signature is tied to this exact evidence version.

Reuse so far Demo-reported

Reuses
3
Tokens avoided
~4,210
Web searches avoided
3

Reuse simulator

What if 10,000 people asked the same checked question?

Illustrative · not recorded traffic
Equivalent requests
10,000
Assumptions (edit them)
Total requests
10,000
Initial generations
1
Not eligible
0
Eligible reuses
9,999
Estimated tokens avoided
14,028,597
Web searches avoided
9,999
Model tokens needed for every request, by approach
ApproachModel tokensWhat you know about the reused answer
Re-run the full AI workflow each time14,030,000Nothing carries over. Every answer is new and unchecked.
Conventional response cache1,403The same bytes as last time. No source recheck, review state or evidence.
EcoKure governed reuse1,403Recomputed figures, re-read sources, a visible review state and versioned evidence.

To be clear: on compute alone, a well-built cache saves about as much as EcoKure does. What EcoKure adds is control over whether an answer may be reused, and a record of why.

Formulas and labels
  • Eligible reuses = total requests − initial generations − ineligible requests
  • Net tokens avoided = eligible reuses × (tokens avoided per reuse − revalidation tokens per reuse)
  • Measured: nothing on this panel. No logged provider token usage is shown here.
  • Estimated: 1,403 tokens per reuse, from the demo's own counter (~4,210 tokens over 3 reuses). Revalidation defaults to 0 because the recompute recipe uses no model; storage and retrieval costs are not counted. Web searches assume one avoided search per reuse (3 over 3 reuses in the demo).
  • Illustrative: the request count. Nobody has sent 10,000 equivalent requests.
  • No cost in dollars is shown, because no documented pricing assumption sits behind it. Real savings depend on whether questions are truly equivalent, review status, source freshness and the baseline you compare against.

Technical evidence

What has actually been
demonstrated.

For engineering and security reviewers. Each line says where the evidence lives. Staged tests show that a mechanism works. They are not completed enterprise deployments, and EcoKure holds no independent certification.

Change controlRecorded run

Selective replay

98.305%

records avoided during replay

1,000,000 records · 16,950 affected · 983,050 preserved.

Scope, version & reproducibility

Synthetic in-process benchmark. It is not a production SLO, certification, customer result or comparison against Temporal/Camunda.

Version / run
selective-replay-benchmark-v1
Environment
{"python": "3.11.9", "platform": "Windows-10-10.0.26200-SP0", "machine": "AMD64", "processor": "AMD64 Family 25 Model 120 Stepping 0, AuthenticAMD", "cpu_count": 12, "workers": 8}
Source SHA-256
7bab808208b5dcff53e84f52ca96abe5ae61588f964f9908ef7915c3bee99180

Inspect the original record for the method and negative outcomes. Reproduce within its declared scope before evaluating another environment.

Change & evidenceRecorded run

Dependency-aware change control

5,000

synthetic iterations recorded

7/7 declared checks passed. Replayable affected work is recalculated; unknown provenance and human judgement are held for review.

Scope, version & reproducibility

Local AML/CTF threshold-change fixture with a declared dependency graph. This is not a customer deployment, legal interpretation or proof of completeness for an unknown graph.

Version / run
EV-02/EV-07 synthetic executable change-control simulation
Environment
Internal / local synthetic run; hardware details not recorded in this file
Source SHA-256
94da96957c2bece6d3921f8347715b3e5ab394fa9098a013ef352884bc962041

Inspect the original record for the method and negative outcomes. Reproduce within its declared scope before evaluating another environment.

VerificationRecorded run

MathGate

5,945

incorrect arithmetic claims blocked

20,000 synthetic cases · 2,987 abstentions · 0 incorrect claims missed.

Scope, version & reproducibility

The gate checks that a claimed result equals the expression it is claimed for. It does not check that the expression is the right expression, and an exactly-correct answer to the wrong question passes. Anything outside its four-operator grammar is abstained rather than passed, and that count is reported rather than folded into the refusals. The expression is parsed, never executed. Synthetic cases.

Version / run
Version not recorded in this file
Environment
Internal / local synthetic run; hardware details not recorded in this file
Source SHA-256
cff3a85261f90c7ff8d5c75b9d146c0eb3722325beca6346e31564c10930d9a8

Inspect the original record for the method and negative outcomes. Reproduce within its declared scope before evaluating another environment.

Recorded internal and local synthetic measurements, each linked to its scope, version and limitations. All results and sources →

Evidence at a glance

Published on this site
2
Internal lab tests
3
Independent certifications
0

Counts of the items in this list. Recorded measurements are in the result cards above.

Deterministic verification (E-stack, DTL)Published

Gate decisions are deterministic and replayable: the same inputs and Control Pack give the same verdict, and gates abstain instead of guessing. The DTL mechanisms are patent pending (Australian provisional applications). Evidence register → · Architecture →

Signed evidence, replay and offline verificationPublished

Decision records can be exported and checked outside the product. Run the synthetic demo → · What we have tested →

Guardian and broker boundaries · AppContainer worker isolationInternal lab test

A sandboxed worker can generate proposals but holds no signing or commit authority; a separate broker mediates its tool calls. Tested on Windows in the lab. The public write-up has not been published yet.

Windows service-rights verification · TPM/CNG approver signingInternal lab test

Service privileges were checked against the intended least-privilege set, and approver signatures were produced with a key held in the TPM. The TPM work is integration evidence with a test key. Live approver enrolment has not been completed.

Routing and model-call efficiency comparisonsInternal lab test

Comparisons of routed and checked workflows against repeated model calls. Read them next to the reuse simulator above: a plain cache can match the compute savings, so we never present compute savings as EcoKure's only advantage.

Not claimed: independent certification, clinical validation, universal compatibility, or that EcoKure would have prevented any specific past incident. Security overview →

Enterprise pilot

Start with one workflow.
Verify the controls.
Expand with evidence.

Pick one AI-enabled workflow and one action boundary, and agree in advance what success means. We run EcoKure against it with synthetic or sanitised data and report the failures alongside the wins.