Security

Overview

xNord processes email and mailbox metadata to run an AI-assisted inbox workflow. That data is among the most sensitive information a business holds. We design the product so that strong isolation, encryption, and least-privilege access are the default—not optional extras.

This Security page explains how we protect the Service in practice. It is not an exhaustive technical specification and does not replace contractual commitments in an order form or Data Processing Agreement (where we offer one). For regulatory rights, categories of data, and subprocessors, see the Privacy Policy. For the rules of use, see our Terms of Service.

If you believe you have found a vulnerability, use the Responsible disclosure section at the end—please do not perform testing that affects other users or production availability without permission.

Scope and relationship to other notices

• Privacy Policy: what we collect, why, retention, your rights, Google user data and Limited Use, cookies/analytics.
• Terms of Service: acceptable use, liability, AI disclaimers, billing.
• Cookie Policy: consent and non-essential cookies.
• GDPR information: supplementary EU/UK GDPR information where we publish it.

Encryption and key management

Encryption at rest

Our primary database is hosted with Supabase on AWS. Disk volumes and snapshots are encrypted at rest by the platform (AES-256 class encryption). Separately, mailbox OAuth refresh tokens — Google or Microsoft (and related secret material we treat as credentials) are encrypted at the application layer using AES-256-GCM before persistence. The symmetric key material is supplied via environment configuration, kept out of source control, and is not written to application logs.

Encryption in transit

Traffic between browsers and the xNord web application is protected with TLS 1.2 or higher. Our hosting provider terminates TLS at the edge; HTTP is redirected to HTTPS. Server-side calls to Microsoft Graph, Google APIs, and other providers also use TLS.

Key management

Production secrets (database URLs, encryption keys, Stripe keys, etc.) live in the deployment environment’s secret store—not in the repository. We rotate application encryption keys on a schedule and retain old key versions only as long as needed to decrypt existing ciphertext, then retire them securely.

Authentication and sessions

End-user authentication is provided by Supabase Auth. Depending on configuration, sign-in may include Microsoft identity and (when enabled) Google ("Sign in with Google"). We do not receive or store your provider account password. Session cookies and tokens are issued under Supabase’s cookie and JWT settings; you should sign out on shared devices and protect your identity provider account with multi-factor authentication where possible.

Access control and authorisation

Row-level security (RLS)

User-scoped tables enforce PostgreSQL RLS policies keyed on auth.uid(). The intent is that, even if application code mishandles a query, the database still refuses cross-tenant reads and writes. Service routes that must bypass RLS (for example Stripe webhooks or cron jobs) use a server-only service role key that is never shipped to the browser.

Principle of least privilege

The public client uses the Supabase anonymous key with policies aligned to authenticated users only where appropriate. Privileged operations run in serverless Node runtimes or trusted workers with narrowly scoped environment variables.

API authentication

Application APIs expect a valid Supabase session (cookie-based or bearer). Unauthenticated calls receive 401. Authorised but disallowed operations return 403. Administrative routes are additionally gated: non-admin callers typically receive 404 responses so as not to confirm the existence of internal paths.

Internal access

xNord personnel access production systems only where needed for support, debugging, or operations, under individual accounts (no shared root passwords) and with awareness of confidentiality. We do not use customer mailbox content to train public machine-learning models.

Mailbox OAuth and tokens

Outlook / Microsoft 365 uses Microsoft identity and OAuth 2.0. You approve the permissions presented by Microsoft (including mail read/write capabilities needed for triage, labels, archive behaviour, and sending messages you confirm). Tokens are stored encrypted and refreshed automatically; failed refresh marks the connection for re-authorisation rather than retrying indefinitely. Disconnect anytime in xNord Settings or revoke the app in your Microsoft account security pages.

Gmail / Google Workspace (when enabled) uses Google OAuth 2.0 with the scopes shown on the Google consent screen. Tokens are stored and rotated the same way as other mailbox connections. You can revoke Google access from xNord settings or from Google Account → Third-party access. Revocation stops new sync but does not erase historical rows already stored — deletion timelines are covered in the Privacy Policy.

Use of Google user data must comply with the Google API Services User Data Policy, including Limited Use requirements where applicable, as described in our Privacy Policy.

Email content we store and process

To power triage, summaries, drafts, and the in-app inbox, we process message content through our application and AI stack. The following reflects current product behaviour; field-level detail may evolve—see the Privacy Policy for the authoritative list of personal data categories.

Typically stored for processed messages

• Sender display name and email address
• Subject line
• Short preview/snippet text from the provider
• Plain-text body excerpt or normalised body text, currently capped at approximately 100,000 characters per message for storage and UI (longer messages are truncated)
• Optional HTML body when fetched or normalised for rendering in the product (schema-supported; population depends on code path)
• AI-derived fields such as summary, urgency, labels, suggested actions, and draft reply text
• Metadata: timestamps, provider message and thread identifiers

Attachments and binary content

We do not store full attachment binaries as a standard part of the core sync pipeline. Opening or forwarding attachments generally relies on live Microsoft Graph or Gmail APIs under your OAuth, subject to the provider’s security controls.

For AI processing, message bodies (up to shorter limits than the database cap) may be sent to inference endpoints—self-hosted or commercial APIs as configured for the environment—so that triage and drafts can be generated. Subprocessor roles are listed in the Privacy Policy.

AI inference and subprocessors

AI features depend on models and hosting that may include our own infrastructure (for example self-hosted Ollama-compatible endpoints) and/or third-party inference APIs. We select providers that offer contractual confidentiality and data-processing terms appropriate to acting as processors. Prompts and outputs may be logged minimally for reliability and abuse investigation; we avoid logging full message bodies in application stdout where feasible.

You remain responsible for reviewing AI-generated drafts before send and for decisions taken on the basis of model output, as stated in the Terms of Service.

Infrastructure, backups, and availability

Hosting regions

The web application is deployed on Vercel; the database and Auth services are provided by Supabase. For typical production configurations we target EU-based AWS regions (for example eu-west-1). Edge caching or global routing may still pass traffic through other PoPs for performance; see the Privacy Policy for international transfer mechanisms (including Standard Contractual Clauses) where relevant.

Backups and durability

Database backups are managed by our database provider, encrypted at rest, and retained for a limited window (for example on the order of 30 days unless we configure otherwise). Backups exist for disaster recovery—not as a user-facing restore feature unless we document one.

Uptime and change management

We monitor availability and error rates and ship fixes through a version-controlled deployment pipeline. We do not guarantee uninterrupted service; third-party outages (Google, cloud providers, payment networks) can affect the product.

Application and API security

• Input validation: API routes validate payloads with schema checks to reduce injection and malformed-data risks.
• Webhooks: Stripe webhooks are verified using signing secrets before trusted business logic runs.
• Dependencies: We track upstream security advisories for npm packages and apply patches as part of regular maintenance.
• Headers and cookies: Security headers and cookie attributes follow platform defaults from Vercel/Next.js and Supabase; we avoid embedding secrets in client bundles.

Logging, monitoring, and abuse prevention

We log operational events needed to run the Service: errors, high-level request metadata, rate-limit events, and billing webhooks. Logs are access-controlled and retained for a finite period appropriate to debugging and security investigations. Where product analytics run, they are described in the Privacy and Cookie policies (including consent for non-essential tools).

Rate limiting

Selected application actions are rate limited using a database-backed counter and rolling time windows so limits stay consistent across server instances. Representative limits in the current codebase include (subject to change):

• Manual agent run: 1 request per 2-minute window per user
• Inbox chat: 30 requests per 60-minute window per user
• Mailbox OAuth connect/start: 10 requests per 60-minute window per user
• Archive actions: 100 requests per 60-minute window per user
• Generate draft: 30 requests per 60-minute window per user
• Send draft: 20 requests per 60-minute window per user
• Revise draft: 30 requests per 60-minute window per user

Additional limits may apply at the CDN or mailbox API layer. We may tune thresholds to protect stability and fairness.

Incident response

If we become aware of a breach of security leading to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of personal data we process:

• We triage scope, containment, and remediation as a priority
• We aim to notify affected individuals without undue delay and, where feasible, within 72 hours of becoming aware for reportable incidents under UK GDPR
• We notify the UK ICO within 72 hours when legally required, and coordinate with subprocessors if they are implicated
• For significant incidents we prepare an internal post-incident review and may publish a summary where transparency helps the community

Your responsibilities

• Maintain control of your Google account and enable 2FA where offered
• Revoke OAuth access when offboarding employees or contractors
• Ensure your use complies with workplace policies and regulations applying to your sector
• Review AI drafts before sending, especially for legal, financial, HR, or safety-critical topics
• Report suspected vulnerabilities via security@xnord.co.uk rather than public exploit posts

Responsible disclosure

If you have discovered a security vulnerability in xNord, please report it responsibly:

Email: security@xnord.co.uk
PGP key: available on request for encrypted reports.

Please include a description, reproducible steps, potential impact, and any non-destructive proof of concept. We aim to acknowledge reports within 48 hours and coordinate remediation before public disclosure.

Please do not access or modify other users' data, perform denial of service attacks, or publicly disclose issues before we have had a reasonable time to fix them. We do not operate a public bug bounty programme at present but can credit researchers if they wish.