badBots — Operator Access Policy (v1 draft)

The published commitment on how the Operator may access customer systems (Constitution I/II, FR-025). Honest v1.

badBots runs on a single-trusted-operator model. This policy is the public promise that bounds that trust.

Principles

  1. Maintenance-only. Operator access to a customer VPS is for provisioning,

incident response, billing enforcement (key disable), backup/restore, and erasure — never to read your conversations for any other purpose.

  1. Logged. Every administrative access is recorded (what, when, why) in an

operator-access log retained for audit.

  1. Notice where practical. For non-emergency maintenance that touches your

bot, we give notice where practical. Emergencies (runaway spend, security, outage) may require acting first and notifying after.

  1. Least access. Routine fleet operations (status, reconcile, balance) use

scoped, least-privilege tokens — not full shell — wherever the operation allows.

What the Operator can technically do (disclosed)

runs hardened (non-root, dropped caps); the Operator's host access is broader.

offline** (each customer's backup key is independent and is itself encrypted to that master). The online fleet-manager holds no key that decrypts any backup; an online breach exposes no readable customer data. This exists for restore + lawful continuity, and is the core of the trust model (see privacy policy).

balance is exhausted, or for abuse/emergency).

The Operator cannot silently exfiltrate your live LLM traffic centrally — there is no central proxy; your VPS calls the provider directly (falsifiable by network capture).

Your recourse

but accountable.

Contact: morgantrowland@protonmail.com.