Security

How the hosted review handles repository content. Report a vulnerability to hi@cerebe.ai. The contact file is /.well-known/security.txt. The companies are on the subprocessor list.

Code

To review a change, Cerebe sends the change and the repository content that review needs to the companies on the subprocessor page. Critics see only the change and the repository it belongs to, in an isolated sandbox with no web access. Model keys never reach them. Each review's sandbox is torn down after the review. Models run on major cloud providers in US regions.

Cerebe uses that content to produce the review. Cerebe does not train a model on it. Cerebe does not state what those companies do with it under their own terms.

Prompts

The instructions Cerebe sends with a review are Cerebe's, and they go to the same companies as the code. Text that is part of the change is code, and the paragraph above covers it.

Derived data

A review produces findings and a verdict. Verdicts are signed and independently verifiable. That record is kept as the product of the review. Retention and deletion controls are on the roadmap.

GitHub App permissions

The Cerebe Factory GitHub App is granted these permissions:

• Contents: read
• Pull requests: read
• Checks: write
• Issues: write
• Actions: read
• Administration: read
• Merge queues: read
• Metadata: read

It posts the check named cerebe/critic. It is not granted permission to write repository contents. It does not push code, and it does not approve or merge a pull request.

When a review cannot finish

If the review cannot finish, the check retries once. If it still cannot finish, the check completes as a failure, titled “could not complete (re-run)”. Where the repository requires the check, that failure blocks the merge until a review finishes.

A repository can set gate.on_infra_error to pass on its base branch. That choice makes the same outcome non-blocking. The setting is read from the base branch. A pull request cannot change it for itself.