Security & Data Handling

Your support conversations are Issues in your own repository

When a customer emails you, Scitor creates a GitHub Issue or Discussion in a repository you own. The sender's name, email address, message, and any attachments live in that Issue — under your GitHub account, subject to your own access controls and retention, exportable at any time with GitHub's standard tools. Scitor does not have a separate database of "your tickets."

What Scitor itself holds is a smaller, specific set of records — attachments, a few opt-in features (contacts, CSAT, suggestion votes), and aggregate usage counts. The table below lists every one of them, where they live, how long they're kept, and how to delete them. If it's not in this table, Scitor does not store it.

What Scitor stores

What Scitor does not store

• Email content after processing. Once the GitHub Issue or Discussion is created, Scitor does not retain a separate copy of the email.
• Plain-text email addresses for blocked senders. Only a SHA-256 hash is stored — the original address is never persisted.
• Voting identity. Suggestion votes are stored as anonymous hashes, not as personal information.
• AI analysis input. Email content sent for AI analysis is used for that single request and not persisted by Scitor or by Cloudflare Workers AI.

Data flow

Inbound: an email arrives

1. The email reaches your unique, non-guessable inbound address. Twilio SendGrid's Inbound Parse receives it and validates SPF/DKIM before forwarding it to Scitor.
2. Scitor checks the sender against your block list (SHA-256 hash comparison). A match drops the message silently — nothing else happens.
3. Automated-message and bounce-loop detection runs next (mailer-daemon addresses, auto-reply headers, and similar signals). An automated reply to an existing ticket is dropped before any other side effect, so out-of-office notices and bounces never land on a customer conversation. A new automated message (a newsletter or notification) becomes a ticket labelled auto-generated, unless you set inbound.auto_generated: drop. Mail that isn't delivered is held for 7 days so a mistake can be undone, then deleted.
4. Attachments are uploaded to Cloudflare R2.
5. If AI is enabled, the message is analyzed for sentiment, category, priority, a one-line summary, and language — a bounded slice of the email, discarded after the response (see AI handling).
6. SendGrid's own spam score for the message is bucketed into a label (clean / low / medium / high).
7. A GitHub Issue or Discussion is created in your repository with the sender, subject, body, and attachment links.
8. Labels are applied (AI labels, priority, spam score), and routing rules auto-assign the ticket if configured (Pro).

Nothing about the raw email persists beyond this point. What remains is the Issue or Discussion in your repository and the attachments in R2 — both governed by the retention rules above.

Outbound: a reply is sent

1. An agent — a person or a coding agent acting on your team's behalf — comments /send (or /sendall) on the Issue or Discussion.
2. Scitor renders that Markdown to HTML via GitHub's own API.
3. On a private repository, any private GitHub-hosted images referenced in the reply are inlined as email attachments, since the recipient can't reach GitHub's private image CDN.
4. The email is composed with a Reply-To address that encodes the conversation's thread ID, so a customer's reply comes back to the same Issue.
5. The message is sent through the configured email provider — Twilio SendGrid in production.
6. Delivery events (bounce, spam report, dropped) are posted back as a comment on the Issue. On a public repository, the recipient's email address is redacted in that comment.

GitHub permissions

Scitor's GitHub App requests only the permissions it needs:

AI handling

AI analysis runs on Cloudflare Workers AI — processed wherever Cloudflare is handling the request, not routed to OpenAI, Anthropic, or any other third-party model provider. Each call sends a bounded slice of context (the ticket, truncated, plus a handful of retrieved knowledge-base excerpts where relevant) and the request body is not retained after the response. Nothing is used to train, fine-tune, or evaluate any model.

If you'd rather email content is never processed by any AI system, disable it entirely:

ai:
  enabled: false

Full detail — per-feature data sent, models used, and every AI-related control — is on the AI Transparency page.

Repository visibility

Issues and Discussions in a public repository are world-readable — including your customers' email addresses, names, and messages. This isn't a Scitor-specific risk; it's how public repositories work. If your support repository is public, anyone can read every conversation, and anyone can open an Issue directly, bypassing your email workflow entirely.

Scitor warns you about this once, in the welcome message posted when you install the app on a public repository. It does not block installation, and it does not re-check on every incoming email — a repository can be switched from private to public at any time in GitHub's own settings, entirely outside Scitor's visibility, so there is no ongoing guarantee we could make here even if we tried to enforce one.

Our recommendation: use a dedicated, private repository for customer support, separate from any public product repository. This is a GitHub-level setting you control — check it under your repository's Settings at any time.

Infrastructure & subprocessors

Scitor runs on Cloudflare Workers — a globally distributed edge-computing platform. All connections use HTTPS/TLS, and data at rest relies on Cloudflare's platform-level encryption; there is no self-hosted infrastructure to secure separately.

Your support conversations are GitHub Issues or Discussions, so they live in your own GitHub repository — under GitHub's own terms and in GitHub's own locations, which are not in the EU. That's a property of the architecture, not a Scitor decision: you already made that call when you chose GitHub as your support platform. What Scitor itself stores is different, and it's not something you can see: it sits in three Cloudflare-operated locations, each fixed today but none bound by a jurisdiction constraint — a primary database (tickets metadata, contacts, CSAT, metrics, configuration) in Western Europe, attachments in Western North America, and compiled knowledge-base/ documentation sites in Eastern North America. Two of these three are outside the EU, but they hold materially less personal data than the GitHub side: full message content, names, and email addresses live in the Issue or Discussion body, not in Scitor's attachment or docs storage.

Region here means where the underlying Cloudflare D1/R2 resource currently sits, not a contractual commitment — none of the three carries a jurisdiction restriction, so none is bound to stay there. Cloudflare D1's jurisdiction setting can only be chosen when a database is created; adding one to an existing database (ours included) would mean creating a new database and migrating into it, not a configuration change.

Personal data originating in the EU that Scitor stores in North America (attachments, compiled docs sites) needs a lawful transfer basis under GDPR — this applies to those two Scitor-operated stores, not to the GitHub side above, which is GitHub's own relationship with you. Today, our basis for that transfer is Cloudflare's own data processing terms, which Scitor is bound by as a Cloudflare customer; if you need more detail for a vendor-security review, contact security@scitor.io.

We use the following subprocessors, each for the purpose stated:

• Cloudflare, Inc. — hosting, database, storage, AI processing, bot protection (Turnstile).
• GitHub, Inc. — the Issues and Discussions your tickets live in, and app authentication.
• Twilio Inc. (SendGrid) — outbound email delivery and inbound email receipt.
• Stripe, Inc. — subscription billing. Card details are entered directly with Stripe and never touch Scitor.
• PostHog, Inc. — product analytics for the app dashboard and Public Ticket Portal.
• Statsig, Inc. — marketing-website analytics only; never touches support data.

The full, current list — with countries and legal basis for any transfer outside the EEA — is maintained in our Privacy Policy.

Compliance

• GDPR. Customer email addresses can be hashed (blocked senders) or stored only within your own GitHub repository, which you control. Contact database data is deleted by removing the contact, or automatically on uninstall. AI processing retains no data beyond the request.
• CAN-SPAM. All outbound emails include unsubscribe headers and honor unsubscribe requests automatically.
• Data portability. Your support data lives in your GitHub repository as Issues or Discussions — you own it and can export it at any time with GitHub's standard tools.
• Controller / processor roles. For your End Customers' data (emails, names, messages, attachments, survey responses), you are the data controller and Scitor is your data processor, acting only on your instructions. For your own account and billing data, Scitor (MindByte) is the controller.
• Data Processing Agreement. Available on request at support@scitor.io.
• Certification. Scitor does not currently hold SOC 2 or ISO 27001 certification. In lieu of a report, we'll walk any prospective customer through the architecture on this page, provide the DPA on request, and recommend running on a private repository as described above.
• Breach notification. We'll notify affected customers without undue delay, and within 72 hours where legally required.

Reporting a vulnerability

Found a security issue? Email security@scitor.io. We aim to acknowledge reports within 5 business days. Please include enough detail to reproduce the issue; we'll follow up with next steps and, where appropriate, credit for the report.

This contact is also published at /.well-known/security.txt, following the security.txt convention.

Questions

Send anything this page doesn't cover to support@scitor.io. We're happy to walk through specifics for a security review or vendor assessment. The implementation-level version of this page, for engineers who want more detail, is on our documentation site.