How Anchor secures the client portal, what data it shows you, where that data is stored, and the privacy controls that apply — written for the client security and IT reviewers who approve the portal for use.
Version 1.0 · Last updated June 12, 2026 · Reflects the live portal implementation
Passwordless sign-in
Access is by a private, single-use link emailed to each contact — no portal password to reuse or steal.
One project per portal
Every portal is filtered, on the server, to a single engagement. It can never return another client's data.
Encrypted in transit
All traffic is HTTPS/TLS with HTTP Strict Transport Security and standard browser-hardening headers.
Least privilege by design
You see only what your delivery team publishes. Internal notes, pricing, and raw transcripts are withheld.
The Anchor client portal is a secure, read-mostly window your delivery team opens onto your own project. You reach it at a private link (for example, anchor-hq.dev/c/your-project). It shows your project's status, meetings, documents, and contacts, and gives you a place to raise support tickets — and it shows nothing from anyone else's project.
This document covers the client portal specifically. For the platform-wide privacy policy and terms of service, see anchor-hq.dev/privacy and anchor-hq.dev/terms.
Portal sessions are intentionally short-lived (24 hours) and self-expire. Revoking a contact's invite stops all future sign-ins immediately. For an instant cut-off of an open session, your delivery team can disable the portal.
Each portal is bound one-to-one to a single project ("implementation") inside your account. Every panel is filtered on the server to that one project, so a portal can only ever return that project's data.
Your delivery team turns each of these on or off per portal — you only see the panels they publish.
Your delivery team can preview the portal exactly as you would see it. This view-as-client mode is only available to authenticated Anchor users who belong to the organization that owns the portal — it cannot be triggered by an anonymous visitor or by anyone outside your engagement.
Anchor applies its own application-layer AES-256-GCM encryption specifically to third-party integration secrets. This is separate from the portal's own sign-in. Other stored data relies on the encryption-at-rest provided by our database and storage providers rather than additional application-layer field encryption.
Audit logging is best-effort: a logging failure is recorded internally but never blocks your access. Rate-limit enforcement depends on the availability of our caching backend.
| Data category | Examples | Purpose |
|---|---|---|
| Contact identity | Name and email address of invited contacts | Grant and manage portal access |
| Session metadata | Email, IP address, browser user-agent, sign-in timestamps | Authenticate the session; security audit |
| Support tickets | Submitter name, email, title; subject, message, attachments | Operate the support desk |
| Ticket replies | Author name and email; message | Maintain the ticket conversation |
| Survey responses | 0–10 score, optional free-text feedback, email and name | Measure satisfaction (when enabled) |
Text typed into the portal's help search is not stored as raw text — only a one-way hash is kept, so usage can be measured without retaining what was asked.
Your organization is the data controller for the personal data of the contacts you invite; Anchor acts as your data processor. A GDPR Article 28 Data Processing Agreement is available on request (email support@anchor-hq.dev with the subject "DPA Request").
| Sub-processor | Role | Portal data it handles |
|---|---|---|
| Vercel (US) | Application hosting, CDN, serverless compute, and file storage (Vercel Blob) | Serves all portal traffic; stores downloadable documents, ticket attachments, and logos |
| Supabase (AWS, US) | Managed PostgreSQL database | Stores all portal content and metadata |
| Upstash (US) | Redis — rate limiting | Sign-in and throttling counters (no portal content) |
| Resend | Transactional email | Delivers portal invite and survey emails, which contain the sign-in link |
| Anthropic (Claude) | AI sub-processor | Generates client-facing meeting recaps from meeting transcripts/summaries, when the Meeting Log is enabled |
| Pusher | Real-time messaging | Carries internal staff notifications when you submit a ticket (your browser does not subscribe to it) |
| Slack (optional) | Team messaging | Receives portal ticket content when your delivery team has connected Slack |
| Atlassian Jira (optional) | Issue tracking | Receives portal ticket content when a support project is connected |
| Sentry | Error monitoring | Application error diagnostics, with credentials and tokens scrubbed |
Optional integrations (Slack, Jira) receive portal-originated ticket content only when your delivery team has connected them. Per Anthropic's API terms, data sent to Claude via the API is not used to train models and is retained only briefly for abuse monitoring. Provider compliance attestations (such as SOC 2) are maintained by each provider and available on request.
Automated recaps are an AI summarization of material your team already shares with you, not the official record. If you spot an inaccuracy, contact your delivery team.
| Data | Retention |
|---|---|
| Expired portal sessions | Permanently deleted 7 days after expiry (automated weekly cleanup) |
| Audit logs | 365 days |
| Tickets, replies, survey responses, invite records | Retained for the life of the engagement; removed when the project/portal is deleted or on written request |
Questions about portal security, a Data Processing Agreement request, or to report a vulnerability: email support@anchor-hq.dev.
This overview reflects the live implementation of the Anchor client portal as of the effective date above. It describes what is implemented today and is updated as the portal evolves.
The questions security and IT teams most often ask before approving the portal.
There are no portal passwords. Each contact receives a personal, single-use sign-in link by email. The link carries a 256-bit random token that is stored only as a salted PBKDF2-HMAC-SHA256 hash (100,000 iterations); the raw token is never written to our database. Links expire after 30 days, rotate on each send, can be revoked, and grant a 24-hour HTTP-only browser session. Sign-in is rate-limited to 5 attempts per 15 minutes per IP.
No. Each portal is bound one-to-one to a single project, and every query is filtered server-side by that project and organization. Support tickets are further scoped to your own account, so even a portal shared by multiple customer organizations keeps each organization's tickets separate.
In transit: yes — all portal traffic is HTTPS/TLS with HTTP Strict Transport Security. At rest: portal data is stored in managed PostgreSQL (Supabase, AWS US) and managed file storage (Vercel), whose providers encrypt data at rest. In addition, third-party integration credentials are encrypted by Anchor with AES-256-GCM before storage.
Primary infrastructure is US-based: Vercel (hosting, CDN, file storage), Supabase (PostgreSQL database, AWS us-west-2), and Upstash (rate limiting). Resend sends portal emails, Anthropic generates meeting recaps, Pusher carries internal notifications, and Sentry handles error monitoring. Slack and Jira receive portal ticket content only when your delivery team connects them. A full table is in the Security & Privacy Overview.
Only to generate client-facing meeting recaps, using Anthropic's Claude model, and only when the Meeting Log is enabled. The relevant meeting transcript or summary is sent to Anthropic to produce a short recap; the raw transcript is never shown in the portal, and internal commentary is excluded from the recap. Per Anthropic's API terms, this data is not used to train models.
Yes. Every sign-in attempt — success or failure — is recorded to an audit log with the email, source IP, and outcome, and retained for 365 days. Successful sign-ins also store a session record with IP and browser user-agent.
Your delivery team can revoke a contact's sign-in link at any time, which blocks all future sign-ins. Sessions are short-lived (24 hours) and self-expire. For an immediate cut-off, the portal can be disabled outright.
Contact name and email (to grant access); session email, IP, browser user-agent, and timestamps (to authenticate and audit); and any ticket or survey content your team submits. Text typed into the help search is stored only as a one-way hash, never as raw text.
Expired sessions are permanently deleted 7 days after expiry; audit logs are kept for 365 days. Tickets, surveys, and invite records are retained for the life of the engagement and removed when the project/portal is deleted or on written request — handled within 30 days.
Yes — a GDPR Article 28 DPA is available on request (email support@anchor-hq.dev with the subject "DPA Request"). Your organization is the data controller for the contacts you invite; Anchor acts as your data processor.
Your delivery team can preview the portal as you would see it, but only when they are an authenticated member of the organization that owns your portal. An anonymous party, or anyone outside your engagement, cannot trigger this preview.
Yes. The portal has its own sign-in path and its own session cookie, fully separate from the internal staff app. The internal app's Google sign-in is never exposed to portal visitors, and the portal opens no real-time socket in your browser.
Questions about portal security, a Data Processing Agreement request, or to report a vulnerability, email support@anchor-hq.dev.
See also our Privacy Policy and Terms of Service. This page reflects the live implementation of the Anchor client portal as of June 12, 2026.