The recorder, running as its own system user, signs the purpose and the two allowed futures datasets. The agent can't read its keys.
Neutral ground
One record that ICE, its customers and other data vendors all check. It works because Hive is none of them.
- 1
Real ICE data, witnessed
A real Claude Code session pulled ICE BofA index data from its public distribution. Each pull was signed and witnessed before the agent saw it.
- 2
Credited across vendors
One answer built from ICE's data and another publisher's. Each side finds its own input, and neither sees the other.
- 3
The same pieces on 100 surfaces
Seven pieces, built once, repeat across all 100 candidate surfaces. Each firm or vendor that joins checks the same log.
AI agents and licensed data · a record the agent can't rewrite
When a customer's AI agent pulls ICE data, every pull is signed and witnessed before it runs, and the witness remembers.
“A complete audit trail so that every output can be traced and trusted.”ICE, July 30, 2026 investor presentation
- The entitlement, the datasets this session may pull, is signed before the first call
- Each pull is fingerprinted and witnessed outside the agent before it runs
- Anyone can ask the witness later, without being handed anything
Line 8 of a real session
Claude Code, October 10, 2026, through a market-data MCP tool. The firm's own log sits on the same machine as the agent. This record doesn't.
- allowed
- futures.brent.*, futures.wti.eod
- asked for
- mortgage.loan-level
- flagged
- outside the entitlement, before it ran
- witnessed
- in 0.3 s, by a witness outside the agent
- kept
- the dataset name and fingerprints. None of the data.
The market-data server is a local stand-in with made-up values, and every reply says so. Hive ran this witness for the demo. ICE can run its own.
What happened
One real session, four steps, one pull outside the entitlement.
Claude asks the market-data tool for futures.brent.eod. The recorder writes the line, the witness signs it, then the call runs.
Claude asks for 5 rows of mortgage.loan-level. The line is flagged outside the entitlement and witnessed before the call runs. Hive doesn't block it. The firm's own controls decide that.
The record is sealed with both signatures. The witness signed 6 times, the slowest in 0.3 s. DigiCert stamped the start and both seals with a public time.
The whole path
From the question to the payment, every step lands on the same record.
Three of the seven steps ran in the session above. The other four are built and run elsewhere on Hive, and haven't yet run on this path.
CarnacPrompt records the request byte for byte, so an answer can be tied to the exact question. Try the prompt box or see the surface
Before the first call, the recorder signs which datasets and purpose the session may touch. See the session
Live Ink marks licensed sources, client names and permission phrases as the request is typed. The words themselves never change. See the surface
Each pull is signed and witnessed before the agent sees it. Check it with ICE's own number
The answer passport ties the figure to exactly the deliveries it was computed from. Open the passport
Before an answer is exported, sent to a client or used for an order, Carnac records which proof was asked for and what was shown. People decide what happens next. See the surface
Where an agent buys data per call, each payment and the pull it bought share one record. Arc settles the payment; the record shows what it paid for. See it on fictional records
Ask the witness yourself
Nobody hands you the witness statements. Your browser asks the witness directly.
The witness keeps four fingerprints, its time and its signature for every statement. It only remembers requests signed with the recorder's own key, so nobody else can add a history to a session. The check below runs in your browser against what the witness remembers right now.
Asking the witness...
3 rewrites of this record, none with witness statements
Two are re-signed with the recorder's own keys, so every signature in them checks. The witness's memory still rejects each one.
Check it on your own machine. The session, the tamper copies and the checker are in the public recorder repository, with one command to run.
Built on the same record · new
Five things only a party in the middle can do for ICE and its clients.
- ICE's own delivery log matched to the firm's record, so a pull outside the agent shows up
- A licence statement both sides check, with no session left out
- A copy of the record for ICE that shows ICE's pulls and nothing else
- One witness across every data vendor in a session
- A trail from an agent's answer back to the ICE pulls behind it
Four real sessions, two vendors
Claude Code, October 10 and 11, 2026, through two MCP data servers. Every check below runs in your browser against the live witness.
- sessions
- 4 here, 2 more through the gateway below
- vendor log
- 4 deliveries from the ICE stand-in, 1 the firm's recorder never saw
- pulls
- one outside ICE's entitlement in each pair
- answers
- figures repeated and figures computed, traced to ICE deliveries
- rewrites tried
- 23. All 23 rejected.
Both data servers are local stand-ins with made-up values, and every reply says so. Hive ran this witness for the demo. ICE can run its own.
1 · Both sides of every pull
ICE's log of what it delivered, matched line by line to the firm's record of what its agent pulled.
The firm's record shows what its agent pulled, and it can't show a pull that went around the agent. ICE's server log shows what ICE delivered, and the firm has no reason to take it on trust. Here each one is signed and witnessed as it happens. ICE's server gives every delivery an id, and the firm's recorder keeps a fingerprint of it. Matching the two logs shows any pull the firm's recorder never saw, and any pull the firm claims that ICE never served. Neither side can do this from its own log, and neither can rewrite its log afterwards.
ICE's delivery log (market-data stand-in)The firm's record
Asking the witness about both logs...
What the answer computed from ICE data
ICE holds what it delivered, so given the agent's answer it can tell which figures were repeated and which were computed. Computed figures are the part a firm's own trail misses, and where derived-data licensing applies.
| Figure | Computed as | From |
|---|
Waiting for the match...
Nine ways either side could bend it. Each one is rejected.
What the outside pull is. After the two Claude Code sessions, we sent one request straight to the market-data stand-in, outside Claude Code and its recorder. It stands for a script or a second agent using the same credential. Everything is in the public recorder repository, including the vendor-side library.
2 · Licence statement
A usage count ICE and the firm can both check, without trusting each other's numbers.
A usage audit usually starts with two counts that don't agree. Here the firm's recorder signs one statement for one vendor and one period: every session, every pull by dataset, every pull outside the entitlement, and every answer that used the data. ICE rebuilds each number from its own copies, checks each copy against the witness, and asks the witness which sessions it saw in the period, so a session left out shows up. When the numbers hold, ICE signs to accept with its own key.
| Dataset | Asked | Ran | Entitlement |
|---|
Asking the witness...
Four ways to bend the statement. Each one is rejected.
3 · One copy for each vendor
The firm shows ICE its own pulls and nothing else, and ICE can still tell nothing was taken out.
Firms only share records they can share narrowly. In ICE's copy, every ICE line is shown in full. The other vendor's pulls, the firm's prompt and a tool lookup show as a fingerprint only. Those lines still chain, still carry the recorder's signature and still match what the witness saw, so a line can't be dropped, relabelled or rewritten without it showing.
shown in fullfingerprint onlyoutside the entitlement
Asking the witness...
Four ways to hide something in ICE's copy
4 · Two vendors, one witness
One session, two data vendors. Each sees its own pulls and proof that the rest is complete.
A firm's agent pulls from several vendors in one session. No vendor would run a witness that another vendor's data passes through, and the firm wouldn't hand any of them the whole record. One witness in the middle holds both. Below are the two copies of the same session: market-data standing in for ICE, and ref-data standing in for another vendor. Each checks against the same witness memory, and neither shows the other's lines.
market-data's copy (ICE stand-in)
Asking the witness...
ref-data's copy (another vendor)
Asking the witness...
Three tricks across the two vendors
5 · From answer back to data
Which answers used ICE data, traced from the answer itself.
Derived data is where much of the licence value sits, and it's the question ICE's own logs can't answer. When a turn ends, the recorder notes which tool results the answer repeats figures from. It matches keyed fingerprints, so it never sees the figures. Given the answer, ICE redoes the match from its own copy.
| Result | Vendor | Dataset | Figures used | Entitlement |
|---|
Asking the witness...
Three ways to hide where an answer came from
Check it on your own machine. Both sessions, every copy, the statement and all 14 rewrites are in the public recorder repository, with the commands to run.
Nothing to build at ICE · the witness is checked too
ICE's MCP server stays as it is, and nobody has to take Hive's witness on trust.
- A gateway in front of ICE's MCP server keeps ICE's signed delivery log, with no change to the server behind it
- Spreads, ratios and percentage changes traced back to the ICE deliveries they came from
- Every statement the witness signs goes into one public, append-only tree
- ICE and the firm each cosign that tree, so the witness can't show them different histories
- Receipts in the IETF SCITT format, so other tools can check them
Two more real sessions, through a gateway
Claude Code, October 11, 2026, over HTTP to a plain MCP server with no Hive code, through the gateway. Every check below runs in your browser against the live witness and its public log.
- vendor code
- none. The gateway sits in front.
- deliveries
- 4 logged, 1 the firm's recorder never saw
- computed
- 5 figures traced: spread, ratio, % change, total, share
- cosigners
- 2, stand-ins for ICE and the firm
- rewrites tried
- 10. All 10 rejected.
The data server is a local stand-in with made-up values, and every reply says so. Hive ran the witness, the gateway and both cosigners for the demo. ICE and the firm can each run their own.
6 · No change to ICE's server
A gateway in front of ICE's MCP server keeps ICE's side of every pull. Nothing changes behind it.
Section 1 needed a few lines of code inside the vendor's server. Here there are none. The gateway sits in front of the MCP server, passes every message through, and for each successful tool result it signs a delivery line, has the witness countersign it, and only then lets the data go out. It adds the delivery id to the result twice: in the MCP metadata field, and as one short text block. We found Claude Code doesn't pass the metadata field to its hooks, so the text block is the one the firm's recorder reads. This run used the strict setting: if no witness answers, the gateway holds the result back and logs nothing. That setting would be ICE's choice on ICE's own gateway, with its own latency and availability numbers. The default is shadow: the result goes out and the missing countersignature shows as a gap. The two modes.
ICE's gateway log (market-data stand-in)The firm's record
Asking the witness about both logs...
Spreads, ratios and percentage changes, traced to ICE deliveries
A figure an agent computes appears nowhere in what ICE delivered, so a firm's own trail can't link it back. ICE can, because ICE kept what it delivered. Each computed figure below matches exactly one operation at the precision the answer shows it, and two of them combine Brent and WTI from two separate deliveries.
| Figure | Operation | From | In |
|---|
Tracing the answers...
Four ways either side could bend it. Each one is rejected.
What the outside pull is. After the two sessions, we sent one Brent request straight to the gateway with the firm's access key, outside Claude Code. The gateway logged it like any other delivery, and the firm's record has no line for it. The gateway, the plain server and both sessions are in the public recorder repository.
7 · Who checks the witness
Every statement the witness signs is in one public tree, and ICE and the firm each cosign it.
Everything above leans on the witness. Hive runs it, so the fair question is who checks Hive. The witness puts every statement it signs into one append-only tree and signs the tree's root. Anyone can prove a statement is in the tree, and prove a later tree only added to an earlier one. A cosigner run by ICE, and another run by the firm, each sign the root only after checking that. If the witness ever showed ICE one history and the firm another, the two signed roots would be the proof. The tree's checkpoints use the same open formats as the Go checksum database and Sigstore, and its receipts follow the IETF SCITT standards (RFC 9943 and RFC 9942).
| Checked | Result | Detail |
|---|
Reading the witness's public log...
Six ways the witness itself could bend it. Each one is rejected.
Checked with other code too. A short Python script in the recorder repository checks the same checkpoint, both cosignatures and the SCITT receipt with standard open-source libraries, and shares no code with this page.
No single holder · Hive included
One signing key, held in three parts by ICE, the firm and Hive. Any two can sign. No one can sign alone.
Two signatures keep the log running. They don't stand for commercial agreement, since ICE and Hive could sign without the firm. A usage declaration counts as agreed only when ICE and the firm each sign it.
- The private key never exists in one place, not at key creation and not afterwards
- Each holder signs only a log tree that extends the last one it signed
- Each holder signs a statement only if it matches what that holder computed from its own records
- The result is a normal Ed25519 signature, so ordinary tools check it
The live key
Created October 11, 2026 with FROST (IETF RFC 9591). Every check below runs in your browser.
- holders
- ICE stand-in, firm stand-in, Hive
- to sign
- any 2 of the 3
- signed so far
- its own ceremony record, a usage inventory, an approved calculation, and the live log
- pairs used
- all three different pairs
- refusals tried
- 7 in this tab, 39 in the test suite
For the demo Hive ran all three holders and made their identity keys. ICE and the firm each run their own holder on their own machines, and Hive then holds one part of three.
An answer that carries its own proof
Claude Code said 146.2 bp. The passport proves that figure came from ICE's delivered data, without showing any of it.
- The calculation was approved in advance by the shared key
- The yields and benchmarks inside the proof are exactly the ones ICE delivered and signed
- The weights are the ones the firm committed to before the data arrived
- The passport holds the result and three fingerprints, and no ICE values
One real answer
Claude Code, October 11, 2026, asked for the par-weighted spread of an eight-bond book through ICE's gateway.
- answer
- Par-weighted spread: 146.2 bp
- proof
- PLONK, 14 KB passport, checks offline
- reveals
- the result and three fingerprints
- hides
- 8 yields, 8 benchmarks, 8 par amounts
- bent copies tried
- 10. All 10 refused.
The bonds are fictional (DEMOBND01 to 08) and the values come from a local stand-in data server. The proof and checks are real.
9 · The answer's passport
A figure an agent computes can be checked against ICE's deliveries, without anyone seeing the deliveries.
Section 6 traced computed figures back to ICE deliveries, but the check needed the delivered values. Here it doesn't. When ICE's gateway delivers, it signs a fingerprint of the values into its delivery line and gives the secret key for that fingerprint only to the customer. The firm logs a fingerprint of its own weights. After the agent answers, the firm makes a zero-knowledge proof that the answer is the approved calculation over values matching those fingerprints. Anyone can check the proof, and it shows only the result.
What the agent said
What the passport shows, and what it never contains
| Step | Result | Detail |
|---|
Loading the proof checker...
Ten ways to bend it. Each one is refused at the step that catches it.
What it proves and what it doesn't. The passport proves the arithmetic and the inputs. It doesn't show that ICE's values were right or that the spread was the right thing to compute. A firm could log several sets of weights; each is a public log entry, so anyone watching sees them all. The proof system is PLONK over the BN254 curve, checked here with a copy of snarkjs 0.7.5 served from this site. The circuit, keys and build script are public, and GitHub rebuilds the keys from the circuit and a public setup file on every change.
Neutral ground
ICE can build its own delivery log. It can't be the one place a firm, ICE and another data vendor all check the same record.
- A usage declaration in ICE's own fee categories, signed by ICE and the firm with the shared key
- The pull made around the agent gets its own declared line
- A figure built from ICE data and another vendor's data is credited to both
- Neither vendor sees the other's name, delivery or value
One real answer, two vendors
Claude Code, October 11, 2026, asked for yesterday's Brent settlement in euros.
- answer
- 77.60 EUR/bbl
- from ICE
- Brent settlement, 84.12 USD
- from vendor two
- EURUSD rate, 1.084
- public statement
- names no vendor, carries no value
- bent copies tried
- 16. All refused.
Both data servers are local stand-ins with made-up values. The session, signatures, log entries and checks are real.
10 · Neutral ground
Two records ICE can bill and settle from, kept where no single party controls them.
The usage declaration
This is the statement a licensing team wants at month end. Every delivery in the period, grouped into ICE's own fee categories. ICE's holder and the firm's holder each worked it out from their own records, and only then lent their part of the shared key. The rates stay in ICE's fee schedule. Nothing here sets a price.
| Fee category | Use | Deliveries | Rate | Amount |
|---|
| Check | Result | Detail |
|---|
Checking the declaration...
One figure, two vendors
The firm's agent pulled Brent from ICE and a EURUSD rate from a second vendor, then answered in euros. The firm registers one statement for that figure. It names no vendor and carries no value. Each vendor gets a private opening for its own input, and checks it against its own delivery log and its own copy of the session, where the other vendor's steps show only as fingerprints. ICE learns its settlement went into a figure with one outside input. The other vendor learns the same about its rate. Neither learns who the other is.
What the agent said
The public statement
| Who checks | Result | Detail |
|---|
Checking the split...
Ways to bend it. Each one is refused at the step that catches it.
Why this sits with a third party
Signed by both sides
The customer already agreed
The declaration carries the firm's signature before anyone talks about a bill. A billing question starts from a record the customer computed and signed itself.
Other vendors
Each vendor's data stays its own
A figure built from several vendors is credited to each, and none of them sees the others. ICE can't hold that record for another vendor, and another vendor can't hold it for ICE.
One log
Everyone checks the same entry
Both statements are in one public log that the shared key cosigns. ICE checks its entry with its own tools and never has to take Hive's copy on trust.
Open formats
Checkable without Hive
FROST (RFC 9591), RFC 9162 logs and IETF SCITT receipts. The code for every check on this page is public.
What it shows and what it doesn't. The declaration covers the four deliveries from the earlier gateway run, made by the stand-in market-data server. The two-vendor answer is one real Claude Code session against two local stand-ins with made-up values. Hive made every key here, including the firm's statement key. With two inputs and the result, each vendor could work the other's number out by arithmetic; with three or more inputs it can't. The split code and tests are public.
11 · ICE's own data
The same record, on ICE's published index data. This page never shows ICE's number. You bring it.
On October 11, 2026 a Claude Code session pulled the ICE BofA US High Yield Index effective yield for October 8 from FRED, where ICE Data Indices publishes it under licence, and the 10-year par yield from the U.S. Treasury. It answered with the spread: 289 bp. A thin adapter on the firm's side fetched each source live, signed a delivery line over the exact bytes the source returned, and had the witness countersign it before the agent saw anything. One statement went on the public log, naming neither source and carrying no value.
What the agent said
Checking...
| Check | Result | Detail |
|---|
Be ICE's side of the check
Open BAMLH0A0HYM2EY on FRED, read the value for October 8, 2026 and type it here. Your browser rebuilds the bytes ICE's adapter delivered, matches the signed delivery line and opens ICE's input in the logged figure. Try a wrong number too.
Waiting for the number.
The data is ICE's, through its public distribution. ICE's own delivery systems are not connected, and Hive ran the adapters and made their keys. The session, adapters and test are public; the test re-fetches FRED and runs the same check.
12 · The map
Seven pieces, built once, repeat across all 100 surfaces. Pick one and see where it goes.
Each tile is one of the 100 candidate surfaces from ICE's public materials: 60 customer workflows and 40 internal teams. A firm or vendor that joins one surface is already on the log every other surface uses.
ICE customersICE internal teamsRuns on stand-in dataRuns on ICE's published data
Every surface uses the public log0 surfaces run today, 0 of them on ICE's published data. The rest are mapped.
Pick a piece to light up the surfaces that use it, or a tile to see its pieces.
Mapped means the pieces fit what ICE describes publicly. It does not mean the surface is connected or that ICE has chosen it.
At ICE
The same record works beside ICE's entitlement system.
Before the call
The entitlement goes in first
The licensed datasets for a user or desk are signed before the agent's first pull, so a later reviewer sees what was allowed at the time, in ICE's own dataset names.
ICE's witness
ICE can run the witness
The witness is a small open server with a database. ICE can run its own, so a firm's record of an agent's pulls is held against a memory ICE controls. A firm can add its own witness too.
What is kept
Names and fingerprints
The record holds dataset names, tool names and fingerprints of inputs and answers. No ICE values, no prompts, no credentials. ICE content stays on the path it already travels.
For a firm, this answers the question its compliance team asks after the fact: which ICE datasets did this agent pull, under which entitlement, and can we show that nobody changed the record since. For ICE, the same record shows a pull outside a licence without ICE holding the firm's logs.
What this does not show
Hive does not decide who may see ICE data, block a call, sit in the request path or hold ICE data. ICE's entitlements and the firm's controls keep doing that. The record shows what was allowed, what the agent asked for, when, and that the record hasn't changed since. It doesn't show that an answer was right. The answer trail matches figures, so an answer that restates a number in words isn't linked. The vendor on each line is the MCP server's name, set by the recorder outside the agent's reach. The second set of sessions also used local stand-ins with made-up values, and the vendor's acceptance key was generated by Hive for the demo. The same goes for the delivery-log key behind "ICE's log": it belongs to a stand-in server Hive ran, so this run shows how the match works. It is not ICE's own log. This session used a local stand-in for a market-data server with made-up values, and Hive ran the witness for the demo, so this run isn't independent of Hive. With ICE or the firm running the witness, it is. In the gateway run, Hive also ran the gateway and both cosigners and generated their keys: the public log and the cosignatures show how the witness is held to one history, and they are independent only when ICE and the firm hold their own cosigner keys.
In the shared-key demo, Hive ran all three holders and made their identity keys; the ICE and firm holders are stand-ins until ICE and the firm run their own. The passport's bonds are fictional and its values come from a local stand-in server. In the neutral-ground section, both data servers are stand-ins and Hive made the firm's statement key.
Built with the same recorder shown on the public Claude Code page, which carries other real sessions and the open spec.