autoarc is a local-first system for trusted repositories.

That trust boundary is the most important thing to understand before using it.

autoarc will, on your machine and with your local user permissions:

• run pi against a working copy of your repository
• execute bun run .autoarc/benchmark.ts
• run local git commands to create worktrees, commit changes, and promote successful candidates

If you would not manually run model-authored code in a repository, do not point autoarc at that repository.

autoarc is built for:

• local development machines
• trusted repositories you control or are comfortable modifying locally
• bounded experiments whose success is determined by a benchmark you can read and understand

autoarc is not designed to be:

• a sandbox for untrusted code
• a multi-tenant service
• an internet-facing autonomous coding service
• a secrets-isolation boundary

• Start with make live-test before targeting a real repository.
• Use clean repositories only.
• Read the generated .autoarc/design.md and .autoarc/config.json before running larger jobs.
• Keep API access local to 127.0.0.1 unless you have a specific reason not to. If you expose the API more broadly, set API_KEY.
• Prefer repositories or clones that do not contain unrelated secrets or credentials.
• Review promoted changes before carrying them elsewhere if the repository matters.

• AGENT_TIMEOUT_MS limits each pi design or experiment command.
• BENCHMARK_TIMEOUT_MS limits each benchmark run.

These bounds are there to make failures legible and prevent jobs from hanging indefinitely. They are not a security boundary.

If you find a security issue in autoarc, please open a private report with the maintainers before publishing details broadly.