pairingby Denamico

Security

How Pairing protects your data

Pairing holds credentials for your systems and copies of the records it syncs. This page says what we do about that today, and what is still in progress.

Each client is kept separate

Every piece of data in Pairing belongs to one workspace, and every request is checked against it in the database itself, not only in the application. One workspace cannot read or change another's data. The background workers that run syncs use a different database role that those database rules do not cover, so a guard in Pairing's code refuses any query that is not tied to one workspace. Automated tests try to cross between workspaces to prove they cannot.

Your browser talks only to Pairing's API, never to the database directly. The API checks who you are and what your role allows on every request.

Encryption

Each workspace has its own encryption keys, and Pairing seals the following with AES-256-GCM:

  • connection credentials and sign-in tokens
  • the record data kept with sync history and held records, so they can be replayed
  • the value a record was held for, and the other system's message about it
  • the record data a webhook carries while it waits in Pairing's job queue
  • data scan examples and cleanup snapshots
  • an Anthropic key, if an admin saves their own

Credentials and keys are write-only: once saved, nobody can read them back through Pairing. Pairing's logs leave out credentials, tokens and record data. Workspace keys are themselves wrapped by a master key, which today is held as a secret in the hosting platform. Pairing can rotate that master key and each workspace's keys without downtime, and has a tool to re-encrypt older stored data under the current keys. The next section says what is not finished.

Not everything is sealed at the record level. The reason a record was held stays readable so you can see why. The value it was held for and the other system's message are sealed, and only people allowed to see record values see them. A failed run's error message is stored with quoted values and email addresses taken out. That is best effort, so treat a run error as possibly containing record values. Run errors are kept with the run.

Who at Denamico can see your workspace

  • Denamico staff set up and support your workspace, so they can open it in the portal and see what an admin sees. That access is an explicit staff record checked by the same database rules, and every change anyone makes, staff included, is recorded in the audit log with who made it.
  • Every time anyone opens sealed record values (a held record's value, a record trace with values, data scan examples), the audit log records who did it, when, and how many records were opened. Never the values. Every time Denamico staff look at a workspace's records, that is recorded too.
  • Staff must use two-step sign-in with an authenticator app. Staff sessions end after 12 hours, or after 8 hours without use. Client users can turn two-step sign-in on too.
  • Denamico's own cross-workspace health view shows counts and times only, with no record values, email addresses or error text.

AI features

  • AI features are off until an admin turns them on in Settings. Everything else in Pairing works without them.
  • They use Claude from Anthropic, through Denamico's account or an Anthropic key the admin provides.
  • Each feature sends only what it needs. The help center's Ask box and mapping suggestions send field names, types, option labels and workspace counts, never record values. A data scan that groups dropdown values sends, for one field at a time, up to 300 distinct values and how often each appears. Those are record values, and nothing else about the records goes with them.

The open fit check at /fit-check is separate: it sends the text you type to Anthropic, which may search the web for the systems you name, and stores the text for 180 days. Describe systems and problems there, not customer records.

Email and alerts

Alert emails and HubSpot tasks name the workspace, integration, event and counts. They never contain record values. Support emails carry only the request's subject and a link.

Calls to your systems

Pairing calls each connected system only at its own address. It refuses addresses on private networks and does not follow redirects. Changes that HubSpot and your other systems send to Pairing are verified before anything is processed, and anything unverified is refused.

Pairing limits how many requests each person, workspace and network address can make. It also limits each webhook address and each simulated system. HubSpot's own change notifications are never limited. Browsers are told to reach Pairing only over HTTPS.

How long data is kept

Once a day Pairing deletes sync history older than your workspace's retention window (90 days unless agreed otherwise): the per-record history of runs, resolved or dismissed held records, shadow comparisons and resolved alerts. Held records that still need attention are never deleted, however old.

Some data has no automatic purge yet and is kept until the workspace is removed: data scan findings, the before-values saved by cleanups, record links, support requests and the audit log. Denamico removes these by hand on request.

Where Pairing runs

Pairing runs on DigitalOcean in New York, with its database and sign-in on Supabase. Unexpected errors are reported to Sentry, with credentials and record values taken out. The companies that handle data for Pairing are listed in the subprocessor list, which is being finalised with Pairing's privacy notice and terms.

What we are still working on

Pairing has not had an independent security audit, and we make no compliance claims on this page. We are open about what is unfinished:

  • Pairing's own privacy notice, terms of service and data processing terms are being prepared with counsel. They are not published yet.
  • Moving production to a managed key service. Support for AWS KMS is built and documented with a rotation and recovery procedure, but production still keeps the master key as a hosting-platform secret, and the offline backup copies of that key are not set up yet.
  • Re-encrypting older stored data under the current keys. The tool exists and Denamico runs it by hand; we do not yet say that all older data has been re-encrypted.
  • Sealing held-record values saved before October 2026. Denamico runs a tool once to seal them. Until it has run, older held records may still show the value as readable text.
  • Incident response. A written security incident procedure covers detecting, containing, notifying you and rotating keys. It has not been tested in a drill yet. Written runbooks also cover monitoring, restarting the background worker, disaster recovery, a staging environment and moving the domain. The restore procedure has not been rehearsed.
  • Request limits are counted by each server on its own and start again when Pairing is updated. They are not yet shared across servers.
  • An automatic purge for data scan findings, cleanup before-values, record links, support requests and the audit log. Only the sync history above and the open fit check's questions are purged automatically today.
  • A Disconnect action for a HubSpot portal, inside Pairing.

Questions from your security team are welcome. Email [email protected] with Security in the subject.