AI harness on the Internet Computer
The Power of AI.
The Unbreakable Security of Blockchain.
An AI harness engineered for absolute privacy, continuous autonomy, and human control.
- Runs on
- Internet Computer
- Encryption
- vetKeys · E2EE
- Node visibility
- None
- Uptime model
- On-chain timers
01 — Infrastructure
Tamper-Proof & Privacy by Design.
vetKeys · end-to-end encryption
Your data is unreadable to the infrastructure it runs on.
Documents are encrypted in your browser and stored as ciphertext. The decryption key is derived through vetKeys, anchored to your Internet Identity passkey — which lives in your device’s secure hardware and cannot be extracted, only used.
Node providers, hosting companies and the canister itself hold ciphertext and nothing else. This is not a policy that can be revised. It is the architecture.
Trust boundary
What each party can see
Local inference
Run the model on your own machine
With a local LLM, nothing leaves your computer at all. No gateway, no anonymisation layer, no trust required — because there is no outside.
Anonymisation layer
When you do want a frontier model, it never learns who this is about.
Four layers — deterministic rules, a register of your own entities, a NER model running entirely in your browser, and your corrections — replace names, amounts and identifiers with codes before anything is transmitted. The response is restored on your screen.
// transmitted
Draft a notice of default for <<Company_A7K2Q1>>, outstanding <<Amount_M4X8>>.
Verifiable, not asserted
The layer measures whether it leaks — and tells you.
It flags when a model writes a name it could not have known. It refuses codes belonging to another matter. It counts every identifier you had to mark by hand as an observed false negative. And a re-identification self-test puts your outgoing text to a local model and asks: who is this, probably? For compliance officers and legal professionals, a control you can audit is worth more than a guarantee you cannot.
02 — Control
Hard Mandates Over Soft Guardrails.
Beyond the system prompt
A boundary the code checks — not a request the model can decline.
A system prompt asks a model to behave, and you find out afterwards whether it did. A mandate is a document that names what an agent may do, and those terms are checked at the moment the action is attempted — outside the model, in code the agent does not get a vote on.
Whether the model was persuaded, confused or deliberately manipulated does not enter into it. It does not ask the agent to stop. It does not proceed.
Anatomy of a mandate
Readable by the person accountable for it
---
name: outbound-counsel
actions: [read, propose]
requires_human: [finalize]
forbids: [deploy, grant_to_others]
key_paths: [matters/velthuis]
---
The floor
The hardest boundary is not a rule. It is a key you do not have.
Access to documents is scoped cryptographically, per agent. An agent reaching outside its scope does not receive a refusal it might argue with — it receives ciphertext. That is not a policy decision taken at runtime; it is the absence of a key.
For work with genuinely sensitive material, this is the boundary that carries the weight. Everything else above it is defence in depth.
Enforced or declared
Evive tells you which of its own rules have teeth.
Every term in the mandate vocabulary is marked as enforced — with the place in the code that enforces it — or as declared, meaning it states intent and nothing checks it yet. You can read that list. So can your compliance officer.
A test reads the source and fails the build the moment an enforced term stops pointing at real code. The failure this closes is the one nobody notices: a promise that quietly stopped being kept.
Vocabulary
An unknown term is refused, not ignored
A mandate using a word the system does not know is rejected rather than silently passing. A guardrail that is really a typo is worse than no guardrail, because you believe in it.
Scope
Case data cannot leave
Matters marked as case-concrete are barred from every external model — cloud and on-chain alike. Lifting that bar is a deliberate, logged act, and only possible once nothing is left unreviewed.
03 — Human in the loop
Trustless Generative UI
What it is, and where it goes wrong
The agent builds the screen. It does not get to write it.
When an agent needs a decision from you, it builds the screen for it — a chart, a form, three buttons — instead of a wall of text. That is generative UI, and it is the right idea.
But when that screen arrives as code your browser then runs, as it does in Google’s generative UI and in MCP Apps, its safety rests on a model behaving. Here it arrives as data. The markup was written by us, reviewed, and is the same for every answer — so a poisoned document cannot become a running script.
Generated for review
A decision, rendered
agent · outbound-counsel · awaiting approval
| Action | Mandate | Enforcement |
|---|---|---|
| Draft notice of default | propose | declared |
| Read matters/velthuis | read | key scope |
| Send to counterparty | forbidden | blocked in code |
Why a screen at all
A form is more deterministic than a conversation.
Somewhere a person has to decide, because a person carries the responsibility. A chat transcript is a poor instrument for that: the decision is buried in paragraph four, the figures are prose, and what you approved is whatever you happened to read.
It is the difference between writing a slide and writing what is on it. Fix the rendering, and the content can change at the moment you need it to — without anyone redesigning anything.
Ten views, one renderer
Every number traces back to the document it came from.
The agent picks from ten audited views — table, kanban, cards, form, calendar, org chart, gauges, sentiment, progress, text — and Evive draws them. It cannot invent an eleventh. A chart is rendered from its own table, so you can point at any figure and see the cell, the document and the passage behind it.
Speaks A2UI, MCP Apps and AG-UI as output formats, so this renders outside Evive too.
Don’t trust, verify. That should include the screen you are approving.
04 — Continuity
24/7 Unstoppable Autonomy.
On-chain timers
No server to keep alive. No process to restart.
Agents are scheduled against the Internet Computer’s own clock. There is no machine of ours that has to stay up, no cron on a laptop that stops when the lid closes, and no provider who can switch it off. A deadline that falls on a Sunday night is watched on Sunday night.
Operating envelope
What keeps running
Put your most sensitive matter in front of a model. Safely.
Evive is in closed access while it is still changing daily. Tell us what you work on and we will put your Internet Identity on the list — no password, and no email address we have to keep.