Security

Last Updated: November 9, 2026

Overview

BlazeXL runs Python and shared business logic for Excel, the web workspace and APIs. This page describes the security controls that are in place today. It does not describe planned features. BlazeXL has not yet been audited against SOC 2 or ISO 27001.

1. Where code runs

  • Local Python in Excel: when a cell runs on your computer, it runs in a sandboxed worker loaded from a separate site (wasm-runtime.blazepy.com). The worker cannot read your BlazeXL sign-in, cannot call Excel, and can make network requests only to its own site, to load the runtime's files. When a cell uses blazexl_fetch_json or blazexl_fetch_csv, the add-in downloads the public HTTPS address written in the cell before the cell runs and passes the result in. A cell that runs too long is stopped, the worker is replaced, and that cell's next recalculation runs on our servers.
  • Server-side Python: runs in containerised executors, separate from the gateway and the databases. Executors are pooled and reused; each task runs in a fresh process, and temporary files are cleared between tasks.

2. Accounts and access

  • Organisations: accounts are normally part of an organisation, whose roles and teams decide who can see and change shared logic and data.
  • Sign-in: email and password, with optional two-step sign-in using an authenticator app. Passwords are stored as bcrypt hashes. Sessions use short-lived tokens (15 minutes) renewed by a refresh token (up to 30 days). Signing out stops the session from renewing; tokens it already holds stop working when they expire (at most 24 hours). Changing your password, or Revoke all on the Access & Tokens page, ends every session; the gateways apply it within about 30 seconds.
  • Access keys: the Excel add-in and the SDKs use access keys that are tied to one organisation and one kind of client, and can be revoked from the workspace.
  • Single sign-on: OIDC and SAML are not available yet.

3. Governed logic

  • Blocks: shared logic is saved as versioned Blocks. Publishing a Block to the whole organisation requires review and approval by an organisation admin. A Block shared only with a team is not reviewed.
  • Strict Mode: a workbook can declare the Blocks it depends on. With Strict Mode on, the add-in refuses inline code and drafts: a direct call must name a declared, published Block, and a handle built from a published Block is allowed. The add-in asks before using a Block you have not approved. Strict Mode is enforced by the add-in; the gateway separately refuses unpublished Blocks.
  • What is not governed: with Strict Mode off, Python written directly in a cell runs as written, without review.

4. Encryption

  • In transit: every public endpoint uses TLS 1.2 or 1.3, with HSTS.
  • At rest: Block and App code, session data, and the data objects held by the compute service are encrypted by the application before they are written. Names, descriptions, review notes and audit records are stored without application encryption.

5. The AI Analyst

The AI Analyst writes Python code and explanations. Numbers in your results come from running that code, not from the model. When you use it, your request is sent to an AI model provider (currently OpenAI, Anthropic, Google or xAI; the current list is on our Sub-processors page). If a provider fails, the request can be retried with another. What a request contains is described in our Privacy Policy (section 5). The code it returns is shown to you before it runs. BlazeXL does not train AI models on your data.

6. Audit

  • What is recorded: for server-side execution and administrative actions, the gateway records who acted (with their email and IP address), when, from which interface, and which Block versions ran. Cells computed locally in Excel are not recorded centrally.
  • Tamper evidence: audit events are hash-chained, so a changed or missing event in the stored chain is detectable.
  • Access: organisation owners and admins on the Pro and Enterprise plans can review their organisation's audit trail in the workspace.

7. Reporting a vulnerability

Email security@blazexl.com (also listed in security.txt). Please include steps to reproduce. We acknowledge reports and keep you informed while we fix them.

We will not take legal action against good-faith security research that follows these rules, and our Terms of Service (section 4) treat it as permitted:

  • test only accounts, organisations and data that you own or are allowed to test;
  • do not set out to access other people's data; if you come across it, stop, do not change, keep or share it, and tell us;
  • do not disrupt or degrade the Service for others, and do not run denial-of-service, spam or social-engineering tests;
  • report the issue to us promptly, and give us reasonable time to fix it before you disclose it.