Abuse Reporting

Abuse Reporting

Draft pending counsel review — not legal advice, not in force until approved by the owner

Reviewed by: (pending) · Reviewed on: (pending).

1. Where to report

Report abuse to security@tcp.systems. The mailbox is delivered by the maddy role alias security@tcp.systems → postmaster@tcp.systems, a real mailbox, added on 2026-10-20 (source: ops/docs/trust/security-txt.md, “The mailbox”). Security vulnerabilities use the same address; the machine-readable pointer lives at /.well-known/security.txt on the public hosts.

2. What to include

A report is most useful with: the API key id or account involved (never the key value), timestamps, the target of the abuse, and enough evidence to act on. Do not include credentials in a report; if a report contains any, treat them as exposed and rotate them rather than assuming the copy is gone (source: ops/docs/trust/retention-schedule.md, “Deletion method”).

3. What happens next

Security-response targets for a small team, stated on the security policy and not backed by an on-call rota or a contractual SLA: acknowledgement within 2 business days, triage within 5 business days (source: ops/docs/trust/security-txt.md, “Known gaps”). Reports and disclosure correspondence are retained for three years as evidence of handling (source: ops/docs/trust/retention-schedule.md, row 10).

4. Scope

The acceptable-use rules a report is judged against are in the acceptable use policy. Abuse intake for the product control plane is being built in Studio (source: GTM-SUITE-PLAN-2026-11-04.md, P0-10); until that ships, this mailbox is the channel. Nothing on this page claims a monitoring or response capability the operator does not have.