Connecting an AI tool to your business data is the part most people quietly worry about. So let's be specific about what clariBI's MCP integrations can and can't do — and where the lines are drawn.
Principle 1: every MCP connection is read-only
When clariBI registers itself with a vendor's MCP server, it asks for the narrowest scope set the vendor exposes: read records, search, list, fetch. It does not ask for write, modify or delete. The vendor's permission screen reflects this — when you authorize Stripe, you'll see "View your Stripe data", not "Manage your Stripe account".
If the AI engine ever wanted to call a "write"-class tool, our internal tool allowlist would block it before the request left clariBI. The allowlist is configured per-vendor and per-tool in our catalog database. There's no path for the LLM to bypass it.
Principle 2: credentials are encrypted at rest
OAuth tokens are encrypted with Fernet (AES-128-CBC + HMAC-SHA256) before they hit the database. The encryption key lives in our secrets manager, not in the application config. Decryption happens server-side at request time, just long enough to make the MCP call, then the plaintext token goes out of scope.
If our database backups were somehow exfiltrated, the attacker would get encrypted blobs without the key. Useless.
Principle 3: per-organization isolation
Every MCP connection is scoped to a single organization. The connection rows carry an organization_id, and every query against them filters on the current request's organization. Cross-tenant access is structurally impossible — not "policy-enforced" or "ACL-checked", but unavailable in the query path. Even an internal mistake can't accidentally surface another customer's data.
Principle 4: disconnect means deleted
When you disconnect a vendor in the data sources page, we delete the encrypted credential row in the same transaction. The vendor's data drops off the analysis surface immediately — the next question that would have used it gets routed somewhere else, or returns a "no data source" message.
We don't keep "soft-deleted" credentials around for analytics. The row is gone.
Principle 5: audit trails for who-connected-what
On Professional and Enterprise tiers, every MCP connection event is logged: who created it, who used it, who disconnected it, and when. Audit logs are exportable from the admin panel. If your compliance team needs proof that an integration was active for a defined window, the logs show it.
Principle 6: tier-gated access
MCP integrations are available on Trial, Starter, Professional and Enterprise. Free and Lite tiers can use native OAuth connectors (Google Analytics, Google Ads, Meta Ads, Jira) and file uploads, but the MCP catalog is gated to paid plans. This isn't a security thing; it's a pricing thing. The vendor-side cost of MCP connections scales with usage, and we don't want to subsidize unlimited free usage.
What we don't do
We don't write to your vendor accounts. We don't share your data with other clariBI customers. We don't sell your data. We don't train AI models on your data — the AI engine is provider-hosted and stateless against your data. We don't keep credentials after you disconnect.
If any of this is wrong for your security model, talk to us before connecting. We'd rather walk through the architecture in detail than have you connect a vendor you'd be uncomfortable connecting.
Full feature-page tour: how MCP integrations work.