For ICE Data Services · Private
ICE Data Services MCP connector · one record per call
“A complete audit trail so that every output can be traced and trusted.”ICE, July 30, 2026 investor presentation
An outside review of the connector put it plainly: “We could not verify the authentication posture, and no one can from outside.” That is the gap a receipt fills. Seal the licensed set before the first call, bind every call to it after, and let anyone check it offline.
Pick a change. The verifier on this page rechecks every signature.
Run by Hive through a real LiteLLM proxy, in front of a stand-in that uses ICE's published tool names. Every value is fictional. Demo key Hive holds, so it is not independent.
Where it plugs in
At the firm
A firm that routes assistant tool calls through a gateway such as LiteLLM or Zuplo can use it today. Hive's plug-in for each is built and was run inside the real gateway. Pointed at fids-mcp.ice.com/mcp, it records every ICE call the firm's assistants make. The firm holds the key. Nothing changes on ICE's side.
At ICE
The same recorder runs next to the connector. It takes the licensed set from ICE's entitlement system before a user's first call and each answer's digest after. ICE holds the key, and a firm can check its own users' records without seeing anyone else's. This connects at onboarding.
What is kept
Each call carries the user, the tool, a hash of the arguments, the decision, the config version and a hash of the answer. No prompts, no ICE values, no credentials. ICE content never leaves the path it already takes.
Limit. ICE's connector needs ICE SSO and active licences, so this run used a local stand-in. The six tool names come from public listings (Manufact, Agentman). Nothing here touched ICE's server, and nothing here says ICE's checks are wrong.
The run
The desk key fi-desk-analyst-1 was licensed for four tools, and that set was sealed first. Call 3 asked for ids_compute, and the gateway refused it. Between call 4 and call 5 the firm's gateway config was widened to include ids_compute. The gateway, correctly reading its new config, let it through. The licensed set never included it. Maybe that change was approved. The point is that the record shows it, and shows when.
| # | Tool | Gateway decision | Dispatched | Against the sealed set |
|---|---|---|---|---|
| 1 | fids.ids_query_trades | allow config v1 | yes | inside sealed grant |
| 2 | fids.ids_get_reference_data | allow config v1 | yes | inside sealed grant |
| 3 | fids.ids_compute | deny config v1 | no | outside sealed grant, refused |
| 4 | fids.ids_describe_concept | allow config v1 | yes | inside sealed grant |
| 5 | fids.ids_compute | allow config v2 | yes | outside sealed grant, dispatched |
| 6 | fids.ids_query_trades | allow config v2 | yes | inside sealed grant |
Finding from the verifier: call 5: the gateway allowed fids.ids_compute and dispatched it, but fids.ids_compute is not in the scope sealed at 2026-10-09T17:26:44Z
Break it yourself
| Change | File | Result at build | In your browser |
|---|---|---|---|
| The refused call is rewritten as allowed | decision-rewritten.json | rejected ACTION_RECORDcall 3: the call record (tool, decision, response) was changed after signing | not run yet |
| ids_compute is added to the licensed set after the run | scope-widened-later.json | rejected SCOPE_MATCHthe disclosed scope is not the scope the grant signed | not run yet |
| The receipt for call 5 is edited to inside the grant | outcome-flipped.json | rejected PAYLOAD_DIGESTcall 5: the signed body was changed after signing | not run yet |
| Call 5 is deleted from the bundle | call-removed.json | rejected CHAIN_COUNTthe chain seals 6 calls, the bundle carries 5 | not run yet |
| Two calls swap places | calls-reordered.json | rejected CHAIN_ORDERchain step 0 is not call 1 as signed, a call was removed, added or reordered | not run yet |
| A different answer is put on call 1 | response-swapped.json | rejected ACTION_RECORDcall 1: the call record (tool, decision, response) was changed after signing | not run yet |
| The bundle claims a different signing key | other-key.json | rejected SIGNATUREgrant: the signature does not match the key in the bundle | not run yet |
Limit. These are the edits we thought of. The recorder now also sends each call's fingerprint to a witness that remembers, before the call runs, so even a record rebuilt by whoever holds the signing key stops matching. See it with a real AI agent pulling licensed datasets.
Check it on your machine
Limit. Needs Node 20 or later. The verifier has no dependencies and is short enough to read before you trust it.
Logged in public
The log is append-only, with signed tree heads. Each entry has an inclusion proof, and the new head is proven consistent with the one before it, so nobody can quietly remove or rewrite these calls later.
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 gateway keep doing that. A receipt shows what the licensed set was, when it was sealed, what the gateway reported for each call, and that none of it changed afterwards. It does not show an answer was correct, or that a widened config was a mistake. The plug-in fails open: if the recorder is down, the call still goes through and is missing from that run's bundle. The bundle here was signed with a demo key Hive holds, so it is not independent. In a deployment the firm, or ICE, holds the key.