Specific safeguards, stated without certification theater.

This page is an implementation overview, not an independent penetration test, audit opinion, certification, compliance attestation, or guarantee that a deployment is free of vulnerabilities. PeopleDat does not claim SOC 2 or ISO 27001 certification here and does not claim customer-selectable data residency or geographic redundancy.

• Passwordless sign-in uses time-limited email links; sessions are database-backed and can be invalidated.
• Protected dashboard operations resolve a server-derived organization/workspace context and reload membership from the database.
• The active workspace in the browser is a preference, not an authorization claim.
• Cross-workspace identifiers return not found to reduce tenant enumeration.
• Owner, Admin, Contributor, and Viewer permissions separate billing, team, data, developer, and spend capabilities.
• Owners/admins have organization-wide workspace access; restricted members receive explicit workspace grants.
• Creator references use nullable attribution so removing a user does not cascade-delete shared data.

Browser/session mutations require an exact trusted Origin. In production, the comparison uses the configured public application origin rather than a reverse-proxy internal URL, and a missing public-origin configuration fails closed.

• Email values and preserved CSV source rows/headers use application-layer AES-256-GCM with a random IV and authenticated ciphertext.
• Invited addresses, exact-email exclusions, verification cache values, and webhook signing secrets are encrypted before database storage.
• Lookup and bearer secrets are stored as hashes where plaintext recovery is unnecessary, including API keys, invitations, and public-report tokens.
• Generated exports are written to S3-compatible object storage with AES-256 server-side encryption and normalized tenant-scoped keys.
• Downloads use short-lived signed URLs after workspace authorization; generated exports expire after 30 days.
• Preserved CSV source-data retention is explicit: 7, 30, 90 days, or until list deletion, with 30 days as the default.

AES-GCM encryption keys, IP-hash salt, session secrets, provider tokens, and storage credentials are deployment secrets. Production rejects missing/placeholder application encryption material when those controls are used.

• Bounded request-body readers reject oversized payloads before unbounded parsing.
• CSV imports enforce 10 MB, 50,000 data rows, 200 columns, 32 KB per cell, and valid UTF-8. TXT and pasted input use the email-only parser and accept up to 50,000 valid addresses.
• CSV/XLSX output neutralizes formula-leading cells; storage filenames and keys reject traversal patterns.
• The public one-address preview validates/normalizes input, verifies Cloudflare Turnstile server-side, and rate-limits salted IP identifiers.
• Authenticated REST and MCP requests reserve transactional database rate-limit buckets and fail closed if that reservation cannot complete.
• If widget rate limiting is unavailable, PeopleDat performs no provider or credit work and returns an allowed unavailable response so the visitor’s form can fail open.
• Security headers include HSTS, deny framing, nosniff, restrictive permissions, a Content Security Policy, and route-specific no-store/noindex controls.

Workspace API secrets use pd_test_… or pd_live_… prefixes, are revealed once, and are stored only as SHA-256 hashes. Keys carry explicit scopes, expiry/revocation, last-use metadata, per-minute limits, an optional daily credit cap, and workspace attribution.

• Free workspaces receive deterministic test keys that never reach the provider or credit ledger.
• Live keys require an active subscription or any settled PayGo purchase; lapse suspends rather than deletes them.
• Chargeable REST requests require idempotency; changed replays return a conflict and concurrent requests settle once.
• MCP uses the same Bearer keys, scopes, rate limits, idempotency, canonical orchestrator, and credit ledger as REST.
• API keys cannot create other keys or alter webhook configuration.
• Privacy-safe API logs keep request/key/workspace IDs, route template, status, duration, counts, source, and billed units—never request bodies, raw addresses, raw IPs, or credentials.

• Only registered workspace endpoints receive events; arbitrary per-job callback URLs are not accepted.
• Destinations must use HTTPS on port 443 with no URL credentials or redirects.
• Every connection performs DNS validation and pins the validated public IP.
• Private, local, metadata, link-local, reserved, mapped-IPv4, and rebinding destinations are rejected.
• Requests have a five-second timeout and bounded response capture.
• The exact raw body is signed with HMAC-SHA256 over timestamp + period + body; recipients receive event ID, timestamp, and versioned signature headers.
• Payloads contain IDs and aggregates, never addresses or source columns.

Delivery retries and replay are at-least-once behavior. Receivers must verify the signature, reject stale timestamps, and deduplicate by event ID before side effects. See the webhook implementation guide.

Neither a browser site key nor a report URL is an identity credential. Customers must set conservative caps, use appropriate sharing channels, and revoke any exposed key/link.

• Structured logs redact common credentials, tokens, addresses, and sensitive fields before output.
• Operational health tracks queue/outbox/schedule age, dead letters, delivery failures, credit discrepancies, database connections, memory, and provider capacity.
• Immutable domain events are created transactionally with terminal state changes so notifications/webhooks survive a lost queue wake-up.
• Webhook/email delivery diagnostics remain 30 days; API logs and in-app notifications remain 90 days.
• Workspace/security/API audit events remain two years.
• FINANCIAL-class audit entries use a seven-year cleanup window.
• Primary subscription, purchase, Stripe-event, wallet, and credit-ledger rows are outside automated retention cleanup; their deletion timing is handled separately under the approved financial policy and applicable legal holds.

1. 1

   Grant least privilege

   Use viewers for review, contributors for operational work, and admins only for people who should manage every workspace and developer setting.
2. 2

   Separate client workspaces

   Do not rely on list names to isolate agency clients. Grant each client only its own workspace.
3. 3

   Name and scope credentials

   Create one key/webhook/widget per integration, select minimal scopes, lower limits, set expiry/caps, and keep secrets in a server-side secret manager.
4. 4

   Minimize source retention

   Choose the shortest source-column window that supports your workflow and delete original columns early when appropriate.
5. 5

   Review and revoke

   Periodically remove invitations, memberships, keys, endpoints, widgets, schedules, and report links no longer needed.
6. 6

   Keep consent and sending controls

   Verification does not establish consent, identity, lawful basis, or inbox placement. Maintain your own collection, suppression, and sending policies.

Email [email protected] with a concise description, affected route/resource ID, approximate time and timezone, and safe reproduction steps. Do not send active credentials, magic links, payment data, or full customer lists.

For account, billing, or ordinary product questions, use Support. Review Privacy, Subprocessors, Terms, and Acceptable Use for the public legal disclosures.