Security

arbiter.run is served over TLS. The website is static-first and keeps public docs separate from authenticated application code. Operational logs are used for reliability, abuse prevention, and incident investigation.

The open-source runtime binds to loopback by default and is designed to sit behind operator-controlled infrastructure when exposed over HTTP. Production deployments should add TLS, rate limiting, and abuse controls at the proxy or infrastructure layer.

When the HTTP API is enabled, requests authenticate with bearer tokens tied to tenants. Tenant reads enforce tenant identity across conversations, memory, artifacts, schedules, and agents.

Shell execution (/exec) is disabled by default in the API server. Operators can enable the per-tenant Docker sandbox so /exec, /write, and /read share an isolated workspace with configured CPU, memory, PID, network, and disk limits.

arbiter.run does not use prompt or response content for model training. Local runtime deployments send prompts only to the model providers and tools you configure.

If you believe you have found a security vulnerability, please report it privately to security@arbiter.run before disclosing it publicly. Include enough detail to reproduce the issue. We will acknowledge your report, keep you updated on remediation, and credit you if you would like.

The runtime repository also ships a SECURITY.md with in-scope / out-of-scope guidance and operator-hardening notes.