Docs / For maintainers & developers / 04

Safeguards & privacy

What session data is public, how multiple keys work, and what opub never collects.

3 min read / Guide 04
maintainers privacy

Spend against donated compute is intentionally transparent. This page explains exactly what is visible, what isn't, and how multiple keys fit into a project.

Session linking and what's public

When you run opub run, the CLI starts a local work session linked to your compute key. The launched agent and local opub MCP server receive secretless project and session context for the directory where you ran it, including repository origin, current commit, project association, target agent, and session timestamps. The public project ledger shows spend tied to the compute key as Linked, but does not publish repository origin, commit hash, branch, session ID, or session timestamps.

What is public:

  • Token count and dollar amount for every spend event against donated compute
  • The compute key name (not the credential)
  • The model reported for the spend event
  • A Linked badge when spend is tied to a compute key

What local opub session context can expose to the launched agent:

  • Project association and compute key ID
  • Repository origin, branch, and current commit hash
  • Target agent and session state/timestamps

What opub never collects:

  • Prompts, completions, or any model input/output
  • File contents, diffs, or repository data
  • What the agent is doing or how

Provider and model data policies still apply to actual model usage. opub does not add prompt, response, diff, or file-content collection on top of the provider request.

The session records local Git context at launch for agent-side linking and operator clarity. Public spend attribution accrues to the project through the compute key, not by publishing that local Git context. If you use the key directly without opub run, spend still accrues to the project — the local session link is simply absent.

Multiple keys

Multiple active keys are supported. Use separate keys when you want distinct spend tracking for different workflows (local dev vs. CI vs. a specific branch) or when you share a project with another maintainer who sets up their own key. Each key has its own limit, spend history, and credential.

Safeguards

opub applies protective measures to credentials and session metadata.

Secretless session context — MCP tools return project, key, target, and session metadata only. They do not expose the provider key or inspect prompt, response, diff, or file contents.

First-party provider allowlist — compute keys are restricted to Anthropic, OpenAI, Mistral, and MiniMax. Keys cannot be routed to arbitrary or third-party endpoints, reducing the surface for credential misuse. See Available models for the full list.

Minimal local contextlinked sessions expose repository origin, commit hash, target agent, and session timestamps to the launched agent and local MCP tools, not to the public project ledger. Direct key use skips that local session link.

These safeguards are applied automatically. No configuration is required.

The CLI is open source — the code that runs on your machine is publicly auditable. Trust, but verify! Read the source at github.com/opubdev/opub-cli.

Even with these safeguards, use caution with what you expose in any working session.

Privacy for your account

Your GitHub login is used only to verify repository access. opub does not read repository contents, issues, pull requests, or any data beyond the public profile and repository list needed for verification. Spend events associated with your compute keys are the only maintainer-linked data shown on the public project page.

We also request your email so that we may contact you if needed. Anything but the bare minimum transactional emails will require your clear consent.

Was this helpful?

Send feedback