How we protect your data.

Customer-facing payloads — approval queue items, handoff log entries, the knowledge substrate documents you connect or upload, OAuth tokens for your connected systems — are encrypted at rest using AES-256-GCM with a per-environment key stored only in our hosting provider's secrets store (Vercel). Vector embeddings are stored plaintext because they're not directly reversible to source text, but each chunk carries a workspace_id that gates retrieval.

The encryption key is rotated per environment (Production, Preview, Development). Losing the production key would render stored OAuth tokens unreadable but would not expose data — we treat key rotation as a controlled migration, not an emergency restore.

All inbound and outbound network traffic uses TLS 1.2 or higher. The marketing site, the customer-facing app, the API, and every subprocessor connection (Anthropic, Neon, Stripe, Resend, Sentry, Inngest, Vercel) require TLS — non-TLS connections are rejected at the edge.

Every database row in our primary store carries a workspace_id column enforced by row-level security policies in Postgres. A query that omits the workspace filter returns zero rows regardless of how it's constructed — the database enforces tenant isolation, not the application layer.

The same isolation extends to vector embeddings in the knowledge substrate: every retrieval call is scoped by workspace_id at the query level, and chunks from one workspace cannot surface in another's answers even if a prompt would otherwise match.

We request the minimum OAuth scopes needed to deliver the value loop. For email connections (Gmail, Microsoft 365), we ask for read-and-draft scopes only — we never request send-on-your-behalf scopes. The fleet drafts into your inbox; you send from your own account.

For file stores (Google Drive, OneDrive), we request the narrowest read scope that lets the fleet ingest the folder you point us at. We never request write scopes for files we don't author. For accounting (QuickBooks Online), we request read-only scopes for reconciliation; we never initiate journal entries or transfers.

You can revoke any OAuth grant at any time from your connected system's app dashboard or from inside the agentplain workspace — revocation takes effect immediately and the fleet ceases reading that source on the next cron fire.

Every agent action — every draft, every flag, every handoff, every configuration change — writes an append-only row to the workspace's handoff log. The log is visible to the workspace owner inside the product and is retained for the life of the workspace. Append-only means no agent and no admin can rewrite history; corrections happen as new rows that reference the original.

Customer-facing outputs (every queued draft, every approved send, every rejected draft) carry full provenance — which skill drafted it, which connectors it pulled context from, which compliance gates it passed through. This is the "open feedback loop" we describe on the marketing site.

Production secrets — database connection strings, OAuth client secrets, the encryption key, the model API key, the Stripe key — live only in our hosting provider's encrypted environment store (Vercel). They are never committed to source control, never logged, and never returned in API responses or error traces.

Internal access to the production environment is limited to the workspace owner (Conner Chambers) and is gated behind multi-factor authentication on the Vercel account. There is no shared admin account; engineering changes are deployed through Git, not through dashboard edits.

We use the named subprocessors listed in our privacy policy. Each is selected and configured to match the security posture described here: TLS in transit, encryption at rest, no-training on customer data (Anthropic), PII scrubbing before transmission (Sentry).

If we detect or are notified of a security incident affecting customer data, we will: (1) contain the incident within 24 hours of confirmed detection; (2) notify affected workspace owners by email within 72 hours of confirming the scope; (3) publish a post-mortem with root cause, timeline, and remediation steps. Notification windows compress for incidents we judge to warrant immediate disclosure regardless of investigation status.

Report a suspected vulnerability or incident to hello@agentplain.com. We respond within one business day to vulnerability reports and do not pursue legal action against good-faith security research.

The primary Postgres database is backed up daily with point-in-time recovery enabled. Backups are encrypted at rest and rolled off after 30 days. We do not restore from backups except to recover from a service-affecting incident, and we never read backup contents in the course of normal operations.

See also our privacy policy and terms of service.