Security at Solidmatics

We hold your team to evidence. Hold us to ours.

Solidmatics reads the tools your teams already work in, across operations, sales, support and engineering, and tells you in plain language whether they are all describing the same reality. So we hold a copy of real work data, and every control that protects it is written out below in full.

The important ones are enforced by code, not by a policy document. Your data is walled off inside the database itself, the AI has no database credentials at all, and the server refuses to start if either of those is ever misconfigured.

No certifications yet, and no badge here pretending otherwise. What exists today is on this page, including the parts that are heavier than you might expect.

This page itself loads no trackers and sets no cookies. The app does, and every one of them is named further down.

Last reviewed 28 July 2026

Connections

What we connect to, and why

Nothing connects until you connect it, and you can cut us off from the tool's own settings without asking us. One thing to know before you start: connecting a tool syncs everything that connection can see. The pickers narrow that down, they do not turn it on, so set them while you are connecting rather than afterwards. Most people start with two or three tools, not all of them.

Slack

Read and send

Chat

Messages in the channels you connect, so a decision made in chat and never written down anywhere else does not disappear.

Only the channels you switch on. This is also the one connector that can write, and it does so as the Solidmatics bot, never as you. Messages it sends on your instruction go to channels you enabled or people on your team list. Anyone who mentions the bot gets a reply in that thread, including in a channel you never enabled, and it answers there from a view with salaries stripped out. If that is more openness than you want, leave the bot uninstalled.

MeetGeek

Read only

Meetings

Transcripts of the meetings you sync, so what people agreed out loud can be checked against what happened afterwards.

All synced meetings unless you set rules to withhold specific ones. A withheld meeting's transcript is never fetched at all; we still keep its title, its time and who attended. We never receive audio or video, only text.

Jira

Read only

Work tracking

Issues, status changes and who moved what, so 'in progress' can be held up against what actually moved.

Every project you can see syncs unless you pick specific ones. Once you do, every query we build stays inside them.

ClickUp

Read only

Work tracking

Tasks, statuses and assignees, feeding the same picture Jira does.

Everything the connection can see, until you narrow it to chosen spaces and lists.

HubSpot

Read only

Sales

Your deal pipeline: what is open, what closed, and how long deals sit in a stage before anyone touches them.

Every pipeline syncs unless you pick specific ones. We read thirteen named fields per deal and nothing else, and we never call contacts, companies, tickets, notes, emails, calls or meetings.

Hanna CRM

Read only

Sales, CRM, finance, tasks, support

A field service and CRM platform used mostly in Europe. If you have never heard of it, skip this card. If you use it, read this one twice: it is the widest connector by a distance, covering your customers, contracts, installed equipment, invoices and payments as well as tasks and tickets.

Ten dataset switches, and all ten start switched on. You untick what you do not want rather than opting in. They work per dataset, not per field: leaving 'Customers and contacts' on means customer email addresses and phone numbers sync.

Intercom

Read only

Support, whole workspace

Support conversations, so a problem your customers keep raising shows up next to the work that would fix it.

There is no per-inbox picker yet, so the connection covers the entire workspace and the assistant can open any single conversation on request. This is the least scoped connector on the list.

GitHub

Read only

Code

Commits, pull requests, reviews, comments and CI runs, so a claim that something shipped can be checked against the work behind it.

Every repository the installation can see syncs unless you pick specific ones. Access is a GitHub App with read-only permissions: no write permissions are requested at all, and we never clone a repository.

GitLab

Read only

Code

The same picture as GitHub: commits, merge requests, reviews, branches and pipelines.

We read as the GitLab user who authorised the connection, so we see the projects that person is a member of. Same default: everything visible, until you narrow it.

Sentry

Read only

Errors

Which errors are firing and how often, so 'it works' can be measured against what is breaking in production.

One Sentry organisation, chosen by you. We only ever read the grouped issue, never an individual error event, which is why no stack traces or request payloads reach us.

Anthropic (Claude Code)

Read only

AI assistant usage

Your own Anthropic organisation's Claude Code usage: sessions, lines changed, commits and cost per person per day, so AI-assisted work shows up as work.

This is your team's AI usage, not the model we run on. One analytics endpoint, returning counts and costs only: no prompts, no completions, no conversations, no file names, no code.

The assistant behaves the opposite way to background syncing. With nothing selected it refuses to read at all, where syncing would take everything. So a tight setup means setting the pickers at connect time; it is not something the assistant will quietly work around for you.

What we hold

What lands in our database

Connector by connector, here is what we keep, including the parts that are heavier than people expect. Connect nothing and we hold nothing beyond your account.

Code and pull requests

GitHub, GitLab

In our database

Commit messages, authors and timestamps
Pull request titles, descriptions, reviews and comments
Branch names and CI run results
A verbatim copy of each record the platform returned, which carries commit author and committer email addresses

Never stored

Source code files, diffs or patches
Repository clones
Anything that would let us rebuild your codebase

Two edges worth naming. Inline review comments arrive with the few lines of surrounding code the platform attaches to them, and we keep the comment as it was sent. And if you ask the assistant to look at a merge request diff, it fetches that at the moment you ask and never keeps it.

Chat

Slack

In our database

Message text from the channels you connect
Channel names, threads and reactions
Who wrote what, and when

Never stored

Direct messages
Channels you did not connect

Slack asks for direct-message permissions during install, which alarms people, so to be clear: nothing in the product reads DMs. Channel discovery and message sync only ever touch the public and private channels you pick. Separately, when someone deletes a Slack message we mark ours deleted and keep the record that it existed, because a promise made and quietly removed is what you hired us to notice.

Meetings

MeetGeek

In our database

Transcripts, sentence by sentence, with speaker names
The title, the times and the host's email
The full attendee list, including people from outside your company

Never stored

Audio or video
The contents of any meeting your rules withhold

A withheld meeting keeps its title, who attended and when. The transcript body is never fetched in the first place, so there is nothing sitting around to delete later.

Production errors

Sentry

In our database

The grouped issue: its title, error type and message
How many times it fired and how many users it hit
Where in the code it surfaced, and who it is assigned to

Never stored

Individual error events
Stack traces and local variables
Request payloads, headers and cookies
The end-user context attached to an error

This one is structural rather than a filter we apply. The endpoint that returns individual events is never called anywhere in the product, so the data has no route in, either during sync or when the assistant looks something up.

Support conversations

Intercom

In our database

One row per thread: status, timing, ratings and tags
An excerpt of the opening message, capped at 500 characters
A verbatim copy of the conversation record Intercom returned

Never stored

The reply messages, one by one
Attachment files

The verbatim copy is of the conversation summary, and it does not carry the reply messages. Those stay in Intercom, though the assistant can open any single conversation live from your workspace when you ask it to. So read the right-hand list as 'not copied into our database' rather than 'out of reach'.

Sales pipeline

HubSpot

In our database

One row per deal: name, amount, currency, stage and pipeline
Expected and actual close dates, and the stage-change timeline
Your sales reps' names and email addresses

Never stored

HubSpot contacts, companies, tickets and notes
Emails, calls, meetings and any activity record
End-customer email addresses, phone numbers or postal addresses

Deal names arrive exactly as your reps typed them, and reps routinely name a deal after the customer. That is the one route by which a customer's name reaches us from HubSpot.

Customers, contracts and money

Hanna CRM

In our database

Customer companies with registration codes, emails, phones and addresses
Named contacts at those companies, with email, phone and job title
Contracts, installed equipment with serial numbers and site coordinates
Invoices, quotes, credit notes, expenses, payments and your price list
A verbatim copy of most records exactly as your Hanna account returned them

Never stored

Document and attachment files, as opposed to the record about them
Your Hanna API token, which stays with our credential broker

Unlike the other connectors, we cannot give you a list of what this one never stores, because we keep each record exactly as your Hanna account sends it. Whatever is in the record is what we hold. That is why the ten switches matter more here than anywhere else, and it is the only connector that brings your customers' personal data with it. Everyone you invite into your Solidmatics account can see all of it, so decide who is in the account before you switch this on.

Your team's Claude Code usage

Anthropic (your own account)

In our database

Per person per day: sessions, lines added and removed, commits and pull requests
Tokens and estimated cost, broken down by model

Never stored

Prompts and completions
Conversations and session content
File names, repository names or code

This connector reads a usage analytics report. Counts and costs are the only shape of data the endpoint returns.

Your team

Entered by you, plus the tools you connect

In our database

Names, work emails and platform usernames
Job titles and which platforms each person shows up on
Monthly salary, if you choose to enter it

Never stored

Anything about your team we did not get from you or a tool you connected

Salary is optional and only ever arrives by you typing it in. Anyone in your Solidmatics account can then see it, and so can the assistant when it reasons about your team. The bot that answers in Slack is the exception: it runs on a separate view with salaries stripped out, because a public channel is no place for them.

Alongside the fields we map, most tables keep the original record exactly as the platform sent it. That way a question we have not thought of yet can be answered later without re-syncing your history. It also means those copies can carry fields we never read. The same wall and the same wipe cover them.

Things we will never do with it

Sell your data, to anyone, for any reason
Show one customer's data to another
Train AI models on your data
Touch your card number: it goes straight into Stripe
Keep the keys to your connected tools in our own database: they sit with a separate service built to hold them

Access

Who can see your data

One question matters more than the others: can anyone outside your company read what we synced? Here is how that gets enforced, and where the edges are.

Your company is walled off inside the database

The wall sits in the database itself, not in our code remembering to filter things. The database will not hand back a single row unless the request says which company it belongs to, and if that stamp is missing the answer is nothing at all, not somebody else's data. It is the difference between a lock and a note on the door asking people not to come in.

Two internal logs sit outside that wall. One records messages arriving from the tools you connected, so we can work out what went wrong when a connector misbehaves. The other records payment events so you are never charged twice. Neither holds your work data, both are protected by our own code, and both are deleted with everything else when you wipe.

Even the database owner has to obey it

Databases normally let whoever owns a table skip these rules. We switch that exemption off on every table, and the app itself connects with an account that has no permission to bypass the wall at all. The credential that can change the database structure is a different one, and the running app never holds it.

The server refuses to start if any of that is wrong

Every time the app starts, it checks that its own database account cannot see across companies, then proves it by asking for rows with no company stamped on the request. If a single row comes back, the app shuts down instead of going live. A misconfigured release fails loudly rather than leaking quietly.

The AI has no database credentials

The assistant runs as its own service with no way to reach the database directly. It asks our API for data, and each request carries a pass that expires quickly and is stamped with your company. Your company is read off that stamp rather than off the request, so neither the model nor a tampered-with browser can aim it at anyone else's data.

The assistant can only look where you pointed it

The repositories, projects and channels you ticked are the entire world the assistant can read. Tick none and it refuses to read anything at all. It never writes its own queries either: every tool is a fixed operation with checked inputs, and anything a search turns up outside your configuration is dropped before the model sees it.

That covers what the assistant reads, not what we sync in the background. Background syncing goes the other way: it takes everything a connection can see unless you narrowed it when you set it up.

Inside your own company there are no walls yet

Everything above keeps one company out of another company's data. It does not divide your own company up. Anyone you invite in can see which tools are connected and what those tools brought with them, whoever connected them, including salaries you have entered.

So think twice before connecting a meeting account that records your one-to-ones. Per-person visibility controls are on the list and do not exist today.

People at Solidmatics

We reach production data to fix something you have raised with us. That is the reason we use it, and we do not go through customer data for anything else. We are small enough that you are usually talking to the person who did it. Treat that as a promise rather than something a machine enforces, because unlike everything above, that is exactly what it is.

Working with an outside agency or a contract team? Because the wall is drawn around the company account, the practical answer is to run two. Give the agency its own account with only the projects they work on connected, and keep a second one for your own side with everything in it. They see their patch, you see the whole picture, and neither of you is relying on a permission setting that does not exist yet.

What the AI sees, and what it can do

You are giving an AI a view of how your company actually runs. Here is the whole path your data takes.

One gateway, so the model can change

All of the analysis goes through a single gateway, OpenRouter, which makes the model doing a given piece of work a setting rather than a foundation. Different parts of the assistant can run different models, and any of them can be swapped, without changing how your data is handled: the rules here sit on the gateway rather than the model. The bar a model has to clear before we offer it is answering consistently in a format we can check, not having a famous name. Whichever one runs, the routing rule in the next card still applies, and every company that can end up holding a prompt is named in the subprocessor list below.

Whatever the model, it runs at temperature zero, the least inventive setting available, because this thing reports facts about your team rather than writing copy.

Providers that train on data are refused

Every request carries a routing rule that only permits providers which do not train on or publish what we send. It is a constraint rather than a preference: when no qualifying provider is available the request fails instead of quietly falling back to one that would.

The limit of that: it stops your data being trained on. It does not stop every provider briefly logging a prompt for abuse monitoring under their own terms. Guaranteed zero retention would mean routing to a much smaller pool of models that cannot reliably do the work this product depends on.

The model only ever sees your organisation

Every request the model makes comes back to our API carrying that stamped, short-lived pass, and the database wall plus your connector settings decide what it gets. The model cannot widen its own access, because it never gets to choose whose data it is looking at.

It can barely touch the outside world

Slack messages are the entire list of things the assistant can do beyond reading and reporting: one it sends when you ask, and a reply when someone mentions the bot. It cannot open tickets, push code, merge anything or message your customers.

Voice notes are the one exception

The microphone button in chat sends your audio clip to OpenAI's transcription API to turn it into text. That is the only data that goes anywhere other than the gateway above, and only when you press the button.

Conversations live where the assistant runs

Chat threads are saved on the platform the assistant runs on so a conversation survives a reload, and that includes the messages and the results the assistant looked up. Wiping your account asks for those threads to be deleted too.

Infrastructure

Where it runs and how it is protected

Specifics rather than adjectives. If a line here matters to your own compliance paperwork, ask and we will put it in writing.

In transit: HTTPS on every production endpoint.Certificates and TLS termination are handled by the platforms we host on.
At rest: Application and database run on Railway, on encrypted volumes, with platform backups.
OAuth credentials: Held by our own Nango deployment at connect.solidmatics.com and encrypted with AES-256-GCM.Nango is open source software we run ourselves, so no outside company is holding your tokens. Our application database keeps a connection reference and your scope settings, never the token.
Uploaded files: Private object storage, reachable only through links that expire after an hour.Bucket credentials never reach the browser. Avatars from a connected tool stay as a link until you pick one as someone's profile photo, at which point we copy the image into the same bucket.
Error reporting: Sentry, with its default personal data collection switched off.Every event and breadcrumb runs through a redaction step that strips anything named like a token, secret, password, key or authorization header before it leaves our servers.
Shipping code: Every change goes through a pull request and a required CI check.Direct pushes to the main branch are blocked, and database migrations run before the new version goes live.
Secrets: Environment variables, validated against a schema at startup.No production credentials live in the codebase.

Subprocessors

Other companies in the chain

Every company that touches some part of your data so the product can do its job, and exactly which part.

Clerk

Accounts and sign-in

Your name, email address and login activity.

Passwords are handled entirely inside Clerk. We never see one, and we keep no copy of your user or company records. SOC 2 Type II.

Stripe

Payments

Your billing details and card.

The card number is typed into Stripe's own embedded form and never reaches our servers. We store a customer reference, nothing more. PCI DSS Level 1.

Railway

Hosting and database

Everything the product stores, at rest on their infrastructure.

OpenRouter

AI gateway

The prompts we send for analysis, which contain excerpts of the work data being analysed.

Anthropic

Claude models, via OpenRouter

Those same prompts, at the moment the model answers them.

Anthropic builds the models we run. It is not always the company running them, because the same Claude models are also rented out on other clouds.

Google Cloud

Runs Claude models (Vertex AI)

Prompts, whenever the gateway sends a run to Vertex.

Microsoft Azure

Runs Claude models

Prompts, on the runs that land there.

Amazon Web Services

Runs Claude models (Bedrock), and file storage

Prompts, on the runs Bedrock handles. Separately, the files you upload: avatars and chat attachments.

OpenAI

Voice transcription

Audio clips recorded with the microphone button in chat. Nothing else touches OpenAI.

LangChain

Hosting for the assistant

Chat runs are saved there so a conversation survives a reload, which includes the messages and the tool results inside it.

Sentry (our own account)

Our error monitoring

Crash reports from the Solidmatics app itself, not from yours, with personal data collection switched off and secrets stripped before anything leaves our servers.

Nothing from the Sentry account you connect passes through here.

Resend

Transactional email

Your email address and the contents of the emails we send you.

Intercom (our own account)

Our support inbox

Whatever you write to us in the support chat, plus your name and email.

Separate from the Intercom workspace you connect as a data source.

PostHog

Product analytics

How you move around the app: pages, clicks, and the account they belong to.

Google

Tag Manager and Analytics

Website and app usage measurement.

Usercentrics (Cookiebot)

Cookie consent

Your consent choices.

Which companies appear in the model chain depends on which model is running. The same model is often rented out on several clouds, and the gateway picks whichever one is healthy at the time, so a request that goes to Anthropic today might go to Google tomorrow. The names above cover every model we offer. Add one that would pull another company into the chain and this list changes before that model does. Whoever ends up running it, the rule that no provider may train on what we send holds, and a provider that does not qualify gets refused rather than quietly used as a backup.

Two pieces you might expect on this list are deliberately not here. Nango brokers your connections to other tools and Inngest runs our background jobs. Both are open source and both run on our own infrastructure, so neither is an outside company holding your data.

Need the hosting regions in writing, or a data processing agreement for your own paperwork? Email security@solidmatics.com and we will sort it out with you.

Deletion

Getting your data out, or gone

All of it is yours to trigger, without our permission and without waiting on us.

One clickWipe everythingOrganisation settings, danger zone. No support ticket, no waiting on us to get to it.

30 daysGrace periodClose your organisation and the wipe runs after 30 days, in case you change your mind.

What the wipe actually removes

All synced work data and everything built on top of it, deleted in one go: it either all goes or none of it does, so nothing is left half-erased. It also deletes the keys to your connected tools, asks the platform the assistant runs on to delete your chat threads, and detaches saved cards from Stripe.

Financial records survive on purpose: what you paid and what you spent. We keep those as an audit trail and will send you a copy whenever you want one. The database deletion is all-or-nothing; the chat threads live on another company's platform, so that part is a request rather than a guarantee. Tell us if you need it confirmed and we will check it by hand.

Nothing gets to quietly survive it

Every organisation-scoped table has to be classified in code as either wiped or deliberately kept. Miss one and the build fails. A second check compares that list against the live database, so a new table cannot slip through unclassified.

Disconnecting a single tool

That integration's credentials are deleted from our broker straight away. The history we already synced stays, so reconnecting later carries on instead of re-importing everything. Run the full wipe if you want the history gone too.

One thing we cannot do from our side: the app authorisation inside GitHub or Slack stays until you remove it there. That is deliberate on their end, not ours.

How long we keep things

There is no automatic expiry. Synced data lives as long as the connection and the organisation do, because a report about last quarter needs last quarter's data. If you need a shorter retention window, tell us what it should be.

Compliance

Where we actually stand

We do not hold a SOC 2 report. We have not commissioned a third-party penetration test. There is no badge going on this page that suggests otherwise.

What we did instead was build the controls those audits look for, and write them down here in language you can hold us to. The wall around your data, the deletion, the way keys are handled: all of it works today, and most of it is enforced by code that shuts down rather than by a document.

A formal audit is a question of when. Until it happens, this page is what we have, and the offer behind it is open.

Email security@solidmatics.com with any question about how your data is handled and a founder answers it.

Incidents

If something goes wrong

The commitment, with a number attached so it means something.

72 hoursBreach notificationFrom the moment we confirm a breach affecting your data, you hear from us inside 72 hours.

How we would find out

Errors from our own software are reported to us as they happen, and every release is checked after it lands. There is a gap here worth naming: we do not run a public status page yet, so you would hear from us directly rather than watch a dashboard.

What you would get from us

An email to your account owner covering what happened, which of your data was involved, what we did about it, and anything you need to do at your end. Written like an email from a person.

Disclosure

Found a vulnerability?

Tell us before you tell anyone else and we will treat you well for it.

Email security@solidmatics.com. Machine-readable contact details live at /.well-known/security.txt, following RFC 9116.

What is fair game

Testing against your own account and your own organisation's data. If you find a way to reach data that is not yours, stop right there and tell us. That is precisely the report we want, and poking further only makes it harder for both of us.

What we ask you not to do

No denial of service testing, no automated hammering of the sign-up or payment flows, and no social engineering of our team or our customers.

What you get back

An acknowledgement within five working days and a straight answer about what we did with the report. We do not run a paid bounty programme yet. Public credit is yours if you want it.

Questions

The things people actually ask

Can my team tell I am using this?

They can see the app authorisation sitting in GitHub or Slack, because that is how those platforms work. Beyond that we read without commenting: nothing from Solidmatics turns up on a pull request or inside a ticket. Slack is the exception, and the details are in the connections section above. Whether you tell your team is your call, and most people do.

Do you read private Slack DMs?

No. Slack's install screen asks for direct-message permissions, which is alarming to read, so to be specific: nothing in the product reads DMs. We only ever look at the public and private channels you switch on.

Is my data used to train AI models?

No, and we route every request so that only providers who do not train on it are allowed to answer. If none is available the request fails instead of falling back. The full path is in the AI section above.

Who inside my company can see all this?

Everyone you invite into your Solidmatics account, including salaries if you enter them. We separate one company from another rigorously and do not yet divide things up inside a single company, so there is no way today to connect a tool only you can see. It matters most for meeting transcripts.

Can I keep an outside agency out of my internal data?

Yes, by giving them their own account with only their projects connected, and keeping a second one for your own side. It is more setup than running one account, but it uses the boundary that is genuinely enforced rather than a permission toggle we have not built.

Do I have to connect everything at once?

No, and most people should not. Connect the two or three tools where the arguments actually happen, usually chat, meetings and whatever your teams track work in, and see whether the reports tell you something you did not already know. Widen it later.

Who owns the data?

You do. We hold a copy so we can do the work you are paying for. Take it back or delete it whenever you like, without asking us.

Can I get a data processing agreement?

Tell us what your side needs at security@solidmatics.com and we will work through it with you. We would rather do that properly than hand you a template nobody has read.