This is the long technical version of our Security & Privacy page - written for security teams running a vendor review.
How a Pocodot request is processed
Every request from your channel (Slack, WhatsApp, email, web) hits a TLS-terminating proxy, then our API. The first thing our API does is identify which workspace the request belongs to, using a session token bound to that workspace. From that moment on, every database query, every tool call, every external API call carries the workspace identity. Code that does not pass the workspace identity through is rejected at our middleware boundary.
Per-workspace data isolation
Every table that holds tenant data carries a workspace_id. Every API endpoint validates the workspace match against the session token. Caller-supplied workspace IDs are explicitly refused - the only workspace a session can resolve to is the one bound to its token. We have an automated test suite that tries to break this rule by issuing cross-workspace requests; those tests must pass before any code change ships.
We are adding PostgreSQL Row-Level Security as a second, database-level enforcement layer. RLS uses a per-session GUC that we set at the start of every transaction; our connection pool resets the GUC on every checkout so a session cannot inherit another workspace's identity.
Cryptography model
Today, we encrypt integration credentials (Slack tokens, OAuth refresh tokens, etc.) at the column level using AES-256-GCM. The encryption key is held in environment configuration on the production host with restricted access.
We are migrating to envelope encryption with per-workspace Data Encryption Keys (DEKs). Each workspace gets a 256-bit DEK, generated at workspace creation, used directly with AES-256-GCM on tenant data columns. The DEK is persisted in our database only in its KMS-wrapped form (wrapped by a single shared Key Encryption Key held in AWS KMS, rotated annually). On workspace deletion, the wrapped-DEK row is hard-deleted and the in-memory copy is zeroised - that is what we mean by "cryptographic deletion".
Live data becomes unrecoverable on deletion. Backup copies remain decryptable (using the DEK that existed at backup time) until they roll out of the 30-day retention window. We are also implementing a backup-restore deletion-tombstone log so tombstoned DEK rows are scrubbed before any restored backup is mounted writable.
Authentication and session model
Sessions are bound to a workspace claim and a 24-hour TTL. We're moving session storage from local browser storage to HttpOnly + SameSite=Strict cookies as part of the same release that ships per-workspace DEKs. Two- factor authentication (TOTP and WebAuthn) is rolling out in the same window.
Logging and observability
Application logs are sanitised at write-time to redact known PII fields. We retain operational logs for 30 days and audit logs for 1 year. Audit logs are exposed in-product for workspace admins.
Sub-processors and AI provider terms
Our AI providers (Anthropic, OpenAI, Google Gemini) are contracted under enterprise no-train terms - your message content is never used to train AI models. Our integration partner (Composio) may use anonymized operational metadata for product improvement, but never message content. The current sub-processor list is available at /security/subprocessors.json.
Incident response
We follow a documented incident-response runbook. Affected workspace admins are notified within 72 hours of confirmation, in line with GDPR Article 33. Public post-mortems are published on our blog within 30 days unless legal counsel advises otherwise.
Deletion certificates
Workspace deletion produces an Ed25519-signed certificate emailed to the admin. The signing public key is published at /security/deletion-key and you can verify the certificate yourself at /security/verify-deletion - the verifier runs entirely in your browser; the certificate never leaves your device.
Compliance posture
SOC 2 Type II is in audit. The audit window opens this summer; the report is targeted within the next few quarters and will be published in our trust portal as soon as it lands. We are GDPR-aligned today and can sign a Data Processing Agreement at the start of any contract. HIPAA Business Associate Agreements are available with our Enterprise plan.
For the source-of-truth research document (engineering-internal), see pocodot-api/docs/POCODOT_DATA_SECURITY_RESEARCH.md in our backend repository. Sales / security teams: email security@pocodot.ai for our trust portal access link.