Security and privacy
What leaves your machine, and how ocra is isolated.
What is sent to the model provider
- The reviewer's instructions, the change request title and description, and the diff of the files under review.
AGENTS.mdand matching.ocra/rules.jsonrules.- File content and search results that reviewers request through their tools.
- Accepted findings from
.ocra/memory.jsonfor the files under review. - For verification, each file's findings with its diff and the lines around them; for judging, the findings with the change request's title and description.
Nothing else is added: ocra starts its agent runtime with your global OpenCode configuration, installed skills and project instruction files disabled, so details of your machine do not end up in prompts.
Isolation
- The OpenCode runtime runs on
127.0.0.1with a random port and a random password per run, and keeps its state in a temporary directory that is removed afterwards. - Review tools are served from ocra's own process on
127.0.0.1, protected by a random bearer token. - The runtime receives only system basics and the credentials of the providers in your model chains, not your whole environment.
- All built-in agent tools (shell, file editing, web access) are disabled; reviewers can only read the revision under review.
- Paths requested by a model are confined to the repository, including through symlinks.
- Reviewers cannot read, diff or search likely secret files (
.env, keys, certificates, cloud and registry credentials,*.tfvars) or anything under.git/, even when the file exists on disk or a prompt asks for it. The same patterns keep those files out of review.
Untrusted input
Pull request text, diffs and repository files are treated as data. Instructions inside them are never followed, and text that imitates ocra's prompt structure is neutralized before it reaches a model. Text ocra prints to your terminal (findings, commit messages, errors) has control characters, escape sequences and bidirectional overrides replaced, so a change cannot rewrite your screen, hide a finding or write to your clipboard.
The verdict is not a security gate
Every model in the pipeline, the reviewers, the verifier and the judge, reads the change under review, so the change can try to steer them: hide an issue from a reviewer, or argue a finding away in front of the judge. Code limits the damage: only a critical finding the verifier confirmed can make the verdict significant_concerns, and the judge cannot drop such a finding. But a clean verdict never proves a change is safe. Keep human review and dedicated security tooling for anything that must not slip through.
Shared configuration
extends fetches settings and rules over https only, never plugins, and can be pinned with #sha256=. For pull requests it is read from the base commit like the rest of the configuration.
Keys
Provider keys are read from environment variables only and never written to configuration, logs or session files. Secret files in the repository are unreadable to reviewers (see Isolation), so their contents cannot end up in prompts, reports or session files either.
CI
- Store keys as CI secrets.
- Do not run ocra with secrets on untrusted code via
pull_request_target. ocra review --prand the GitHub Action read.ocra/config.json,.ocra/rules.jsonandAGENTS.mdfrom the pull request's base commit and never load repository plugins. See GitHub pull requests.
Reviewing code you do not trust
.ocra/config.json can list plugins, and plugins run code. ocra review --no-repo-config ignores that file entirely and takes models from OCRA_MODEL_*. ocra-eval always passes it, because benchmark repositories are third-party code.