KeyText Security

Effective Date: April 29, 2026 Last Updated: April 29, 2026

SECURITY OVERVIEW

Security is a feature of KeyText, not an afterthought. This page describes how we design, build, and operate KeyText to protect your snippets, account data, and AI prompts. It complements our Privacy Policy and Terms of Service.

If something here is unclear, or you believe you've found a vulnerability, please email security@keytext.app. We read every report.

1. OUR APPROACH

We follow three principles:

• Collect the minimum. Free users can use KeyText with no account at all — snippets stay in chrome.storage. Account data is only collected when sync, billing, or AI requires it.
• Disclose every processor. AI inference is provided by the OpenAI API, where API content is not used to train OpenAI's models by default. Every other vendor that touches your data (database, payments, email, error monitoring) is listed in our Privacy Policy.
• Defense in depth. Encryption in transit and at rest, hardened auth, locked-down infrastructure, monitoring, and a tested recovery path — no single layer is the only thing standing between an attacker and your data.

2. INFRASTRUCTURE AND HOSTING

2.1 Where KeyText Runs

KeyText runs on a single self-managed virtual private server (VPS) provided by a major European hosting provider. The VPS sits behind nginx with TLS terminated by Let's Encrypt certificates that are renewed automatically. DNS is managed by Cloudflare (DNS-only / "grey-cloud"); Cloudflare does not proxy traffic, so it does not see your snippet content or AI prompts.

2.2 Network Posture

• Only ports 22 (SSH, key-only), 80 (HTTP, used solely to redirect to HTTPS), and 443 (HTTPS) are exposed to the public internet.
• Internal services (the API and admin dashboard) bind only to 127.0.0.1 — they are reached only via nginx, never directly from the internet.
• SSH password authentication is disabled. Only ed25519 public keys belonging to engineering staff are accepted.
• The host firewall (ufw) defaults to deny for all inbound traffic except the ports listed above.

2.3 OS and Patching

The host runs an LTS Linux distribution with unattended security updates enabled. Application services run under their own non-root system users via systemd with hardening directives (ProtectSystem, NoNewPrivileges, restricted filesystem mounts).

3. ENCRYPTION

3.1 In Transit

• All traffic between the Chrome extension, the marketing website, and our API uses TLS 1.2 or higher.
• HTTP requests to keytext.app and api.keytext.app are 301-redirected to HTTPS, and HSTS is enforced.
• TLS configuration follows current Mozilla "intermediate" guidance: modern cipher suites, no SSLv3 / TLS 1.0 / TLS 1.1.

3.2 At Rest

• Account and snippet data is stored in Supabase Postgres, which encrypts data at rest using AES-256 at the storage layer.
• Backups are encrypted with the same standard and stored in a separate region from the primary database.
• Secrets used by our services (database credentials, Stripe keys, Resend API key) live in /etc/keytext/env on the VPS with 0640 permissions, owned by root and readable only by the service account. They are injected into the systemd unit at start time and never written into the repository.

4. AI PROCESSING

AI is the part of KeyText where text leaves your browser, so it gets the strictest treatment.

4.1 AI Provider

All AI features (snippet generation, tone rewriting, auto-reply drafting, and variable auto-fill) are powered by the OpenAI API, operated by OpenAI, L.L.C. Per OpenAI's API Data Usage Policy, content submitted via the API is not used to train OpenAI's models by default, and is retained for up to 30 days for abuse monitoring before being deleted.

• Your prompts travel over HTTPS to api.keytext.app, which forwards the request to OpenAI's Chat Completions API and streams the response back to your browser.
• Our processing relationship with OpenAI is governed by OpenAI's Data Processing Addendum.
• Prompts and outputs are not retained on our servers beyond the lifetime of the request, except for an aggregate per-user monthly + daily usage counter (number of AI actions) used to enforce plan caps. The counters do not include prompt content.
• We do not use your prompts, snippets, or generated content to train any AI model of our own.
• We may swap the specific OpenAI model version for performance or cost reasons within the same provider; this does not change who processes your data.

4.2 Quota and Abuse Protection

The API authenticates every AI request against your Supabase JWT and enforces three layers of limits server-side: a per-user monthly + daily counter (database-backed), a 30-requests-per-minute sliding window per user, and a maximum of 3 simultaneous in-flight requests per user. When any of these reject a request, the rejection is logged to an internal security_events table that surfaces in our admin dashboard so abuse patterns are visible. The log captures the user identifier and event type — not the prompt content.

5. AUTHENTICATION AND ACCESS CONTROL

5.1 User Authentication

• Account auth is handled by Supabase Auth. JWTs are signed with asymmetric ES256 and verified against Supabase's public JWKS endpoint — no shared JWT secret leaves Supabase.
• Passwords are hashed by Supabase using industry-standard bcrypt. We never see plain-text passwords.
• Where supported, you can sign in with Google, Apple, or Microsoft OAuth instead of a password.
• Session tokens are short-lived and refreshed on a rolling basis.

5.2 Admin and Engineering Access

• Production access is limited to a small number of named engineers. Each has a personal SSH key; shared accounts and shared keys are not used.
• Admin dashboard access requires the same JWT plus an additional admin role flag in the database.
• Stripe, Resend, Supabase, and Cloudflare consoles are protected by two-factor authentication on every staff account.
• Access is reviewed when a team member's role changes; offboarding revokes keys and tokens before the access window closes.

5.3 Row-Level Security

Supabase row-level security policies enforce per-user data isolation at the database layer. Even if an authenticated request reached a row it shouldn't, the database itself would reject it — the application code is not the only line of defense.

6. CHROME EXTENSION SECURITY

6.1 Manifest V3

KeyText is a Manifest V3 extension. The service worker is event-driven and has no long-running background page. We do not ship remotely-hosted code, eval'd strings, or remotely-loaded WASM — every line of executable code is reviewed and bundled into the extension package submitted to the Chrome Web Store.

6.2 Permissions

The extension requests only the permissions it needs to expand snippets and process AI requests:

• storage — to cache your snippets, folders, and settings locally.
• scripting and host permissions — to detect the trigger character and insert expanded snippets in the page where you typed.
• commands — to enable the Ctrl+Shift+S shortcut.

The extension does not request permissions for browsing history, cookies from other sites, downloads, debugger access, or remote scripting.

6.3 What the Content Script Sees

The content script monitors text fields you type into for the trigger character (/ by default). It does not transmit what you type to any server unless you explicitly invoke an AI action. It does not read web page content outside of the field you're typing in. It does not access form fields containing passwords, autofill data, or payment information.

7. SUBPROCESSORS

We rely on a small set of carefully chosen vendors. Each handles a narrow slice of data and is bound by its own data-protection terms.

This list is kept in sync with our Privacy Policy. When we add or remove a subprocessor, both pages are updated and material changes are announced to account holders.

8. BACKUPS AND RECOVERY

• The Supabase Postgres database is backed up automatically on a daily schedule, with point-in-time recovery available for the most recent retention window.
• Backups are encrypted at rest and stored in a separate region from the primary database.
• Restores are tested periodically against a non-production environment to verify that backups are usable.
• The application code, infrastructure-as-code, and configuration templates are version-controlled in a private Git repository. The VPS can be rebuilt from the repository plus the encrypted secrets file.

9. MONITORING, LOGGING, AND AUDIT TRAIL

• The API records security-relevant events — failed sign-ins, invalid JWTs, AI quota exhaustion, suspicious billing webhook activity — to an internal security_events table reviewed in our admin dashboard.
• System and access logs are retained on the VPS with rotation; sensitive log fields (tokens, prompt content, message bodies) are scrubbed before write.
• Stripe webhooks are HMAC-verified against the configured webhook secret. Webhooks that fail verification are rejected and logged.
• Browser-side errors are captured by Sentry. Reports include the error stack, extension version, and the page domain — never the full URL, page contents, snippet bodies, or text you typed.

10. SECURE DEVELOPMENT

• All code changes go through pull request review on GitHub. The main branch is protected; deploys to production happen only via the reviewed CI/CD pipeline.
• Dependencies are pinned in lockfiles. Security advisories from GitHub Dependabot are reviewed and patched on a regular cadence.
• Secrets never enter the repository. Pre-commit checks and .gitignore rules block accidental commits of .env, credential files, and key material.
• The Chrome Web Store submission checklist is followed before every extension release to ensure the listing matches the manifest, permissions are justified, and no remote code is bundled.

11. RESPONSIBLE DISCLOSURE

If you believe you've found a security vulnerability in KeyText, we want to hear from you. Please email security@keytext.app with:

• A description of the issue and the conditions required to reproduce it
• The version of the extension, the URL you tested against, and your browser / OS
• Any proof-of-concept code, screenshots, or logs

Our commitments to you:

• We will acknowledge your report within 3 business days.
• We will keep you updated as we triage, validate, and remediate.
• We will not pursue legal action against good-faith researchers who follow this policy and avoid privacy violations, service disruption, or destruction of data.
• With your permission, we will publicly credit you in our changelog or a security advisory once the issue is fixed.

Out of scope: denial-of-service attacks, social engineering of staff or users, physical attacks, attacks on third-party services we do not control, automated scanner output without a working proof of concept, missing security headers without a demonstrated impact, and clickjacking on pages with no sensitive actions.

We do not currently run a paid bug bounty program, but we may issue swag or a thank-you for impactful reports at our discretion.

12. INCIDENT RESPONSE

If a security incident affects your personal information, we will:

• Investigate, contain, and remediate the issue as quickly as possible.
• Notify affected users by email, typically within 72 hours of confirming the scope, and post an advisory on the website.
• Notify applicable regulatory authorities where required by law (for example, under GDPR or the UAE PDPL).
• Publish a post-incident write-up describing what happened, what we did, and what we changed to prevent it from happening again.

13. COMPLIANCE ROADMAP

• SOC 2 Type I: in progress, with completion targeted for Q3 2026.
• GDPR / UK GDPR: we honor data subject rights for all users regardless of jurisdiction. See the Privacy Policy for the legal bases we rely on and how to exercise your rights.
• UAE PDPL: as a UAE-based company, we comply with Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data.
• CCPA / CPRA: California residents have full data subject rights, including the right to know, delete, correct, and limit use.
• Data Processing Addenda (DPAs): available on request from legal@keytext.app for Team and Custom plan customers.

14. ACCOUNT-HOLDER RESPONSIBILITIES

Security is a shared responsibility. To keep your account safe:

• Use a strong, unique password — or sign in with an OAuth provider you already protect with two-factor authentication.
• Don't share your account credentials. Team plan seats are issued to named users for a reason.
• Install the extension only from the official Chrome Web Store listing.
• Review the Custom AI prompts you save — KeyText executes them on your behalf, so a malicious prompt added by someone with access to your account will run when you trigger it.
• If you suspect your account has been accessed without authorization, email security@keytext.app immediately.

15. UPDATES TO THIS PAGE

We may revise this Security page as our practices, tooling, or threat model evolve. When we make changes:

• We will update the "Last Updated" date at the top of this page.
• For material changes — new subprocessors, changed encryption posture, expanded data collection — we will notify account holders by email.

16. CONTACT

Security reports and vulnerability disclosures: 📧 security@keytext.app

Privacy and data subject requests: 📧 privacy@keytext.app

Legal and compliance inquiries: 📧 legal@keytext.app

General support: 📧 support@keytext.app

Postal address: KeyText, Sheik Zayed Road, Sama Tower, Office 305, Dubai, United Arab Emirates

Effective Date: April 29, 2026 Document Version: 1.0

If you read this far and something feels weak, tell us. The fastest way to make KeyText more secure is to hear from people who care: security@keytext.app