LetsPing is built for teams who need to secure their agents and stay in control. Below we describe how we protect the platform you use every day (dashboard, approvals, keys, data). Then we cover the safeguards for self-serve agent infrastructure: signup, agent APIs, and escrow. For implementation details, env vars, and rate-limit reference, see Trust anchor (security architecture).
Platform & dashboard
The core product: dashboard, triage, approvals, and API keys. We secure it so your team can trust what goes in and out of your agents.
Your keys and identity
- API keys are hashed with SHA-256 before we store them. We never persist plaintext keys, so a database leak does not expose your credentials.
- Webhook and attestation signing use HMAC-SHA256 with a dedicated secret. Outbound webhooks send X-LetsPing-Signature with a timestamp and signature, and we enforce a 5-minute replay window so old payloads cannot be replayed.
Tenant isolation
- Every request is scoped by project and organization. Your data never mixes with another team's. Proof, attestation, and trust-score APIs only return resources that belong to your project.
Billing and abuse prevention
- Credits are only added after a successful charge to your Stripe payment method. We do not grant usage without payment. Trust score volume is capped and adjusted when there are few third-party outcomes, and we surface that so downstreams can interpret scores fairly.
Audit and compliance
- Sensitive actions (fund, rotate, register) are written to audit logs when audit actor is set; otherwise we log structured JSON. You can export audit logs (CSV) by project and date range for SOC2 and compliance. Retention follows your plan (14 days on Free, 60 days on Pro).
Operational safety
- We reject request bodies over 4MB to protect the pipeline. Webhook dispatch uses a 5-second timeout and circuit breaker so one slow downstream does not cascade. Ingest and handoff-outcome support idempotency keys (24h in Redis) so you can retry safely.
Self-serve agent infrastructure
When agents sign up autonomously or call agent-only APIs (attestation, escrow, handoff registry, billing/fund), we apply extra safeguards. This section is for builders who care about how we protect those flows.
Agent identity and escrow
- Agent identity uses HMAC-SHA256 over project, service, action, and payload with the agent secret. We use constant-time comparison for signature verification to prevent timing attacks.
- Escrow handoff signatures cover id, event, data, upstream and downstream agent, commitment, and state ref. Downstream agents can verify the chain without trusting the transport.
Rate limiting and fail-closed where it matters
- Ingest and agent APIs use tier-based token buckets per API key (e.g. 120/min for ingest, 20/min for register). If Redis is unavailable for these limits, we fail open so availability is not tied to rate-limit infra.
- Self-serve agent signup (request-token) has no auth, so we assume bad actors. We enforce 5 requests per hour and 10 per 24h per IP, a global daily cap (500), and a kill switch (DISABLE_AGENT_SELF_SERVE_SIGNUP). If Redis is unavailable for this path, we do not issue tokens. We fail closed so we never hand out signup tokens when we cannot enforce limits.
Docs · Integrations · Home