All answers
Buying and evaluation

Is my data safe with a relationship intelligence tool?

Four questions settle it, and vendors differ on all four. Is the connection read-only or can it write to your systems? Does it read message metadata or message content? Does your relationship graph stay in your own tenant? And - the one most people forget to ask - does the vendor pool your data with other customers' to improve coverage?
October 2, 2026

The four questions, and why each matters

1. Read-only, or read-write? A tool that can only read cannot corrupt a CRM record or send an email as one of your people. If a vendor needs write access, make them name exactly which object and why.

2. Metadata or message content? Scoring a relationship needs frequency, recency and direction - who emailed whom, how often, how recently. It does not need the body of the email. A vendor reading content has a materially larger problem to defend in your security review.

3. Whose tenant holds the graph? Some vendors keep each customer's graph isolated. Others pool relationships across their customer base, so your coverage includes relationships your company does not have. That is a genuine feature and a genuine governance question, and it should be a deliberate choice rather than a surprise.

4. How is access revoked? Not just "can we cancel" - at what granularity, and how fast. Per client, per user, per organisation.

What Orbb's documentation commits to

Worth checking any vendor's docs rather than their sales deck. Orbb's are public:

  • Google Workspace connects read-only, through domain-wide delegation, with no documented capability to write or modify.
  • CRM connections use OAuth, not stored credentials - so there is no password of yours sitting in a vendor's database.
  • The MCP server is read-only across its entire tool surface: search, path-finding and interaction tools read, and no tool writes to the relationship graph, contacts, accounts, or back to any connected CRM, inbox or calendar.
  • MCP access is off by default and must be enabled per organisation. Until it is, every call is rejected regardless of authentication.
  • Authentication is OAuth 2.1 with no API keys, no shared secrets and no static credentials. Existing SSO and MFA policy applies unchanged.
  • Tenant isolation is server-side. The organisation is resolved from the authenticated user's identity record, not passed as a parameter, so a token structurally cannot return another tenant's data.
  • Every tool call is logged with the calling user, organisation, tool name and outcome.
  • Access is revocable at three levels: remove the client, deactivate the user, or disable the organisation - the last cuts off every connected client immediately.

SOC 2 and GDPR-readiness are covered on Orbb's trust page; for a security questionnaire, ask the customer team rather than relying on a marketing claim.

What your own legal team will ask

Separately from the vendor's posture, mapping your team's communications has obligations on your side under GDPR: a lawful basis, usually legitimate interests; a completed balancing test; an entry in your processing register; and a route to honour deletion requests.

The practical safeguard that does most of the work is telling your employees before you switch it on. It is also the one most often skipped.

The answer that should worry you

"We're fully secure and compliant." Every vendor says it.

The answer worth hearing names a mechanism: which scopes, which direction, which tenant, which audit log, and how to turn it off in a hurry.

Orbb finds the warm paths into your target accounts and names the colleague who can make the introduction.
See it on your own accounts