CroCodeDocumentation
Security
Understand the sandbox, credential boundaries, and data exposure limits.
On this page
Trust boundary
Treat the pull request author, text, code, repository files, and agent output as untrusted. The operator, base-branch config, database, GitHub App key, and Docker daemon are trusted.
Prompt boundaries and read-only tools reduce risk. They do not prove that a model will ignore hostile instructions. Read-only files do not stop a process from executing code or sending network requests.
Sandbox controls
| Control | Value |
|---|---|
| Root filesystem | Read-only |
| User | 10001:10001 |
| Linux capabilities | All dropped |
| Privilege escalation | no-new-privileges |
| Resources | 512 processes, 4 GiB memory, 2 CPUs |
| Repository and inputs | /repo:ro and /input:ro |
| Result directory | /output:rw |
| Temporary files and agent home | Separate 512 MiB tmpfs mounts with nosuid,nodev |
Credentials and checkout
The API checks webhook HMAC SHA-256 before parsing or recording an event. The worker creates a token scoped to one repository. Git receives it through environment config, not a URL or command argument.
The worker removes .git before starting the agent. It does not fetch submodules. Repository symlinks become plain text files. The sandbox receives no GitHub token, App key, Docker socket, or dashboard secret.
The worker redacts known passed secrets of at least eight bytes before storage. This covers exact strings. It does not cover encoded, split, transformed, or unknown secrets.
Finding validation
Findings must use normalized paths from the reviewed diff. Inline comments need RIGHT-side lines. A multiline range must stay in one hunk. Other valid findings move to the summary.
CroCode escapes HTML, disables Markdown images, breaks mentions, removes control characters, and limits output length. It removes previously published finding fingerprints.
Ordinary links remain. Check their destinations before following them. Sanitization is not complete data-loss prevention. A person must review suggested patches.
Host and network isolation
- Use a dedicated host or Docker daemon. Give socket access only to the worker.
- Keep host credentials and unrelated data off that host.
- Use a private work directory and a filesystem disk quota.
- Put sandboxes on a dedicated network. Deny direct egress and allow model traffic through a restricted proxy.
- Check an allowed provider connection and a blocked destination before use.
Choosing a Docker network does not create firewall rules. A read-only worker UID does not remove Docker socket risk. An optional runsc runtime requires separate installation and testing.
Known limits
The worker removes completed reviews after 30 days. It removes deleted installations’ reviews on its next cleanup pass. Cleanup runs once per minute and removes findings and patches too. Active jobs remain unless their installation is deleted. Protect the database and its backups as source-code data. Backups and GitHub reviews need a separate retention policy. A host crash can leave checkout files behind.
Cancellation can take until the next heartbeat. The installation concurrency cap is soft. A crash between GitHub publication and its database update can cause a duplicate review on retry.
Read the full security model for verification results and dependency advisories.