Security & limits

What kovee does not claim, said first.

Kovee is pre-release, under active development, not production-ready and not audited. No compatibility claim is made. Everything below is a limit that also appears next to the capability it limits, because a limit that only lives in a footer is a limit nobody reads.

developer assurance profile no confinement no team mode not audited

The register

This project is at the stage where the interesting question is whether the mechanisms are right, not whether they are hardened. It runs; its durability claims are tested by killing the process; its wire format is re-derived by two independent implementations. It has been through five adversarial review rounds inside the program that builds it, and their most common finding was claims outrunning evidence — which is why this page exists and why the rest of the site is machine-checked against the tree. None of that is an external audit, and none of it makes kovee safe to put something valuable behind.

The assurance profile is `developer`

Concretely, and by design rather than by omission:

Not provided	What that means for you
No UID separation	The daemon, the CLI, the MCP server and any assistant all run as you. A process that can read your home directory can read kovee's database directly and bypass every check on this site.
No attested process identity	The daemon authenticates its peer's UID with `SO_PEERCRED`. It cannot tell which of your programs connected, only that it is one of yours.
No asymmetric endpoint identity	There are no endpoint keys and no signatures on the local wire. Authority is a local socket you can reach.

Non-developer deployment profiles are refused rather than faked: the daemon does not accept a production profile and then quietly run without the isolation that profile implies. The confined workers, immutable production packages and brokered egress in kovee's design are unbuilt.

Provider-bypass prevention is not claimed

This is the easiest claim on this site to overstate, so it gets stated twice. Kovee's model broker discloses, permits and meters its own calls to a model provider. It does not prevent bypass. There are two separate limits, at two different levels.

1. At the operating-system level

A same-UID assistant can skip the daemon entirely and call a provider itself with its own key. Nothing in kovee observes that, let alone stops it. Enforced broker-only egress would need confinement kovee does not have, and it is a later milestone.

2. Inside one process

The external path to minting an execution permit is closed at the crate boundary — no public constructor, no Deserialize, a sealed spent-ledger trait, a crate-private transport, and one public door in the daemon build that answers once per process. Those refusals are proved against rustc's own diagnostics rather than asserted; see the compile gate.

That closes the external-crate path and nothing more. It cannot distinguish the daemon from other code compiled into the daemon: code that runs before koveed takes the grant can take it instead, and code holding a reference to the authority can drive it with material of its own.

What actually bounds a forgery

The durable ledger, not cryptography. A fabricated permit still has to claim its single use by moving a row that only a real byom consumption created, so it sends nothing — and there is a test that builds an attacker's authority from identical key material and proves not one byte leaves. But the property is "the ledger refuses", not "the forgery is detected". Closing the rest needs byom to sign its receipts so kovee can verify provenance against a peer key. That is a cross-boundary protocol change, and it is deferred.

If any wording on this site is stronger than the module documentation in crates/kovee-effects/src/permit.rs — its section is called "What is closed, and what is not" — then the site is wrong and the code is right.

Team mode does not exist

There is no PostgreSQL, no OIDC, no realtime channel and no NATS. Kovee binds two Unix domain sockets and has no network listener at all. The personal profile has one realm and one principal. Multi-person installations are a later milestone, and nothing shipped should be read as a preview of one.

The governed-loop gate is partial

The end-to-end gate that exercises kovee under byom governance is recorded as partial, and the tag says why: of thirteen items, five are exercised with nothing standing in and eight are explicitly simulated.

Simulated	Because
The attention trigger	`crates/kovee-attention` is a two-line stub; nothing wakes an assistant.
Manifestation variety	byom mints only attached-harness manifestations.
Onboarding	kovee ships no onboarding code.
Provider calls on the ambiguous-effect and broker paths	A recording transport stands in for a real provider.

The gate derives that breakdown from the daemons' own records rather than from a checklist: each coverage query runs against the daemon that owns the record, simulation status is re-probed every run, and a cell whose declaration disagrees with what the probes observed fails instead of being promoted. A no-op cell fails naming the item and the query, and skipping a real harness returns a non-zero exit rather than a pass. That is a property worth more than the number: the gate is built so that this page cannot quietly become false while the gate stays green.

The two-host tooling has never run

Scripts exist under harness/fleet/ that would stand up two hosts, run the cross-installation gate and destroy them. They are written and dry-run validated. No cloud resource has ever been created by them, and most of their scenarios need a per-side driver that does not exist yet. Treat the directory as intent, not as evidence.

What is real

Within a single trusted user account, these are properties, not aspirations:

Same-UID peer authentication. Every connection is checked with SO_PEERCRED. The socket directory is created 0700 and each socket file 0600; a stale socket is removed before binding.
No inbound network surface. Two Unix sockets, nothing else.
Fail-closed durability. The store refuses to run if SQLite does not confirm WAL mode, because a filesystem that silently downgrades it would silently weaken every crash guarantee.
Atomic commands, tested by process abort. State, events, outbox, audit and the idempotency record commit together or not at all — checked by killing the real daemon at both sides of the commit. See crash-honesty.
Authenticated cursors. Ledger positions are MAC'd and bound to the installation and source; possession grants nothing and authorization is rechecked on every read.
Closed enums and hard caps on kinds, list sizes, request and reply bytes, page limits and identifiers — refusal rather than truncation.
A hash-linked audit chain written inside the command transaction, so there is no committed command without an audit row. It records that a command happened, not what was said.
Deny-by-absence on the agent surface. No worker- or operator-surface operation is exposed as an MCP tool, and that is re-derived from the registry rather than maintained by hand.

Erasure is real, and narrow

Artifact content is addressed by an HMAC under a secret minted for that one object, so destroying that secret erases verifiability for exactly that object. Erasing removes the sealed blob and the staging copies and null-columns the key, digest, storage reference, size and media type, keeping identity and provenance. There is no retained plaintext hash to undo it, freed database pages are overwritten, and the tests grep the database file, its write-ahead log and the artifact store for the plaintext rather than trusting the code path.

Limits

Erasure covers what kovee stores. It cannot reach a copy something else made, an operating-system backup, or a snapshot of the volume. And nothing is scanned: verification checks size, declared digest, media type and content digest — no malware or secret scanning is performed or claimed, and the record says so by pinning an empty scanner set.

How the claims on this site are checked

This program's most common defect across five review rounds was documentation and tests that keep passing after the thing they describe changes. So the site is wired against that:

The reference is generated from spec/registry.json, the per-operation schemas, and the CLI's own source. It is not transcribed.
Every count on every page — operations, entries, bundles, CLI verbs, MCP tools, schemas, vectors, migrations, caps — is tagged in the HTML and re-derived from those sources by docs-tools/check_docs.py, which runs in ./run-checks.sh. A number that drifts fails the build.
Every operation name mentioned in prose is checked to exist in the registry.
Every absence claim — no branch_*, no attention_*, no need_* / offer_* / commitment_* operation — is re-derived too. If someone ships one of those, the pages that say it does not exist go red rather than going stale.

That is a defence against the site rotting, not a proof that the code is correct.

If you run it anyway

Run it as a user account whose home directory you would be comfortable handing to any agent you invoke, because effectively you are.
Keep the data directory on a real local filesystem — the WAL check will refuse a network filesystem, which is the point.
Do not put secrets in contributions. Redaction destroys verifiability, not other people's copies.
Treat provider keys as if the broker were not there, because for any other process on that machine it is not.
Expect breaking changes. No compatibility claim is made, and the protocol version is 0.1.

Reporting

There is no security contact address and no advisory process yet — consistent with the register. For now, open an issue at github.com/zarbafian/kovee. If you find a claim on this site that the code does not support, that is the most useful issue you can file: it has happened before, and correcting it in public is the intended outcome.