Skip to content
SWARE CRM
Documentation Platform

Security

How your data is separated, encrypted, scanned and access-controlled.

Your data is separated by account

Every record in the CRM belongs to exactly one account, and every lookup runs through the account you are signed in to. An identifier belonging to another account is simply not found — the check happens as the record is fetched, not after.

This is enforced through shared machinery rather than repeated by hand for each screen, and cross-account access is covered by an automated test contract that every part of the application is held to.

Access control

Four roles — member, admin, owner and account owner — with a single, shared definition of what each may do. Every action is checked against it. See Team & roles.

Underneath roles, individual fields can require a minimum role. Below that level the field is absent from forms, lists, filters and history, and the server refuses to accept a value for it. Because one rule decides all of those places at once, they cannot fall out of step.

Credentials and secrets

  • Integration tokens — Gmail, Calendly and CAPTCHA keys are encrypted at rest.
  • Your AI provider key — encrypted at rest, write-only in the interface, and never shown again beyond its last four characters.
  • API keys — stored only as a keyed one-way digest. The key itself is shown once at creation and never again; revoking one stops it working immediately.
  • MCP tokens — short-lived, and likewise stored only as one-way digests.
  • Passwords — hashed, never recoverable, and required to include upper and lower case, a number and a symbol, with a minimum length of eight.

AI assistants and MCP

An AI model that can read and change records needs more care than a person with a login, so the controls are built into the product rather than left to settings. See SWARECO AI and MCP for the details.

  • Same permissions. Both read and write through the same checks as the rest of the app, as the person using them. Every call is checked at the moment it is made.
  • Nothing can be deleted. There is no delete tool and no delete permission, so no instruction — however it arrives — can reach one.
  • Writes are opt-in. A new MCP connection is read-only. Write permissions sit in a separate warning panel and need an extra confirmation to grant.
  • SWARECO AI waits for a click. It proposes a change as a card. Nothing is written until the person chatting clicks Confirm, and the CRM re-checks the record and their permission at that moment.
  • Limited blast radius. One record per change, no bulk operations, and no way to reach another account.
  • Attributed. Changes are labelled MCP or Assistant in history. Every lookup SWARECO AI makes is recorded, and admins can review conversations in the AI activity log.
  • Private by design. Prompts and replies are not sent to our error tracking, and conversations can be removed on a retention schedule you choose.
  • Rate limited. Writes from connected assistants are limited per person and client.

Accounts and sessions

  • Email confirmation is required before an account can be used.
  • Repeated failed sign-in attempts lock the account temporarily.
  • Idle sessions time out.
  • There is no open registration — access is by invitation only, and an invitation link expires after 14 days.
  • Deactivating a member revokes their access on their next request.

Uploads

Files are checked against a content-type allowlist by inspecting their actual bytes, capped at 25 MB, and scanned for malware in the background. A detection quarantines the file for review and raises an alert rather than deleting it silently. Files are served through the application, so access is always checked. Files attached through MCP go through the same checks.

Public endpoints

Public capture forms accept only the fields their own configuration defines. Post-submission redirects are restricted to ordinary web addresses. Optional CAPTCHA verification is performed on the server and fails closed. Incoming integration callbacks must originate from the provider's published address range and carry a valid signature, verified within a short replay window.

In the browser

The application ships a Content Security Policy restricting where scripts, styles, fonts, frames and network requests may come from. Values supplied by customers are escaped on output, and link fields are limited to http and https addresses so a form submission cannot plant a script URL. Assistant replies are escaped or sanitised before they are shown, so a reply cannot run a script.

Dependencies

The dependency set is checked against published security advisories on every build, and a build fails if a known vulnerable package is present.

What we do not claim

We describe controls that are implemented in the product today. We do not currently hold SOC 2, ISO 27001 or any comparable third-party audit, and we will not imply otherwise.

We also cannot stop an AI model from being influenced by text it reads in your records, including text a visitor typed into a public form. That is why SWARECO AI cannot change anything without a click, and why MCP write access is opt-in and limited. If your review needs specific evidence, ask us and we will tell you plainly what exists.