Skip to content

Confidentiality

What refereekit sends, what stops it sending more, and what protects a paper on your disk.

The paper’s text leaves your computer by one route: the model backend, the language model you choose to read it. Two checks stand on that route, in order. The venue gate comes first. Then the attestation: refereekit sends nothing to a backend unless you have declared that it keeps no data.

Every step that sends the paper passes through this gate: the question loop, the drafts, the OpenReview form and the analysis of the authors’ replies, which quote the paper.

You can see the gate refuse on the tutorial session. Before you make the attestation, ask the agent to draft the tutorial’s report again. The private view shows:

refusing to send: backend is not marked zero_retention

The agent gets the code retention-refused, and no request reaches the network.

The attestation is your statement that the account behind the model backend keeps no copy of what it is sent. You make it in Model access, as a checkbox on the reviews folder’s page or a yes in pi’s /refx-model. refereekit cannot check it. Once you make it, every deployment is treated as keeping nothing, whatever its account really does. What you assert depends on the deployment:

Deployment What REFEREEKIT_ZERO_RETENTION=1 asserts
anthropic Your organization has a zero-data-retention arrangement.
bedrock Your AWS account has no model-invocation logging.
vertex Your project’s logging and retention settings permit it.
claude-cli The Claude Code login that refereekit runs as claude -p sits on terms and settings that retain nothing.

On bedrock and vertex the statement is about the cloud provider’s terms. The claude-cli row is the hardest to make honestly. Consumer and subscription plans generally offer no zero-retention terms. That deployment fits papers that are already public. It is the wrong deployment for a manuscript under review, unless your terms say otherwise.

The agent cannot make it for you: no tool takes it.

Some venues forbid sending a submission to any outside model. Zero retention is no exception to that rule, so refereekit checks the venue before the attestation.

refereekit’s table has exactly one entry, NeurIPS. Any venue name that contains it matches, so NeurIPS.cc/2026/Conference is refused. Every venue the table does not match is permitted. It cannot know every venue’s rule, so check your own first (see Before you start).

Start a review of a NeurIPS paper, and the review window shows:

NeurIPS.cc/2026/Conference prohibits sending the submission to an outside model, so this command will not send it. Use the venue's own review interface. If this rule has changed, add to your venue policy file (…/reviews/venue-policy.toml) under [venues]:
neurips = { llm = true }

Nothing is sent. Steps that send nothing, such as checking a draft, still work.

To add a venue, edit venue-policy.toml in your reviews folder with any text editor. A line such as "Some Journal" = { llm = false } refuses that venue. An entry with llm = true lifts a refusal, and nothing else: the attestation is still checked.

The gate can only act on a venue it knows. The session records the venue you name when it starts, or the one OpenReview gives. A review on a session with no venue asks you for one before its first question.

Venue notes hold only your own words. Before a note is stored, refereekit compares it with the paper’s text, and refuses it if it matches. A paper with no readable text refuses every note, rather than letting one through. Your voice says what the guard rejects.

The agent’s model is not trusted with the paper. No word of the paper, and none of yours, reaches it from refereekit. They appear only in a private view on your own screen.

What you type in the chat reaches the agent’s model, and so does every tool argument, such as the PDF’s file name. Keep the paper’s title out of them (see What you give the agent).

Three layers keep the paper out of the agent’s view:

  1. Tool results carry counts and codes only.
  2. A hook guard, a guard program that blocks the agent’s file tools, keeps them from session files, .env and the PDFs.
  3. The agent’s instructions tell it not to try.

This prevents accidents. It is not a sandbox. What protects the manuscript, and where it stops gives each layer’s limit.

Claude Desktop and the ChatGPT desktop app run no hooks, so the second layer is missing there. Whether the app’s model can read a session file then depends on what other tools you connected to it (see Desktop apps: no hooks).

Setup writes a .gitignore in your reviews folder, or adds the lines an existing one lacks:

# refereekit: manuscripts and everything derived from them
work/
*.pdf
.env
.env.*
!.env.template
*.db
questions.json
questions.txt
verdicts.json
answers.json
index.html
*.png

Each line applies at every depth. Most session files have no line of their own, so only work/ protects them. Keep every session inside work/. If the folder is in git, commit files by name.

You enter your model key, your OpenReview password and the attestation only in a private view. That is the reviews folder’s page, which the agent opens for you, or /refx-model in pi. The view saves them to the folder’s .env, which only you can read. It never shows a stored secret again. In pi the dialogs have no password field, so a key shows on your screen as you type it.

Never paste a key or a password into the chat. No tool takes one, and a call that tries is refused without repeating the value. Where hooks run, the hook guard also stops the agent from reading or writing .env.

refereekit reads these settings from the environment first, then from the .env of your reviews folder. It reads no other .env.

Two other requests leave your computer. Fetching from OpenReview logs in with your account and downloads the paper, the form and the replies. There is no code that posts to OpenReview. And the Q&A page, opened from disk in a browser, loads the MathJax script from a public site, a request that carries nothing of yours.