Trust

Security

Last updated 14 October 2026

The short version: sign-ins and connected accounts are encrypted, people see only what their role and each flow’s sharing allow, every release is tested before it goes live, and we say plainly what we do not have yet.

Accounts and sign-in

  • Passwords are stored only as salted one-way hashes (scrypt). Nobody at xMap can read them.
  • Sign-in sessions are random tokens kept in a secure, HttpOnly cookie. Changing or resetting a password signs every other device out.
  • Two-step sign-in with an authenticator app is available to everyone, with one-time recovery codes. An organization can require it for all its members, and it is required for xMap’s own administrators.
  • Sign in with Google or Microsoft is accepted only when the provider confirms the email address.
  • Single sign-on with SAML (Okta, Microsoft Entra ID, Google Workspace and others) for organizations that prove their email domain with a DNS record. It can be required, so passwords stop working for that domain. Your identity provider can also add and remove people automatically (SCIM).
  • Admins can limit an organization to its own networks (an IP allow-list, which covers its API keys too), make everyone sign in again after a set time, and require longer passwords. The most common passwords are refused everywhere.
  • Sign-up is for company email addresses, confirmed by a one-time code. Repeated wrong passwords or codes are slowed down and then refused.

Who can see what

  • Three roles in an organization: admin, member and viewer, plus custom roles (a member with some things switched off, such as deploying or sending). Each flow is private, shared with the team, or shared with named people or groups, and its results, maps and runs follow the same rule.
  • Organization API keys belong to the organization, act as a member or a viewer (never an admin), and are named in the activity log.
  • Personal access keys act as the person who made them. Someone in several organizations chooses whether a key opens only one of them or all of them, and the key list says which. A key never carries xMap administrator rights.
  • Team connections are managed by admins. Personal connections (your own Gmail or Slack) can be used only by you, in flows you own.
  • When someone leaves an organization their access ends at once, their flows pass to an admin and their personal connections there are deleted.
  • xMap staff cannot open an organization unless one of its admins allows it, for a time the admin chooses (Settings, xMap support access). While they can, every page they open and every change they make is listed for the organization’s admins, who are emailed and can end it at once. Only one person at xMap can add or remove xMap administrators, and every administrator is told when that happens.
  • A private flow that uses a member’s own connected accounts, and what it finds, is seen only by that member and the people they share it with: not by organization admins, not by xMap. When the member leaves, what those accounts gave the flow is deleted before the flow passes on.
  • An account that is a person (Gmail, Google Calendar, Drive, Sheets and Docs signed in with Google, Outlook, Teams, Excel, Todoist, Apollo) can only be connected as that person’s own: it cannot be shared with the team. Only company accounts can be shared (a Slack bot, WhatsApp Business, CRMs, databases, API keys, Google through a service account), only by admins and after a confirmation; a new connection is personal unless an admin chooses Team. A Slack connection can be kept to the channels it lists, and kept from writing to people directly. The person a team connection signs in as is told the first time a colleague’s flow uses it. An admin who changes where a team connection points must enter its sign-in again, so a colleague’s key never goes to a new address.
  • Admins can download the organization’s activity log (who did what and when, kept for two years) and set a monthly spending limit for the whole organization.

Data protection

  • All traffic uses HTTPS. The database and backups are encrypted at rest by our hosting providers.
  • The sign-in details of connected apps (tokens, API keys, passwords) are encrypted again inside the database with AES-256-GCM, are never shown after they are saved, and are never sent to the browser.
  • Card details are handled by Stripe. xMap never receives full card numbers.
  • You can download everything we hold about your account, and delete your account, from Settings.
  • The Service is hosted in the United States with Vercel and Neon. The full list of providers is in the Privacy Policy.

Where your data is kept

  • The application, its database and its backups run in the United States, with Vercel and Neon. Files the Service makes (CSV downloads, satellite pictures) are kept in Vercel’s file storage in the United States.
  • xMap’s own data services (places, job postings, traffic, demographics) run on Google Cloud and Amazon Web Services: most of them on Google Cloud, and some older ones on Amazon Web Services in Japan. They receive what a flow searches for: a kind of place and a position, or the name of a place or company to look up.
  • AI, email, payments and the other providers process data where the Privacy Policy says, under the safeguards it describes.
  • A choice of data region, for example the European Union, is not offered today. If your organization needs one, book a call or write to legal@xmap.ai, so we know.

Application security

  • Text that people type is always shown as text: pages carry a strict Content Security Policy and do not run inline scripts.
  • Flows can call only public internet addresses. Private and internal network addresses are refused, checked again at the moment each connection opens. Calls to APIs and the HTTP block do not follow redirects; the pages that News and Web page watch read may redirect, and every address on the way is checked the same way.
  • Requests are rate limited per person, per organization and per visitor, in a way that holds when many requests arrive at once.
  • Credits are taken in single database operations, so two runs at the same moment cannot spend the same credits. Payment events are processed once.
  • Webhooks use a secret address that can be replaced at any time, and repeat calls are recognised.

How we build and release

  • Every change runs the full automatic test suite, including tests that send malformed input to every route. Only a change that passes is released.
  • After each release a check confirms that the live site, sign-in and the API are answering, and the site is checked again every few minutes.
  • Third-party packages are pinned to exact versions and checked for known vulnerabilities every week.
  • Independent reviews are part of our process: findings are fixed, and each fix gets a test so it cannot return.

Artificial intelligence

AI blocks run only inside flows that contain them. What they receive is described in the Privacy Policy. We do not use customer content to train AI models. AI answers are checked for shape and range before a flow uses them, and they can still be wrong: review them before you rely on them.

What we do not have yet

  • No SOC 2 or ISO 27001 certificate yet.
  • No choice of data region yet.

If one of these matters for your purchase, tell us at legal@xmap.ai.

Report a problem

If you believe you have found a security problem, write to legal@xmap.ai with the steps to reproduce it. We answer within two working days, we will not take legal action against research done in good faith, and we ask that you do not access other people’s data or disrupt the Service. The current state of the Service is on the Status page.