Free for 30 days on Scale.Start free
Legal

Security Policy

How Dock authenticates, authorizes, encrypts, audits, and responds to incidents. Written in plain English for procurement review. The engineer-facing technical reference lives at /docs/support/security.

Effective: May 10, 2026

1. Who we are

Dock is operated by Vector Apps, Inc. (“we”, “us”). Reach the security team at security@trydock.ai. The same address handles vulnerability disclosure, DPA requests, vendor questionnaires, and security-related buyer questions.

2. Scope

This policy covers the Dock service operated at trydock.ai and its subdomains, the Dock REST API, the MCP server at /api/mcp, the outbound webhook system, and the Dock CLI + desktop client. It does not cover third-party agents or applications that consumers connect to Dock; those are governed by their own policies and your authorization scope.

3. Compliance posture

Dock is in commercial beta. Our compliance status across common framework requests is, as of the effective date above:

  • SOC 2 Type II: not yet attested. Targeted for completion in the second half of 2026, aligned with the Enterprise plan launch. Customers requiring SOC 2 before purchase should email security@trydock.ai for our pre-attestation risk and controls summary.
  • GDPR (EU) and UK GDPR:we act as Processor on Customer’s behalf. Our standard Data Processing Addendum is accepted at signup via a consent checkbox; a counter-signed PDF copy is available on request for procurement records. Standard Contractual Clauses (Module Two, Controller-to-Processor) plus the UK Addendum are incorporated by reference in the DPA for transfers out of the EEA / UK / Switzerland.
  • CCPA / CPRA (California): Vector Apps acts as a Service Provider under the CCPA. We do not sell or share Personal Information for cross-context behavioral advertising.
  • HIPAA: Dock is not currently HIPAA-eligible and we do not sign Business Associate Agreements. Do not upload Protected Health Information into Dock workspaces.
  • PCI DSS: Dock does not process, store, or transmit cardholder data. Payment processing is handled entirely by Stripe under their own PCI DSS Level 1 attestation.
  • ISO 27001 / 27017 / 27018: not currently certified. Operating practices align with the ISO 27001 Annex A controls where applicable; formal certification is not on the near-term roadmap.
  • Penetration testing: we have not commissioned a third-party penetration test as of the effective date. Internal security audits are conducted on a recurring cadence; outcomes are published in section 24 below.

4. Authentication

Three authentication mechanisms, each with explicit protections.

4.1 Magic-link sign-in (humans)

Humans authenticate via single-use email links delivered by Resend. Links are valid for fifteen (15) minutes from issuance, invalidated upon redemption, and cryptographically bound to the email address they were issued for. A leaked link cannot be redeemed by anyone other than the recipient even within the validity window. Successful redemption establishes a thirty (30) day session cookie scoped to trydock.ai with HttpOnly, Secure, and SameSite=Lax attributes.

Multi-factor authentication is structurally provided by the email channel: possession of the email account is required to complete sign-in, so any MFA configured on the upstream email provider (TOTP, WebAuthn, SMS) flows through transparently. Dock does not currently offer native TOTP or WebAuthn second factor. Native WebAuthn is on the roadmap; customers requiring native second factor before purchase should email security@trydock.ai.

4.2 API keys (agents)

Agents authenticate via Bearer tokens with the prefix dk_. Each token is a forty-eight character random string drawn from a cryptographically secure pseudorandom number generator. Plaintext is shown to the creating client exactly once at creation and is not retrievable thereafter. The database stores SHA-256 hashes of each key in a unique-indexed column; verification on every request hashes the incoming Bearer token and looks up the row by hash.

4.3 OAuth 2.1 with Dynamic Client Registration (MCP connectors)

MCP connectors authenticate via the OAuth 2.1 authorization code flow with mandatory PKCE (S256 method only) per RFC 9700. Plain PKCE and unprotected flows are rejected. Access tokens have a seven (7) day lifetime; refresh tokens have a thirty (30) day sliding lifetime, where each refresh resets the clock. Active sessions thus do not require re- authentication; idle sessions expire after thirty days. Both token types are stored as SHA-256 hashes at rest with the same architecture used for API keys.

5. Authorization

Every operation against a workspace is gated through a single canonical access check. Access is determined, in order: an explicit workspace-member record; signed-agent inheritance from the agent’s owning user; org-membership combined with the workspace’s visibility tier; or, where the workspace visibility permits, virtual viewer access for unauthenticated reads. Cross-organization access flows exclusively through explicit workspace-member records; org-visibility tiers do not cross organization boundaries.

Roles are: owner, editor, commenter, viewer. Owners can delete; editors can read and write content and invite members; commenters can read and comment but not modify content; viewers are read-only. Role checks are performed against the database on every request and are not cached across requests.

6. Employee access and internal controls

Vector Apps employees do not access Customer Personal Data in the ordinary course of operating the Service. Engineering and operations personnel may access Customer data only when required to:

  • Resolve a support request initiated by an authorized Customer representative.
  • Investigate an active security incident or suspected abuse.
  • Diagnose a production fault that cannot be reproduced without Customer data and where Customer has consented to investigation.
  • Comply with a valid legal request as required by applicable law.

All employee access to production systems requires single-sign-on through Google Workspace with mandatory hardware-key or WebAuthn second factor; password-only access is not permitted. Production database access is gated through Neon’s console, which logs every connection with the operator identity and timestamp. Vercel project access is gated by GitHub identity with hardware-key second factor. Sub-processor consoles (Resend, Sentry, Stripe, Upstash) are accessed through the same identity provider with the same second-factor requirement.

Access reviews are performed when an employee’s role changes and on departure: production access is revoked the same business day. The current head count is small enough that a continuous access review is implicit in day-to-day operations; a documented quarterly review is targeted for the second half of 2026 alongside SOC 2 preparation.

Employees complete a written confidentiality agreement on engagement that survives termination. Background checks appropriate to the role and jurisdiction are conducted on hires.

7. Session integrity

Two server-side defenses protect against session-state residue.

Shared-device takeover:when a sign-in request is received on a browser carrying a different user’s session cookie, the prior session record is deleted server-side before the new cookie is issued. Any process still holding the prior cookie value receives a 401 on its next request.

Privilege change:when a user is removed from an organization or has their organization-level role changed by an administrator, every active session for that user is invalidated. The user’s next request requires a fresh sign-in, ensuring the new authorization state takes effect across all connected clients including long-lived streaming connections.

8. Encryption

In transit: TLS 1.3 on every public endpoint. Strict-Transport-Security with a one-year max-age, includeSubDomains, and preload. The trydock.ai domain is on the Chromium HSTS preload list.

At rest: AES-256 on the primary Postgres database (Neon, US East) and on object storage (Vercel Blob, multi-region). Per-row encryption for sensitive workspaces is on the roadmap and tied to the Team plan launch.

Credentials at rest: every Bearer credential Dock issues (API keys, OAuth access tokens, OAuth refresh tokens, magic-link tokens, invite tokens) is stored as a SHA-256 hash, never plaintext. The plaintext is shown to the issuing client exactly once. A database leak exposes hashes, not impersonable secrets. Webhook secrets are an exception: they are stored in a form recoverable by the application because outbound HMAC signing requires the plaintext. Encryption-at-rest for webhook secrets (in-process AES-GCM) is on the roadmap.

9. Network egress controls

Every URL Dock dispatches to from user-controlled input (webhooks, embed lookups, content fetchers, OG previews) is validated in two layers before any outbound request is sent.

At save time, a syntactic check rejects URLs whose host is a raw IP in a private or reserved range (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, IPv4 loopback, IPv6 link-local, IPv6 unique-local), the IPv6 loopback, the string “localhost”, or any host ending in a reserved TLD (.local, .internal, .lan, .home.arpa, .arpa, .intranet).

At dispatch time, the host is re-resolved via DNS and the resulting IP is checked against the same blocklist. This defeats DNS-rebinding attacks, where an attacker registers a public-looking hostname that resolves to a private address. Cloud-metadata addresses (169.254.169.254 and aliases) are blocked by both layers. In production, only https:// destinations are permitted.

10. Content sanitization

User-supplied HTML, SVG, and remixed markdown pass through DOMPurify with explicit allowed-tag and allowed-attribute lists before rendering. URL schemes within sanitized content are restricted to http(s), mailto, and tel; javascript:, data:text/html, vbscript:, and event-handler attributes are stripped. Comment bodies are rendered as plain text with no markdown or HTML interpretation. Embedded content from third-party services expands only for hosts on a static safelist (YouTube, Vimeo, Loom, Figma, CodePen, GitHub Gist).

The doc-shape guard caps maximum byte size, depth, and node count on every write to a TipTap document body. Real prose does not approach the caps; runaway agent loops do.

11. Rate limiting

Sliding-window rate limits are applied per IP address and per authenticated principal. Limits include: magic-link sends, 5 per email per hour and 20 per IP per hour; API writes, 300 per principal per minute; API reads, 600 per principal per minute; organization invite operations, 20 per organization per hour. Exceeding a limit returns HTTP 429 with a Retry-After header.

The rate-limit backend is Upstash Redis in production, keyed atomically across all Vercel instances. Spreading requests across instances or waiting for cold starts does not bypass the limits. If the Redis backend becomes unavailable at deploy time, requests fail closed with a 5xx error rather than silently degrading to per-instance in-memory state.

12. Webhook integrity

Outbound webhook deliveries are signed with HMAC-SHA256 over the concatenation of the request timestamp and body using the organization’s webhook secret. The signature appears in the x-dock-signature request header in the form t=<unix-ts>, v1=<hex>. Receivers should reject deliveries where the timestamp is more than five minutes off the receiver’s clock to defeat replay. When a webhook secret is rotated, deliveries carry a second signature v2=<hex> signed with the previous secret for a twenty-four hour grace window, allowing receivers to update their stored secret without dropping in-flight deliveries. After the grace window, only v1 is sent.

Failed deliveries retry with exponential backoff: one second, five seconds, thirty seconds, five minutes, thirty minutes, two hours, six hours, twenty-four hours. After eight failed attempts, the delivery is recorded as failed and not retried automatically. Manual redelivery is available through the dashboard or the API.

13. Audit logging

Every state-changing operation in a workspace is recorded in an append-only event log scoped to that workspace. Each record names the actor (human or agent) explicitly and includes the action, payload diff, IP address prefix, request ID, and timestamp. The event log is readable by workspace members through the Activity tab and by agents through the MCP get_recent_events tool. Webhook subscriptions emit the same events to external receivers.

Authentication events (successful sign-ins, failed sign-ins, session terminations, OAuth grants, OAuth revocations) are logged to centralized infrastructure logging (Vercel) and error monitoring (Sentry) with credentials scrubbed.

14. Logging hygiene

Two layers prevent credentials from appearing in operational logs. A field-name blocklist scrubs by name before any log record reaches Vercel or Sentry; covered names include password, token, secret, api_key, session_token, accessToken, refreshToken, keyHash, authorization, and cookie. A credential-shape regular expression catches Bearer tokens, webhook secrets, JWT-shaped strings, and other recognized formats in stringified output even when the field name does not trigger the blocklist. Request bodies are never logged in full; request IDs are used to correlate operations without exposing actor identity.

15. Dangerous-operation gates

Operations that move money or permanently widen access do not execute on the first call. Instead, the handler returns a confirmation token and an operation summary. The agent surfaces the summary to the human user. The user confirms. The agent re-calls the operation with the token. The token is single-use, expires after sixty seconds, and is bound to the requesting principal, organization, operation name, and operation parameters; it cannot be replayed for a different operation. Today’s gated operations are plan upgrades and downgrades. New operations of similar character route through the same gate.

16. Privacy by default

Dock does not connect any large language model or AI service to its software. The only AI that reads workspace data is the agent the customer has authorized through their own API key or OAuth grant. We do not train any model on customer data, do not share customer data with third parties for marketing or advertising purposes, and do not sell customer data. Subprocessors are limited to infrastructure providers; the current list is published at /subprocessors.

Customer data export and deletion procedures (right-to-delete, right-to-portability, backup retention) are detailed in section 17.

17. Data export and deletion

Customers can export Customer data at any time during the term of the agreement. Workspace export: the REST API at GET /api/workspaces/:slug/export returns a ZIP containing every row, document body, comment, and attachment in a structured, commonly used, machine-readable format (JSON for structured data; original binary for attachments). Account export: a full export of all workspaces a user owns is available on request via security@trydock.ai and delivered within seven (7) days.

Deletion.Right-to-delete requests are honored within thirty (30) days of confirmed receipt. Cascade deletion removes the user’s organization memberships, workspace memberships, agents, API keys, OAuth tokens, and sessions, plus orphaned workspaces where the user was the sole owner. Audit log entries that name the deleted user are retained as required by the immutable- ledger contract in section 13, with personal identifiers replaced by an anonymized handle so the audit history remains coherent for surviving Customers.

Backups are subject to the standard backup retention described in section 19. Personal Data in backups is overwritten in the normal backup cycle; a Customer requiring immediate purge from backups (rather than expiration) should email security@trydock.ai.

18. Data residency

Primary data is stored in the US-East-1 Neon region. EU data residency is on the roadmap and tied to the Team plan launch. Until then, customers in the EU should treat Dock as a US data processor. Our standard Data Processing Addendum is counter-signable as-is and incorporates the EU Standard Contractual Clauses (Module Two, Controller-to-Processor) plus the UK Addendum where applicable.

19. Backup and recovery

Postgres on Neon with continuous point-in-time recovery (seven days on Free and Pro tiers, fourteen days on Scale). Restore procedures are verified quarterly against a scratch branch. Object storage on Vercel Blob is multi-region with a fourteen-day undelete window.

Our operating targets are a five (5) minute recovery point objective (driven by Neon’s PITR granularity) and a four (4) hour recovery time objective (restore branch, flip DNS, warm caches). These targets are not contractual SLAs; an explicit SLA is available on the Scale and Enterprise plans on request.

20. Shared responsibility model

Security is a joint obligation. Vector Apps is responsible for the security of the Service infrastructure and software as described in this policy. Customer is responsible for the security of how Customer uses the Service.

Vector Apps is responsible for hosting, patching, and operating the Service; authenticating and authorizing every API call against the canonical access check; storing every credential at rest as a SHA-256 hash; encrypting data in transit and at rest; validating outbound network requests against the network-egress controls in section 9; sanitizing user-supplied content per section 10; enforcing rate limits per section 11; logging state changes per section 13; preserving credential confidentiality per section 14; gating dangerous operations per section 15; responding to incidents per section 22.

Customer is responsible forchoosing strong sign-in protections on the email accounts of all Data Subjects with Dock access; rotating API keys and OAuth clients when staff change roles or leave; reviewing the list of authorized agents under Settings → API keys at a regular cadence and revoking unused ones; choosing appropriate workspace visibility for each workspace (private, org, unlisted, public); honoring the categories of data the Service is appropriate to host (no PHI under the HIPAA exclusion in section 3; no cardholder data; no regulated data classes Dock is not currently approved for); configuring webhook endpoints that verify the HMAC signature in section 12; and complying with the laws and contractual obligations governing Customer’s use of the data Customer chooses to store in the Service.

21. Vulnerability disclosure

Security researchers and customers are encouraged to report vulnerabilities to security@trydock.ai. We acknowledge reports within one business day and aim to deliver a fix or scoped mitigation within seven days for high-severity findings. Public credit on the changelog is offered with researcher consent. Please do not run automated vulnerability scanners against production; they consume rate-limit budget without producing actionable signal. A manual reproduction with a clear write-up is materially more useful.

22. Incident response

Our incident response procedure is: contain, investigate, notify and remediate. Containment may involve rotating affected credentials, revoking compromised sessions, and disabling specific endpoints. Investigation is reconstructed from Vercel logs, Postgres audit data, and version-control history. Customer notification follows GDPR Article 33/34 timing where applicable: affected users are notified within seventy-two hours of confirmation. A post-mortem is published after remediation completes.

On-call rotation during the beta period is the founder. Paging routes through Vercel alerts and security@trydock.ai.

23. Supply chain

Releases of @trydock/cli and @trydock/mcp are published with npm provenance. Every published version is cryptographically signed via Sigstore and tied to the commit and build log that produced it. Local npm publishis not possible; if a Dock-branded package on npmjs.com lacks the green “Published with provenance” badge, it did not originate from us.

24. Recent security work

We run focused security audits on a recurring cadence and publish the resulting fixes the same week. Below are the completed audits to date.

May 9, 2026. Comprehensive sweep covering authentication, encryption, network egress, and content sanitization. Outcomes shipped: SSRF protection extended with DNS-resolution check at dispatch; PKCE S256 made mandatory at the OAuth authorization endpoint; OAuth access and refresh tokens hashed at rest with a soak-gated plaintext-column drop scheduled for June 9, 2026; rate limiter hardened to fail closed when its backend is unavailable in production; magic-link verification bound to the recipient email address; OAuth refresh-token lifetime bounded at thirty days with a sliding window; webhook secret rotation given a twenty-four hour dual-signature grace window; HTML sanitizer in the remix flow replaced with a DOMPurify pipeline matching the existing SVG sanitizer; an upstream dependency vulnerability in fast-uri patched via an npm overrides directive; shared-device session takeover defense added to magic-link verification; and session rotation added to organization role changes and removals.

May 6, 2026.Earlier sweep across authentication and authorization surfaces. Outcomes shipped prior to this policy’s effective date.

25. Changes to this policy

Material changes to this policy will be reflected in an updated effective date at the top of this page. Customers on a paid plan with an executed Data Processing Addendum will be notified of material changes via email at least thirty days before they take effect, unless the change is required by law or addresses a security risk that requires faster action.