/privacy
Privacy & security: what IICP protects, and what it does not yet protect
This page is intentionally plain. IICP is a live beta network, not a finished privacy product and not a legally certified compliance product. Some protections already work, some are in transition, and some still need broader testing before they should be trusted by default. The long-term goal is simple: important claims should be checkable through protocol behaviour, usable controls and clear evidence, not just believed.
Expert view: this page ties public claims to current software behaviour, live observations and roadmap state as reviewed on 2026-08-20. Public SDK registries publish Python, TypeScript and Rust v0.7.109 with retry-safe heartbeat outcome delivery, additive discovery explanations, fail-closed/keyless-node defaults, consistent model/QoS/region/reputation projection into provider discovery, remote-routing policy profiles, coordinated tunnel contention backoff and supervised temporary-failure recovery; the browser consumer also has a strict allowed-region guard for policy-bound routing. Live SDK adoption, complete key coverage and encrypted round-trip evidence are still rollout gates, so the live stats page remains the source for current node counts. Self-verification remains the principle: node, routing, retention, fallback, transfer, rights-handling and directory claims should become machine-checkable over time.
Short version
Use local browser inference for the strongest privacy today. Use remote mesh nodes only for data you are comfortable sending to the selected node operator. Verified operators can now use their local client to export or manage directory records without uploading a private key. The live network still needs broader key, transfer and real-world evidence.
Current posture: directory-only control plane; current directories use canonical cx_public_key while SDKs retain a short compatibility fallback for older directory releases; current clients refuse keyless nodes by default unless an explicit debug override is set; the browser consumer can enforce a strict allowed-region policy before dispatch; public registries publish Python, TypeScript and Rust v0.7.109; live adoption and key coverage must be verified from the current stats before any full-cutover claim; remote executor still sees plaintext. Operator-key DSR export/restrict/anonymise commands and a local-only receipt viewer now provide a guided rights path without browser key storage. Metadata privacy, key transparency, response encryption wiring, forward secrecy, broader self-verifying manifests/receipts, operator-bound transfer evidence and executor-blind inference remain roadmap work.
What works today
These are current capabilities, with caveats shown where needed.
The directory helps agents find each other; it is not the task processor.
IICP is mainly a map and coordination layer. It helps a client find a suitable node, but the actual AI task is sent to the chosen node, not processed by the directory website.
Expert detail: The directory exposes discovery, registry, stats, credits, events and related control-plane endpoints. Task execution is node-to-node; directory routes are not the inference path.
Local/browser inference is the strongest privacy mode today.
If the model runs in your own browser, your prompt does not need to leave your device. This is the clearest privacy path for sensitive experiments.
Expert detail: The browser-node surface uses WebGPU/WebLLM for local execution where supported. Mesh consume remains available separately, but local mode avoids remote operator exposure entirely.
The SDKs now encrypt automatically when a node publishes an encryption key.
The encryption machinery exists and is turned on when the chosen node has a published key. The visible live mesh is key-ready today, but this must stay true as outside operators update and new nodes join.
Expert detail: Current Python, TypeScript and Rust clients use canonical cx_public_key from current directories and retain a short read fallback for older directory releases. They refuse plaintext to keyless nodes by default unless the explicit transitional debug override is set, and Docker/serve providers can fall back to a paced Quick Tunnel or relay path only when direct reachability is not available. Key-ready listings remain weaker evidence than a verified encrypted round trip.
Some self-verification foundations already exist.
IICP already exposes live status, public protocol documents, public SDKs and a signed event log. That means some claims can be checked instead of only trusted.
Expert detail: Current foundations include open protocol/spec surfaces, live /stats and /discover data, public SDKs, signed control-plane event work, and conformance probes. These verify parts of the control plane, not every node policy or retention claim yet.
A technical privacy and compliance-readiness baseline now exists.
There is now a public GDPR transparency baseline and a way to handle access, export, restriction or anonymisation requests during beta. IICP is an unfunded, non-commercial research project and the website is a public reference, not a service. Formal organizational details and legal review remain future work before any service offering.
Expert detail: The technical readiness work added a purpose/lawful-basis draft, retention matrix, breach runbook, DSR workflow, signed operator-key actions, AI-risk classification, DPIA and processor/transfer baselines, release gates, signed node-policy manifests, operator-bound evidence and strict browser region filtering. These are engineering controls, not legal conclusions. Formal controller, retention and recipient details remain organizational work before IICP is presented as a service; AI Act duties still need role- and deployment-specific assessment.
The project is already live, but still beta.
IICP has real nodes, SDKs and a website, but many features still need broader testing with more people, devices and network setups.
Expert detail: Controlled tests are not the same as broad population evidence. Relay, browser-provider mode, key advertisement, NAT paths, self-updates, CORS/browser behaviour and failure recovery need larger sample sizes across independent clients and nodes.
Current limits
These limits are not hidden in small print because they affect how you should use the network.
A remote node can read the prompt it runs.
Encryption can protect the prompt while it travels, but the node that runs the AI model must eventually see the prompt to answer it. Do not send secrets to an unknown remote operator.
Expert detail: IICP-CX protects against the directory, relays and passive network observers when the selected node advertises a key. It does not make normal remote inference executor-blind; TEE/attested execution is a future research track.
Fail-closed encryption depends on live adoption, not only published code.
The newest clients refuse keyless nodes by default. The live node list may show all visible nodes key-ready, but this still has to stay true as outside operators update and new nodes join.
Expert detail: Strict current clients now fail closed, with an explicit transitional debug override for plaintext. The remaining gate is not only node count: provider key rollout must remain complete across churn, encrypted round-trip evidence must be refreshed, ambiguous key aliases should be removed, and any downlevel/keyless capacity must be remediated.
IICP does not provide anonymity yet.
The network does not yet hide which nodes exist, what they offer, or which kind of routing happened. Metadata privacy is separate from payload encryption.
Expert detail: Discovery exposes node endpoint, transport, models, region, reputation, SDK version and operator-facing metadata. Request unlinkability, private discovery and traffic-analysis resistance are not current guarantees.
Relay and browser-provider mode are experimental.
Relays help browsers and home-network nodes participate. They now recover better from ordinary network interruptions, but relay trust, health and abuse resistance still need more hardening.
Expert detail: The live status currently shows a relay-capable route, and supervised nodes have recovered from sleep/tunnel cooldown without manual restart in live use. Relay code and browser-provider glue exist, but relay bind security, attestation/trust, availability, browser validation and relay-path confidentiality remain active roadmap items before relay is promoted as dependable infrastructure.
Reputation is useful, but not yet cryptographic proof.
A node score can help choose better nodes, but it should not be treated as a guarantee that the operator is honest or the answer is correct.
Expert detail: Current ranking uses reputation/health signals and caps, but zero-knowledge or receipt-backed proof of work and quality is future work. Reputation is a routing signal, not a security certificate.
Node retention, operator identity and policy claims are not fully self-verifying yet.
A node should eventually say, in a machine-readable way, what it logs, retains, reviews, trains on, where it operates, and who is accountable for the claim. That is not complete across the live mesh yet.
Expert detail: The self-verification target is signed node manifests with capability, policy, jurisdiction, retention, fallback and unsupported-feature declarations that clients can compare against user policy before sending a prompt. The directory now exposes the first operator-bound signal when a manifest key matches a verified operator delegation key; the next maturity step is known-operator terms/DPA evidence, durable revocation lists and cross-SDK strict routing.
Federation is intentionally not released broadly yet.
A federated directory network is planned, but releasing it before the core is stable would make every future fix slower to roll out.
Expert detail: Federation pieces exist, but public federated directory SDKs/software are gated until IICP is feature- and security-stable. Otherwise each compatibility/security change would need coordination across independent directory replicas.
What comes next
The roadmap focuses on closing the gap between implemented mechanisms and release-grade guarantees.
Finish key advertisement and fail-closed encryption.
Every usable remote node should publish the key needed for encrypted tasks, and clients should refuse nodes that cannot receive encrypted tasks.
Expert detail: This closes the remaining gap between implemented IICP-CX primitives and live-mesh enforcement: provider keys everywhere, downgrade protection, live round-trip tests, no ambiguous key fields, and no usable downlevel/keyless capacity.
Add stronger recipient-key verification.
Clients should be able to know they are encrypting to the real node operator, not just to whatever key a directory response returned.
Expert detail: The planned direction is operator-signed encryption keys and key transparency anchored in the signed event log.
Encrypt responses and improve session secrecy.
The answer path should get the same privacy attention as the prompt path, and old sessions should stay protected even if a later key leaks.
Expert detail: SDKs already include Tier-2 response-encryption primitives, but response encryption and forward secrecy are not yet fully wired into the live task flow.
Harden relay, browser-node and operator onboarding.
The system needs more real-world tests with more nodes, more browsers, more home networks and more failure cases.
Expert detail: Population testing should cover relay trust, bind/session abuse, CORS, WebGPU devices, NAT/CGNAT paths, tunnel rotation, self-updaters, SDK parity and mixed-version behaviour.
Add self-service rights, operator and compliance controls.
The beta manual privacy-request path should become easier: a protected page or portal where verified operators/users can export, restrict, anonymise or review retained records without exposing secrets.
Expert detail: The signed DSR/operator API is the foundation for a guided self-service portal. Planned controls include broader redacted action receipts, cross-client known-operator transfer enforcement evidence, strict known-operator profiles and compliance CI checks that catch prompt-to-directory leakage, keyless routing regressions and missing privacy documentation.
Make important claims self-verifiable.
The goal is not “trust us”. The goal is that users and clients can check who served a request, what was promised, where it went, and whether fallbacks or policy changes happened.
Expert detail: Reduced self-verification roadmap: signed node manifests, machine-readable retention/policy declarations, capability challenges, routing receipts, explicit fallback disclosure, directory neutrality rules, multi-directory cross-checks, public conformance suites, extension registry discipline and fork continuity pack.
Research executor-blind and metadata-private inference.
The long-term goal is that even remote inference reveals less to the network and eventually less to the operator running the node.
Expert detail: Research tracks include confidential-computing/TEE execution, metadata privacy, private discovery, and cryptographic/zero-knowledge verification for reputation or work receipts.
Broader testing caveat
Most privacy and security features still need extensive testing with a broader population of IICP clients and nodes. As more operators, browsers, devices, relays, SDK versions and network conditions are observed, this page should be updated with better caveats, stronger evidence, and corrected claims where reality teaches us something new.
Useful public evidence sources include the transparency claims ledger, privacy-first simulation/change plan, compliance-readiness audit/remediation notes, the privacy notice baseline, relay-bind design notes, node-confidentiality research, zero-knowledge research, current SDK changelogs, live /api/v1/stats, live discovery output, and the public roadmap.
EU privacy and AI transparency boundaries
IICP is non-commercial research and this website is not a hosted AI service, but those descriptions are not blanket GDPR or EU AI Act exemptions. The privacy baseline records current data flows and unresolved controller information; the AI transparency baseline explains first-interaction notices, generated-output metadata, and the component-specific assessment still required under the final Article 50 guidance.
Last reviewed 2026-08-01. This page describes protocol and network privacy/security posture. The separate GDPR transparency baseline records current data flows and the formal-notice work that remains. If a claim becomes stale, the honest fix is to update the claim or downgrade it until verified again.