Security
ActiveQ is a new product. This page describes how we protect information today and how to report a security problem. It describes current practice, not guarantees, and it will grow as the product does. We hold no security certification (such as SOC 2 or ISO 27001) today.
What we do today
- Encryption in transit. The website, application and portals are served over HTTPS through our hosting and network provider.
- Encrypted storage. Our providers encrypt stored data at rest: the database (Supabase), and the waitlist and file storage (Cloudflare). The database is hosted in the United States (US East, N. Virginia).
- Workspace isolation. Every table that holds workspace data has database row-level security, and what you can see and do is checked in the database against your role and permissions, not only in the application. Automated tests check that row-level security is on for every table and that one workspace cannot read another’s data.
- Roles and an audit log. Workspaces define their own roles and permissions. Changes to settings and tickets are recorded in an audit log that permitted members can read.
- Sign-in. Workspace passwords must be at least 12 characters and are stored hashed. Sign-up verifies your email with a one-time code that expires after 15 minutes, and a bot check protects sign-up and suspicious sign-ins. Sessions use secure, HttpOnly cookies; the access cookie is short-lived. Two-factor authentication is required for ActiveQ operator access; it is not yet available to customer accounts.
- Session control. Each seat is one named person; logins are not shared. A seat has at most one live desktop session and one live phone session, so a new sign-in on the same kind of device signs out the older one, tells the person signing in, and emails the account (without an IP address). Staff sessions end after 4 hours of inactivity by default and after 14 days at most; workspace owners can change both within limits. Customer portal sessions end after 8 hours of inactivity by default, which is configurable. A password change or reset signs out the other sessions, and disabling a member or changing their role signs them out of that workspace. Owners and admins can see a member’s sessions (device, approximate location, times) and sign them out. We may limit concurrent sign-ins and end sessions to protect accounts. Session records are kept for 90 days after a session ends; the IP address is visible only in the audit log. The device cookie __Host-aq_dev is strictly necessary for this and is used for nothing else.
- Link tokens. One-time sign-in, invitation and request links carry a random 256-bit token, and we store only a hash of it. A request link in an email works for 72 hours, shows the public conversation of that one request read-only, cannot be used to sign in, and anyone who holds it can open it, so avoid forwarding such emails. Link pages are not cached and are sent with a no-referrer policy, and tokens in links are redacted from our logs.
- Rate limits and size caps. Sign-up, sign-in, portal, link and other public endpoints are rate limited, and every request that changes data has a size limit (uploads are limited in size and to an allow-list of file types).
- Operator access. When ActiveQ support views a workspace, access is read-only, limited to 15, 30 or 60 minutes, requires a written reason and two-factor sign-in, and is recorded in that workspace’s audit log.
- Monitoring and alerts. We monitor mail delivery, background jobs and error rates, and send automated alerts to the operator when something fails. Alerts contain counts and system names, not customer content. Detailed per-request logging of full URLs is turned off on our application servers.
- Test environments. Test and staging environments use synthetic data only; we do not copy production data into them.
- Backups. Daily database backups are enabled (our database provider takes a physical backup once a day and currently keeps the seven most recent). Point-in-time recovery is not enabled, so a restore returns the database to the time of a daily backup, not to an arbitrary moment. We do not promise a particular recovery time or recovery point. Uploaded files and stored original emails (in Cloudflare R2) are not backed up separately.
- Minimal website data. The waitlist collects only an email address and a timestamp. The site also runs first-party, pseudonymous site analytics (page, referring site, campaign tags, country, region such as US state and city, the page a link on our own site leads to, device and browser type, how far down a page you scrolled, which links and buttons were clicked by label, and a daily-rotating one-way visitor hash; the daily visitor code is not stored in sign-up records and analytics is not matched to them, no raw IP address or full browser string is stored, no cookies or browser storage are used, automated traffic is stored but left out of the reports, and Do Not Track and Global Privacy Control signals are honored). It uses no advertising trackers.
- Knowledge base. Articles belong to one workspace and are protected by the same database row-level rules as tickets. Staff need a permission to read, write, review or publish articles, and a portal user sees only published articles whose audience includes them (all clients, or their own organization), and only after signing in; there is no public access. Changes to articles and to review settings are recorded in the audit log without the article text.
- AI features. AI actions run only when a staff member clicks, and the text sent is limited to the one ticket the member can read (for polish, only the text the member wrote and the workspace name; for a help-article draft, public messages only with names hidden), with common personal identifiers redacted on a best-effort basis (see section 11 of the Privacy Policy for what is and is not covered). Except for Research (see below), the model has no tools or web access, and it never has access to other tickets or workspaces. The platform’s AI key is stored only as an encrypted worker secret in production, and test and staging environments do not connect to the AI provider (Anthropic). AI output is checked and HTML, images and links that are not in the conversation are removed, but that check is not a guarantee; staff review a result before it is sent. Research (searching the public web) is off by default, only a workspace owner can switch it on, and what leaves the system is a few generic search queries made from the ticket’s public messages, with the names of the requester, the staff member who clicked, the workspace’s other staff, and the workspace and organisation removed on a best-effort basis, and filtered for personal details on a best-effort basis, not the ticket itself. Everything that comes back from the web is treated as untrusted data: it is never followed as an instruction, text is stripped of markup, and the only links shown are the pages the search actually returned, which open in a new tab without sending a referrer and are labelled for staff to verify. Commands that look dangerous are removed and flagged. Nothing found by Research is sent to anyone or inserted into a ticket automatically; a staff member copies it or adds it as an internal note. Ticket text and prompts are not written to our logs, we do not train AI models on workspace content, and workspace owners can turn AI off.
- Payments. Paid plans and credit packs are on sale. Card details are entered only on Stripe’s hosted checkout and billing pages, so they never reach our servers and we never store card numbers; Stripe is responsible for protecting them. Only members with the billing permission (by default, owners) can open those pages. Stripe’s webhook messages to us are checked against a signature and a time limit before anything is changed, and we store only references and status, not the message content.
- API keys. API keys are shown once when created and only a hash of each is stored. A key acts with a role chosen when it is created, never more than its creator holds, and cannot hold settings, billing or member-management permissions. Keys can expire and can be revoked, which takes effect on the next call. Workspace owners are emailed when a key is created. API requests are rate limited, and keys and secrets are kept out of our logs.
- App connections (OAuth). When an administrator connects an app such as Zapier, the approval uses a one-time code and PKCE, and the app receives a short-lived access token and a refresh token that is replaced each time it is used. We store only hashes of codes and tokens, and keep them out of our logs. A connection acts with a role chosen at approval, never more than the approver holds, and cannot hold settings, billing, member or integration permissions. A refresh token used again after it was replaced stops the connection. An administrator can pause or disconnect a connection at any time, which takes effect on the next request.
- Data export. Only a member who holds the Owner role can export a workspace’s data, once in 24 hours, while the workspace is open or for 30 days after it closes. The file is built in the background, stored in Cloudflare R2 and emailed to the owner as a signed link that works for 7 days; the attachment and knowledge base image links in it work for the same 7 days, and the file is deleted from our storage afterwards. The link is the credential: anyone who holds the link can download the file until it expires, so do not forward the email. The request is recorded in the workspace’s audit log. API keys, webhook secrets, sessions and billing records are left out of the file.
- Signed webhooks. Each webhook endpoint has its own signing secret, stored encrypted in the database vault and shown once. Every message is signed (HMAC-SHA256) with a timestamp so the receiver can verify it and reject old messages, and the secret can be rotated with an overlap. Endpoints must use HTTPS on port 443 at a public address. We check the address when it is saved and again before every delivery, do not follow redirects, and stop waiting after 10 seconds. These checks reduce the risk of webhooks being used to reach private systems; they cannot remove it completely. Delivery logs are kept for 30 days. Customers are responsible for the security of their own endpoints and keys.
- Restricted access. Production access is limited to the operator.
- Input checks. The waitlist endpoint validates input and rejects requests from other origins.
What is planned
As ActiveQ grows we intend to add single sign-on, two-factor authentication for customer accounts, malware scanning of uploaded files, and documented incident-response practices; uploaded files are not scanned for malware today. Features marked “Coming soon” on the website are not available yet and will be reflected in our policies before they launch. These are plans, not current features.
Reporting a vulnerability
If you believe you have found a security issue, email support@activeq.app (our security.txt lists the same contact) with the details and steps to reproduce. Please give us reasonable time to respond and fix the issue before disclosing it, and do not access, change or delete data that is not yours, degrade the service, or use social engineering. We will acknowledge reports and will not pursue legal action against good-faith research that follows these rules.
Incidents
If an incident affects your personal information, we will notify affected people as required by applicable law.