Terms of Service & liability terms

[JSONbored]

Problem: An autonomous agent merging code into a paying customer's live repository, funded through decentralized compute, carries real liability exposure with no terms defined today.

Area: Legal / Product

Proposal: Draft Terms of Service covering autonomy scope, liability for autonomous actions, refund policy, and data handling. This explicitly needs real legal counsel review before publishing — an engineering draft alone is not sufficient sign-off for this issue to close.

Deliverables:

• Published Terms of Service, reviewed by legal counsel.

Acceptance criteria:

• Terms are reviewed and approved by legal counsel, not just drafted internally.

Boundaries:

• Do not treat an engineering-only draft as sufficient — this issue does not close without actual legal review.

---

Part of #4778.

[linear-code]

JSO-3477

[JSONbored]

Research: what's actually needed to move this forward

This issue's own boundary is explicit: an engineering draft alone isn't sufficient, real legal counsel review is required to close it. I can't do that step. Two things need resolving before that step is even worth taking, plus one thing I can concretely offer.

Two open business questions that block briefing a lawyer usefully

1. Is there a registered legal entity for gittensory (LLC, corp, sole proprietorship)? Governing-law and liability-shield clauses depend entirely on this, and it's not something visible from the repo.
2. What jurisdiction should govern -- where the entity is registered, where the maintainer is based, or somewhere else?

What I can offer: a risk-scenario brief for counsel

Grounded in this session's actual architecture work (#4783, #4782, #4795, #4797), not a generic SaaS ToS template, so counsel doesn't have to reverse-engineer the product's real behavior from scratch:

1. Autonomy scope -- an agent with real write authority merges code directly into a customer's live repository (Multi-tenant hosted architecture spec #4783's tenancy model: installations.id = tenant, query-layer isolation). Granted via GitHub App install, not a traditional SaaS toggle -- the ToS needs to define what authority is actually granted.
2. Compute funding source -- compute is funded through decentralized infra (gittensor), not conventional billed compute-hours (gittensor rental economics spec #4781, still an open economics decision). Refund/liability language can't really be finalized until gittensor rental economics spec #4781 resolves, since what was actually purchased isn't decided yet.
3. Kill-switch / incident response -- a global + per-repo kill-switch exists (Kill-switch implementation #5670) and an incident runbook exists (Incident runbook for the kill-switch #4809, posted as a comment, not yet validated by a real drill). The ToS should probably reference a committed response-time expectation, but that number shouldn't be promised until a real drill has validated it.
4. Post-merge harm -- Post-merge incident: gittensory's obligations to the customer #5137 (already blocked on this issue) covers what obligations exist once a rented-loop PR has already merged and is later found harmful. A real liability question this ToS needs to define, not defer.
5. Content moderation -- Content-moderation policy for submitted ideas #5136 (also blocked on this issue) covers what counts as an abusive/illegal idea submission before it consumes paid compute. Needs to agree with the ToS on this boundary.
6. Prompt-injection surface -- Prompt-injection & content-sanitization defense #4795 (just shipped) defends the coding agent's own instructions against adversarial content in a customer's own issue text, but it's a best-effort regex defense, not a guarantee. Liability language shouldn't over-promise here.
7. Cross-tenant isolation -- Per-tenant execution sandboxing #4793/Scoped credential handling #4794 (shipped, tested) cover execution sandboxing and credential scoping; Cross-tenant data-isolation audit #4797 (shipped) found and fixed one real gap (unscoped bulk queries, now guardrailed) but v1 is query-layer isolation, not physical per-tenant database sharding. Worth being straightforward with counsel about what "isolated" actually means today vs. what a customer might assume.

Next action: find and engage real legal counsel. Everything above exists to make that conversation shorter and more accurate, not to replace it.