Products

Three products, on your own server

Zetna™ runs on a server you already operate. Each product below runs on that one server, and each starts as a four-week pilot, with your own people approving, against success criteria both sides sign before it starts.

We're selling to operators first. They can host Zetna and sell governed AI to their own customers, whose security and compliance teams are the buyers inside.

One Credential

Staff join by invitation and enrol a hardware security key, bound to your domain. Every sign-in and every approval is one touch on that key, with no password. A synced passkey, which can be copied off the device, is refused, and so are a look-alike site and a replayed approval.

Agents get their credentials from their person's. A service accepts an agent because its request is signed by a key that traces back to a named person, so there's no API key to paste into a config, leak or rotate. Each agent's key is created in hardware (a TPM chip or the Secure Enclave) and can't be copied off the machine; it signs every request.

An agent that arrives with a signed token from your identity provider shows it once, when it is issued. After that it signs every call with its own key, and any bearer token is refused at every door.

One revoke cuts off the person and every agent they issued, everywhere the credential is accepted. Every service that accepts it makes it worth more to the next. More on One Credential

Use it for

• Phishing-resistant sign-in and approval for a customer's staff, with no password to steal.
• Deleting your agents' API keys.
• Letting a service accept your people and their agents with no password and no API key.

What an operator gets: passwordless sign-in and approval for a customer's staff, under its own brand, with a signed receipt for every sign-in, issue and approval.

The four-week pilot

Week by week

1. Week 1. An officer invites staff, and each touches a security key, which is then bound to your domain. A synced passkey, which can be copied off the device, is refused.
2. Week 2. Every sign-in and approval is one touch on that key. Staff try a copied passkey, a look-alike site and a replayed approval; each is refused by name.
3. Week 3. Your customer's agents move off shared API keys. An agent with a token from the identity provider shows it once, when it is issued, and signs every call with its own key after that; any bearer token is refused at every door.
4. Week 4. Your customer revokes one person, and every door refuses them and their agents at the next request.

What gets measured

No password stored or accepted. Every sign-in without the enrolled key refused and receipted. A synced passkey and a look-alike site refused. A revoked person refused at the next request, and every receipt verified offline.

At the end: passwordless, phishing-resistant sign-in and approval for a customer's staff, that customer's agents off shared API keys, and a signed receipt for every sign-in, issue and approval, under your own brand.

You provide: a domain with HTTPS, a FIDO2 security key per participant, and your customer's identity-provider signing key, issuer name and group. The server never calls the identity provider.

On a remote server, staff use security keys, and a key built into a laptop or phone is not supported. Touch ID works only on the Mac the server runs on. The enrolment page does not fetch the company login.

The governance control plane

One console for a security team. Invite your people. Each joins on their own key and issues their agent with one touch, and every agent answers to that person.

An act over its limit is held. The named person sees the amount, the payee and the limit it breaks, approves with a touch, and it happens once. One officer can stop an agent, and one can throw a switch that halts every agent; lifting the switch needs two.

Two officers can grant an examiner a range of the log, and the examiner checks it offline. The compliance pages lay out the evidence for the EU AI Act, the NIST AI RMF and other frameworks, for an auditor to judge. Security events go to your SIEM as content-free OCSF events.

Use it for

• Letting an agent pay invoices, with a named person approving anything over its limit.
• Handing an auditor evidence the auditor re-derives, not screenshots.
• Giving a customer's security team this console, and its staff a workspace, under your own name and logo.

What an operator gets: a governance service it can sell under its own brand, and an evidence pack an examiner has checked.

The four-week pilot

Week by week

1. Week 1. Two or three officers enrol on security keys. An IT officer invites staff, and each issues their agent with one touch; every agent answers to that person.
2. Week 2. One real workload runs under your customer's rules; paying an invoice is our standard example. An agent proposes a payment over its limit, and it is held. The named person sees the amount, the payee and the limit it breaks, approves with a touch, and it happens once.
3. Week 3. An officer stops one agent from the console, and revoking a person stops every agent they issued. Your customer's SIEM pulls the security events, and the compliance pages show the evidence for each framework, for an auditor to judge.
4. Week 4. Two officers grant an examiner a range of the log, and the examiner checks the pack offline.

What gets measured

Every act that matters held, and none carried out without a named approver or twice. Every attempt without approval refused and receipted. A revoked person or agent refused at the next request. Every sampled receipt verified offline in two verifiers, every one-byte edit refused, and no prompt or answer in the evidence.

At the end: a governance service you can sell under your own brand, a customer security team that has run it themselves, and an evidence pack an examiner has checked.

You provide: the server and domain, a FIDO2 security key for each officer and approver, one real workload, and, if wanted, your customer's SIEM collector on the server.

The governed agent is our reference agent. The adapters for Claude Code, Hermes and MCP clients are tested against recorded traffic, and none has run in the real client. On a remote server, approval uses a FIDO2 security key. The compliance readings are with our counsel. In a pilot, officers reach the console on the server itself or over a private tunnel.

Governed inference

Serve open-weights models from your own hardware to your customers. A router picks a model inside the menu you set, by the task, the data's sensitivity and cost, and records why. A caller asks for a task, never a model.

Every call gets a signed receipt that names the model by the digest of its weights and carries the tokens in and out. The billing statement re-derives offline from the receipts alone.

Use it for

• Selling metered inference from your own data centre, with a bill each customer can re-check without asking you.
• Keeping restricted data on your server: a call that would send it towards a cloud model is refused and receipted.

What an operator gets: a metered inference service on its own hardware, a statement per customer to price against, and a receipt trail its customers check themselves.

The four-week pilot

Week by week

1. Week 1. Your team installs the release and binds two or three models, each pinned by the digest of its weights, and a rate card. The server records each step, up to its first metered receipt.
2. Week 2. Your customer's staff send real requests. They ask for a task, never a model, and the router records why it chose each model.
3. Week 3. Your team watches each call on the Routing and Billing pages, then tries to break it: a model outside the menu, restricted data sent towards a cloud model, an agent stopped. Each is refused and receipted.
4. Week 4. Your customer's auditor re-derives the bill from the receipts, on a laptop with no network, and compares it with what the models reported.

What gets measured

The time from a bare server to its first metered receipt. For every call, a signed receipt naming the model by the digest of its weights, the route record with its reasons, and the tokens in and out. The billing statement, re-derived offline, must equal what the models reported, with each call billed once.

At the end: a metered inference service on your own hardware, a statement per customer you can price against, and a receipt trail your customers check themselves.

You provide: one server sized for your models, the model weights, a domain name with HTTPS in front of the server, and two or three named people. We have measured small open models on four virtual CPUs.

Payments in a pilot use ledger units, and nothing is paid. Our routing and metering runs so far used stand-in model servers, so the first job in week one is the same run on your models. A cloud model through the exit has not run with a live key. Answers come back whole, not streamed.

Pilots: the success criteria you sign

Each pilot runs for four weeks on a server you already operate, with your own people approving, against these criteria, signed by both sides before it starts.

You sign these success criteria before we start, and each one is measured in your environment.

• S1 · Time to first receipt. Under 60 minutes per server you own, from a bare machine to its first metered receipt, with every step receipted.
• S2 · Held actions. 100% of the actions that matter are held, 0 are carried out without a named approver, and 0 are carried out again on a replay.
• S3 · Break the rules. Every attempt without approval or without clearance is refused, and the refusal is receipted.
• S4 · Offline verification. 100% of sampled receipts verify on your machine with every server of ours stopped, in two verifiers, and 100% of one-byte edits are refused.
• S5 · Forbidden egress. 0 connections to a destination you did not declare, and every refusal receipted before a connection opens.
• S7 · Revocation. A revoked person or agent is refused at the next request.
• S9 · Content-free evidence. 0 prompt or response bytes in the receipt store or the log stream.

S1 is our commitment for your environment, not a measurement taken there. A fresh server has reached its first receipt in about two minutes on rented servers.

How to start a pilot