Every organization deploying AI in a regulated domain now has some form of governance. It is usually one of three things: a policy document, a monitoring dashboard, or a paragraph in a system prompt that asks the model to behave. Each has its place. None of them is a control, because none of them can stop an action that has already been decided.
EVE CoreGuard is what I built from the other direction. The thesis is one sentence long, and it is on the product page because it is the whole product: no governed AI action executes without proof.
Every action routed through CoreGuard is evaluated before it runs. What the governance corpus cannot defend is blocked. And every verdict — allow or block — is emitted as a cryptographically signed record, so the decision can be replayed and checked later by someone who does not trust the system that made it.
“We have a policy” is not a control
The distinction that matters is pre-execution versus post-hoc. A guardrail that logs what the model did is an audit trail; it is not a brake. If a lending model approves a loan, a trading agent places an order, or an agent calls an API with credentials, the interesting moment is the millisecond before the effect — and that is precisely the moment most governance tooling is not present for.
This is the argument I made in the piece on deterministic AI governance earlier this year: the enforcement point has to sit in the hot path, in front of the execution boundary. CoreGuard is that argument implemented — twice: once before the model call for input governance, and once before the tool call, transaction, or API action for agents.
Seven stages between intent and effect
The runtime resolves authority in a fixed sequence. Nothing about it is probabilistic, and that is deliberate: a verdict has to be the same verdict tomorrow, given the same inputs and the same corpus.
- Intercept — the proposed action is captured before it executes. Nothing has happened yet.
- Normalize — NFKC normalization and stakes classification, so the corpus evaluates a canonical form of the request rather than a string that can be dressed up to slip past a matcher.
- Enforce — the governance corpus is evaluated deterministically. Rules, not prompts; not heuristics, not a second model asked to referee the first one.
- CRD Score — Confidence-Reality Divergence. How far the model's stated confidence has drifted from what the evidence actually supports.
- Resolve — a canonical verdict:
ALLOW,BLOCK, orMODIFY. - Attest — the verdict is sealed with an ECDSA P-384 certificate and the hash chain advances.
- Dispatch — the approved action is released, and only after the proof is sealed.
That ordering is the design. Attestation happens before dispatch, not after, which means a released action always has a sealed verdict behind it. There is no window in which work is happening without a record of why it was permitted.
What gets signed, and why the signature matters
A log entry written by the same system that made the decision is an assertion about itself. CoreGuard's verdicts are hash-chained and signed, and the chain's integrity is computable without contacting EVE at all. That is the property regulators and auditors actually need: proof that survives the vendor.
eve-proof verify. Real signed records can be verified at evecore.com.The example above is instructive in what it does not say. It does not say “this action was probably fine.” It names the action and amount, the policy version it was evaluated against, the specific rules that passed, the divergence score, the signature, and the chain position — then it states that the certificate is valid because the signature matches, the chain is intact, and the decision is unaltered. Any party can run that check. They do not have to take EVE's word for it, which is the point.
The latency numbers, including the unflattering ones
Governance that sits in the hot path has to be fast, and this is where most vendors start rounding. So the benchmarks are published, with the outlier cases and the benchmark harness included.
- Policy evaluation alone — p50 0.006 ms, p99 0.015 ms at n=20,000. No signing, no evidence write, no network.
- Verdict derivation with binding — p50 0.09–0.12 ms, p95 0.17–0.33 ms at n=20,000.
- A 10-violation verdict — p95 0.73–1.19 ms, p99 1.3–4.7 ms. The stated conclusion is refreshingly blunt: this case is not reliably sub-millisecond.
- A full governed decision — adding hash-chain anchoring and evidence persistence: p50 17.6 ms at n=300.
Single host, highly load-sensitive, measured by a harness in the repository. The honest headline is that the policy check is microseconds and a complete signed, persisted decision is roughly 18 milliseconds. That is the real trade: you are buying provability, and provability costs a signature and a write. Pretending otherwise would be the exact failure mode the product exists to prevent.
What ships in the box
Governance corpora encode regulatory requirements as deterministic rules. Lending, healthcare, trading, and enterprise security corpora ship out of the box; enterprise corpora are available on contract. The point of a corpus is that a client is not authoring their own enforcement from a blank page and then discovering at audit time that a rule was worded as a suggestion.
Deployment is where the customer already runs: AWS Marketplace, Microsoft Azure Marketplace, and Google Cloud, with an appliance build in preview. There is a live demo, documentation, and a fixed-price assessment at the entry point. The trust page carries SOC 2 Type II, in progress — stated as in progress, which is the only honest way to state it before an audit is complete.
Where it honestly stops
I have written before that the useful question about an AI system is not whether it is impressive but whether a practitioner can defend it to an auditor, a regulator, or a customer. The same standard applies to the tool.
CoreGuard governs actions routed through it. An agent that bypasses the governed path is not governed, and no runtime can retroactively fix an architecture that gives a model an unguarded route to a transaction. The corporate philosophy is literally “the infrastructure of no,” but it only says no to what it can see. That means deployment is an architectural decision, not a checkbox: the enforcement point has to be the only path to the effect.
It also does not decide what your rules should be. A corpus makes requirements executable; it does not make them correct. Someone accountable still has to determine that a debt-to-income threshold or a clinical constraint is the right one. The product's job is to make the answer to that human question enforceable and provable, ten thousand times a day, identically.
Why this sits next to the rest of my work
On the same day I am publishing this, there is a post about ArkCloud Health — healthcare software where the platform deliberately declines seven capabilities it could have shipped — and one about why the database is the only adult in the room, which is the enforcement layer below this one. Those three decisions come from the same place. In a regulated domain, the durable product is not the one with the most capability; it is the one whose refusals are legible, enforced, and provable.
That is what CoreGuard is for. Not a policy on a wall, and not a dashboard after the fact — a runtime that decides before the action executes, signs what it decided, and leaves a chain anyone can replay.
If you want to see it run, there is a live demo and documentation at evecore.com, including the benchmark harness if you would rather check the numbers than take them.
— Jamaurice Holt, Founder of EVE NeuroSystems LLC