Kerneva is a control on money-moving agents, so this page is written for the person who has to approve it. Everything below can be checked against the API, the SDK, or the self-hosted image.
The evaluate payload is deliberately small. Kerneva scores the action, not the conversation that led to it:
Kerneva does not need: customer names, email addresses, conversation content, model outputs, or function arguments beyond the action type and amount. metadata is optional and under your control; send nothing in it if you prefer. Counterparty identifiers, where you choose to send them, are used for structuring detection and the new-payee hold, and are validated, never resolved against outside data. Bank accounts are compared by a one-way fingerprint, which can be keyed with a secret (KERNEVA_FINGERPRINT_SECRET) so the stored value can't be worked back to an account number. A bank detail that fails validation is described in the decision by its length and character shape, not quoted.
Keys are scoped to one account and one environment (test or live), stored as SHA-256 hashes, and revocable from the dashboard. A key can evaluate actions and report what happened; it cannot change configuration, mint keys, approve an agent, release a held action, or release a halt.
Two roles per account. Admins change thresholds, manage keys and members, approve agents, and release halts. Members review. Service keys hold neither role. Kerneva refuses to demote the last admin.
Each decision carries an HMAC-signed token bound to the action, amount and counterparty, so the business system can verify it is executing the decision Kerneva issued and not a replayed or edited one.
Every query is scoped by account and environment at the API layer. The code went through three rounds of security audit in 2026, including one by an outside reviewer; every confirmed finding is fixed on the main branch with a regression test.
Hosted traffic terminates at Cloudflare and is served over HTTPS; the origin accepts requests only from the edge. Hosted data is stored in managed PostgreSQL (Neon). Self-hosted deployments use your own PostgreSQL with sslmode=require set in the chart; encryption at rest, backups and key management are yours, on infrastructure you already control.
Any credential, including a service key, can halt an agent, an action type, or a whole account. Halted actions are blocked regardless of Observation Mode. Only an admin can release the halt, and the release is recorded with who did it and when. Stopping money is deliberately easier than restarting it.
An agent holding an API key can register itself, but only an admin can approve it. With the agent allowlist on, actions from agents nobody approved are held or blocked. The new-payee hold sends the first payment to a payee the company has never paid, or to a bank account a known payee has never been paid at, to review. A held payment can only be reported as completed after a person releases it, so an agent cannot make a new payee “known” by retrying. From SDK 0.7.0, guard does not run a held action: it raises RuntimeTrustHeld so your code can queue it for that person.
Kerneva runs the API and dashboard at api.kerneva.com and app.kerneva.com. Upgrades, monitoring and incident response are ours. Suited to pilots and teams that want to start without infrastructure work.
One runtime container, one dashboard container, your PostgreSQL. Images are published to Docker Hub as kerneva/runtime and kerneva/dashboard, scanned and signed with cosign on release. No outbound internet is required. Same API, same scoring logic as Hosted. You hold the signing and fingerprint secrets; the deployment docs list both.
Retention: evaluations, receipts and review outcomes are kept until you delete them. There is no automatic expiry today. Self-hosted, retention is whatever your database policy says.
Export: the full evaluation history is exportable as CSV from the API or dashboard. Every export is itself logged with who requested it. Each evaluation carries a stable evaluation_id for cross-referencing with your own audit logs.
Deletion: Hosted account deletion is on request to [email protected] and is confirmed back to you in writing. Self-hosted, the data never left your network.
guard holds a REVIEW instead of running it; pass hold_on_review=False to keep the older proceed-with-a-warning behavior. The one exception is an operator halt, which blocks in every mode because a person asked it to.fail_open=True for workflows where proceeding without a decision is acceptable. Timeouts are configurable per endpoint. The choice is explicit in your code either way.Twenty minutes on how it behaves today, and whether the patterns in the benchmark show up in your own history. No integration needed for the first conversation.
Or write directly: [email protected]