Privacy Protocol
LAST UPDATED: 2026-01-29
01. Data Minimization
LetsPing is an infrastructure layer, not a data broker. Our architecture is designed to hold state only as long as necessary to resolve a Human-in-the-Loop (HITL) request. We strictly differentiate between Runtime State (Active) and Audit Logs (Archived).
02. Ingested Data Types
- Agent Payloads (JSON):The arbitrary data blobs sent via `letsping.ask`. We treat these as Transient Data. We do not index the contents of your payloads for global search.
- Telemetry Metadata:Timestamps, Trace IDs, and Actor IDs (e.g., `finance-bot-01`).
- Account Identity:Email addresses and provider tokens (GitHub/Google) used for authentication via Supabase Auth.
No Generative AI Training
LetsPing is a pure state machine. We do not operate generative models.
Your data is never used to train, fine-tune, or improve any proprietary or third-party AI models. Inputs strictly equal outputs.
03. Infrastructure & Subprocessors
We utilize a strictly typed set of US-based vendors to maintain our protocol.
| Vendor | Purpose | Persistence |
|---|---|---|
| Upstash (Redis) | Hot Signal / Queue | Ephemeral (TTL) |
| Supabase (Postgres) | Cold Storage / Audit Logs | Durable |
| Vercel | Edge Runtime | Transient |
| Stripe | Billing | Durable |
04. Encryption Standards
- At Rest: All data in Cold Storage is encrypted via Supabase's transparent disk encryption (AES-256).
- In Transit: All data ingressed via API or egressed via Webhooks is secured via TLS 1.3 (HTTPS).
- Key Management: API Keys are cryptographically hashed before storage. We cannot view or recover your raw API keys.
For security disclosures or data deletion requests, contact the engineering team directly:
security@letsping.co