Security and privacy

OCC's security and privacy claims are not slogans. They are properties of the code, mostly enforced structurally rather than by policy. This page maps each claim to where it lives in the system, and is explicit about what OCC does and does not defend against.

Where your data goes

Three kinds of data are involved in a typical OCC interaction: your queries, your pack content, and the inference workload. Each follows a different path.

Your queries

In local mode (the default), your query is processed entirely on your machine. The classifier, the decomposer, retrieval, the Expert, the Critic, the Synthesizer — every step runs locally. The query never leaves the Node.

The Node does need to ask the broker which pack pages are relevant, and to fetch those pages. The broker therefore sees your sub-queries — the decomposed topical phrases — over an HTTPS connection. It does not see the original natural-language question, and it does not maintain a per-user query history. The broker's role is search, not logging.

In network mode — when the Critic step is delegated to a peer Node — the Critic payload (the manifest, an excerpt of the retrieved context, and the Expert's draft) is encrypted with the peer's public key before leaving your machine. The broker routes the ciphertext to the peer; the peer decrypts, runs the Critic, encrypts the response back, and returns it. See End-to-end encryption below.

Your pack content

A private pack lives entirely on your machine. The Node uses it to answer your questions. The pack content does not appear in any search index outside your machine, is not uploaded anywhere, and cannot be discovered by other Nodes. There is no "share to network" toggle that could be flipped accidentally — public packs are submitted through a deliberate pull-request process, not by the Node.

A public pack is, by definition, public. Once it has been reviewed and deployed to the broker, its content is served to any Node that asks. If a piece of information should not be public, it does not belong in a public pack.

Your inference

By default, the Node runs inference locally with a Qwen model. No remote inference provider is involved.

When the user opts to use OpenRouter as an alternative inference backend (with their own API key), the model is still Qwen. The user's queries and the Node's prompts are sent to OpenRouter the same way any other application would send them — under the user's account, billed to the user, subject to the user's agreement with that provider. OCC adds nothing to that path.

The web-tool gate

The Node has a small set of agentic tools available in chat mode: reading a file in the workspace, writing a file, listing files, running a piece of code. These work without further confirmation — the user is in control of their own workspace.

Web tools — searching the open web, fetching a URL — are gated separately. They are exposed to the model only when the user's current message explicitly invokes the web: a URL embedded in the message, or words like "web", "online", "internet", "search the web". Without one of these triggers, the web tools are not in the schema the model receives.

The reason matters: OCC's value comes from answers grounded in community-curated packs, not in whatever happens to be on the open web today. Allowing the model to silently consult the web would compromise that guarantee. The gate enforces the principle in code.

End-to-end encryption in peer reviews

When the Critic step runs on a peer Node, the payload is encrypted with the peer's public key and decrypted only on the peer. The broker, which routes the encrypted payload from requester to peer and the response back, never holds the keys.

What this means concretely:

• The user's query and the Expert's draft are visible to exactly two parties: the user's Node and the peer Node selected for the Critic step.
• The broker sees ciphertext. An operator with full broker access can observe that a payload was routed between two Node IDs but cannot read its content.
• Each Node generates its own keypair on first run. The public key is shared via the broker's peer registry; the private key never leaves the machine.

Defense against GEO

A specific threat to AI systems that draw on the open web is Generative Engine Optimization — the practice of injecting content into the public web specifically to manipulate what AI systems say about a topic. A model that crawls the web is permanently exposed: an attacker who seeds enough optimized content can shift the model's output on a chosen subject.

OCC is structurally immune to GEO at the retrieval layer:

• Nodes do not crawl the web. They retrieve from packs hosted on the broker.
• Every pack is built from sources explicitly approved by the community before they could be incorporated.
• The source registry — the list of approved domains — is itself public and reviewed.

The remaining attack surface is the source registry: an attacker who could get a manipulated source domain accepted into the registry could influence packs built from that domain. This requires getting a public pull request through review — orders of magnitude harder than seeding SEO content. The defense is the openness of the process, not its obscurity.

Pack integrity

Today, pack integrity rests on two mechanisms:

• The packs are version-controlled in a public repository. Every change is a normal pull request, reviewable, with a full history.
• The broker serves the packs from disk, and operators of the broker are accountable for not tampering with what they serve.

Pack signing — a cryptographic signature in manifest.yaml over a content hash of the pack's files — is on the Roadmap but not yet implemented. When it ships, Nodes will be able to verify that a pack fetched from any broker is bit-identical to the version the maintainer signed, regardless of the path it traveled.

What OCC does not defend against

• A compromised user machine. If an attacker has root on your laptop, they can read your private packs, your queries, and the model's outputs directly. OCC is not a defense against local compromise; it is a defense against remote inference services and uncontrolled web sources.
• A malicious local model. OCC trusts the model weights it loads. A backdoored Qwen variant downloaded from an untrusted source would be a problem. Stick to official Ollama distributions and verify model checksums when in doubt.
• A malicious peer Node. A peer can return a misleading Critic review. The Synthesizer takes the review at face value, but the Sources panel surfaces the full review to the user, so a clearly wrong Critic produces a visibly inconsistent final answer that the user can spot.
• A malicious broker operator. A broker operator can serve modified packs, or refuse to route peer payloads. Pack signing (planned) addresses the first; the broker's replaceability and the public pack repository address the second.
• Intentionally bad sources accepted into the registry. The mitigation is process discipline, not technology.

---

The principles behind these choices are in Principles and design; the mechanics of the broker (including its WebSocket peer-routing surface) are in The broker and the network.