Security

01Our approach

Clients trust us with their brand, their content and access to their tools. We protect that with a small set of controls built into the platform from the start, and we describe them here plainly. This page covers what we do today. Where something is still on our roadmap, we say so rather than claim it.

02Infrastructure and hosting

• Platform hosting: the Comma platform and its databases run on a managed cloud hosting provider in the United States.
• Website and DNS: getcomma.ai and our DNS are served through a global network provider that also absorbs denial-of-service attacks.
• Managed services: we rely on established providers for email delivery, error monitoring and AI models rather than running our own, and we review them as described in section 11.
• Secrets: application secrets, such as the encryption and signing keys, are held in the hosting provider's environment configuration, not in our source code.

03Workspace isolation

• Each client workspace has its own separate database. A workspace's content, settings, integration keys and history live only in that database.
• Every request is resolved to a single workspace before any data is read, and a person can only open workspaces they're an active member of.
• A small shared registry holds the information needed to sign people in and route them to the right workspace: workspaces, members, roles and sign-in security settings.
• Each workspace has its own web address, so browser sessions and links stay tied to the right client.

04Encryption

• In transit: the website and platform are served only over HTTPS, with HTTP Strict Transport Security telling browsers never to connect without it. Our calls to providers' APIs use HTTPS too.
• Integration secrets at rest: API keys you bring (such as an Ahrefs key), CMS tokens, the Search Console refresh token, Notion tokens and Slack webhook addresses are encrypted with AES-256-GCM before they're stored, and they're masked whenever the platform shows them.
• Two-factor secrets: authenticator app secrets are stored encrypted with AES-256-GCM, and backup codes are stored only as hashes.
• Passwords: stored only as salted scrypt hashes. We never see or store your password itself.
• Access tokens: MCP tokens are shown once when created and stored only as hashes.
• Webhooks: each outgoing webhook is signed so you can check it came from us.

05Sign-in and authentication

• Passwords and two-factor: people sign in with their email and password. Two-factor authentication is available for every account, using an authenticator app or a code sent by email, with single-use backup codes for recovery.
• Brute-force protection: repeated failed sign-ins and code attempts are throttled and locked out for a period. The counters survive restarts.
• Sessions: session cookies are HTTP-only, sent only over HTTPS and restricted to our own site. A session ends after 48 hours without use.
• Revocation: changing or resetting a password signs that person out everywhere, and removing someone from a workspace cuts off their access, including any MCP tokens they created.
• Our team's console: the internal console our team uses to manage workspaces requires a second factor at every sign-in.

06Access control and roles

• Roles: each person in a client workspace is an Owner, Editor, Reviewer or Viewer. Roles decide what they can see and change, and Owners can adjust individual permissions and turn areas off for specific people.
• Checked on the server: permissions are enforced on every request on our servers, not just hidden in the interface.
• MCP access: tokens for AI assistants belong to one person in one workspace, act with that person's permissions, and can be revoked at any time.
• Our team's access: people on our team who deliver your services can access your workspace to do the work. Sensitive administration, such as creating or deleting workspaces, is limited to a small group.

07Application security

• Cross-site request forgery: every request that changes data must come from our own origin. Requests without a matching origin are rejected.
• Security headers: responses carry headers that block framing by other sites, stop content-type sniffing, limit referrer data and disable camera, microphone and location access.
• Rate limits: sign-in, code requests, the workspace assistant, uploads and other sensitive or costly actions are rate limited.
• Outbound requests: web addresses that people enter, such as webhook targets or a website to analyse, are checked so they can't be used to reach internal systems.
• Content handling: rich content shown in the platform is sanitised before display, and values in our emails are escaped.
• Testing: the codebase has automated tests for permissions, sign-in, workspace routing and other security-sensitive paths.

08Monitoring and logging

• Error monitoring: application errors are reported to an error monitoring service, configured not to collect user details or request bodies.
• Activity records: we keep records of sign-ins (time, IP address and device), which workspace Owners can see for their members, plus application logs of significant events and a revision history of content.
• Log retention: application logs are kept for 14 days inside each workspace.

09Incident response

If we suspect a security incident, we work to contain it, investigate what happened, fix the cause and record what we learned.

• Clients: if an incident affects personal data in your workspace, we'll tell you without undue delay and within 72 hours of confirming it, with what we know and the steps we're taking, as set out in our DPA. We'll keep you updated as we learn more.
• CERT-In: as a business based in India, we report cyber incidents covered by CERT-In's directions to the Indian Computer Emergency Response Team within six hours of noticing them.
• Data protection authorities: where we're the controller, we notify the Data Protection Board of India and other authorities and affected people as the law requires.

10Backups and deletion

• Backups: our team can take a full copy of any workspace database and restore it. Backup copies are kept on access-restricted systems.
• Automatic retention: monitoring data is deleted after 180 days and Search Console data after 365 days, by a job that runs every night in each workspace. Other retention periods are listed in our privacy policy.
• Deleting a workspace: when a workspace is deleted, its database and its records in the shared registry are removed, and its Owners are told by email. Any backup copies are deleted within a further 30 days.

11Vendor management

We choose established providers and check their security and privacy commitments before we use them. We sign data processing terms with each provider that handles personal data, give each one only the access it needs, and keep platform-level keys out of the client workspace. A current list of providers is available on request at privacy@getcomma.ai and is included with every DPA.

12People and practices

• Everyone on our team is bound by confidentiality obligations.
• Our team uses company accounts protected by two-factor authentication.
• Access to client workspaces and production systems is limited to the people who need it, and removed when it's no longer needed.

13AI safety and data handling

• Only what's needed: we send our AI model provider only the text needed for the task in hand.
• No training: under our provider's commercial terms, it may not train its models on the data we send.
• Short retention: our model provider deletes what we send, and its outputs, within 30 days. It keeps data longer only where the law requires, or for up to 2 years if its automated safety systems flag a request for review.
• Untrusted content: public pages and community posts are clearly marked as untrusted data inside our prompts, so instructions hidden in them aren't followed.
• Human review: AI outputs are drafts. Our team reviews them before anything is published on a client's behalf.

Our AI terms cover this in more detail.

14Compliance and questionnaires

We don't hold SOC 2 or ISO 27001 certification today. We design our controls with these frameworks in mind and will share our plans as they firm up. In the meantime, we're happy to complete security questionnaires, walk your team through our controls, and share more detail under a non-disclosure agreement. Email security@getcomma.ai.

15Responsible disclosure

If you think you've found a security vulnerability in Comma, please email security@getcomma.ai with enough detail for us to reproduce it. Our contact details are also published at /.well-known/security.txt.

• We'll acknowledge your report, keep you updated, and let you know when it's fixed.
• Please give us reasonable time to fix the issue before sharing it publicly.
• Don't access, change or delete data that isn't yours, run denial-of-service or social engineering tests, or test against client workspaces. Use your own account, and stop as soon as you've confirmed an issue.
• We won't take legal action against good-faith research that follows these guidelines.

We don't run a paid bug bounty at the moment.