Your IT team is going to ask. Here are the answers.
Single sign-on over SAML 2.0 and OIDC, SCIM provisioning and deprovisioning, workspace-wide MFA, role-based access control down to the record, and an exportable audit log. Plus the question no CRM security page answers: exactly what our AI does with your data.
What we are, and what we're not.
What's live today
SSO (SAML 2.0 and OIDC) with group → role mapping, SCIM 2.0 with deprovisioning, TOTP MFA with a workspace-wide policy, granular role-based permissions enforced across the app, the REST API and the MCP layer, and a searchable, exportable audit log. Everything on this page is shipped and running, not roadmap.
What we don't claim
Tidela has not completed a SOC 2 audit, and we're not going to dress that up as "SOC 2 aligned." We don't publish an uptime SLA yet. We'd rather you evaluate us on the controls below and the written packet than on a badge we haven't earned. If a certification is a hard requirement for you, tell us — it shapes our roadmap.
Single sign-on and SCIM.
Your identity provider stays the source of truth. Tidela reads it; it doesn't ask you to maintain a second directory.
- ✓ SAML 2.0 or OpenID Connect. Works with Okta, Microsoft Entra ID, Google Workspace, and any standards-compliant provider. Both SP-initiated and IdP-initiated sign-in are supported for SAML.
- ✓ Group → role mapping. Map your IdP groups to Tidela roles, so a change in Entra or Okta changes what someone can do in Tidela. No second admin panel to keep in sync.
- ✓ Just-in-time provisioning. Users are created on first successful sign-on with a configurable default role.
- ✓ SCIM 2.0 lifecycle. Create, update, and — the one that matters — deprovision. Disabling a user in your IdP deactivates their Tidela account and immediately revokes their sessions and API/OAuth tokens.
- ✓ Enforcement with a break-glass. Require SSO for the workspace; workspace owners can always sign in with a password, so a misconfigured connection can never lock you out.
Assertion handling
Tidela verifies your IdP's signed SAML assertion and requires assertion signing by default. It does not sign its own requests and does not require encrypted assertions — TLS protects the wire — so there is no SP keypair for your team to manage or rotate.
What we don't do yet
SAML Single Logout, SP request signing, and encrypted assertions are not implemented. SSO and SCIM cover internal users; external partner-portal logins use a password plus MFA. We'd rather list these than have you discover them in week two.
Multi-factor authentication.
TOTP, not SMS
Authenticator-app codes on the TOTP standard, with one-time recovery codes as the backup if a device is lost. Any user can enable it themselves from their profile.
Workspace-wide policy
Admins can require MFA for the whole workspace. Members without it are prompted to enrol on their next sign-in and can't get past the gate until they do.
Partners included
When you require MFA, external partner-portal logins have to enrol and pass it too — a gap in a lot of PRM implementations, and one we closed deliberately.
SSO users
If a user signs in through your IdP, their factor is handled there and Tidela doesn't double-prompt. Your IdP policy stays the single place you set the rule.
Permissions that hold everywhere.
The part most CRMs get half-right: the app enforces permissions, and then the API or the AI assistant quietly hands over everything anyway.
- ✓ Configurable roles, per-module rights. View, create, edit, delete, and export, set per module across every part of Tidela — including data import, web forms, and the partner portal.
- ✓ Record scope per role. All records, their team's records, or only what they own. Build teams, assign members, set the scope once.
- ✓ One decision point, three surfaces. The app, the REST API, and the MCP layer all read the same permission check on the server — not three parallel implementations that drift apart.
- ✓ Deny by default. A role with no grant for a module gets nothing; an admin grants explicitly.
Why the AI layer matters here
An AI assistant bolted onto a CRM is a new way to ask the database questions. If it runs with elevated rights, every permission you configured is decorative — a rep can simply ask for what they can't click.
Every AI action against a specific record — a brief, a draft, a workflow, anything through the MCP tools — runs under the invoking user's permissions and workspace scope. The workspace-level assistant, the one that answers "what should I chase this week," currently summarises across the whole workspace rather than the asking user's record scope. If you restrict record scope by role, know that before you roll it out; narrowing it is on our near-term roadmap and we'll say so here when it ships.
An audit log your SIEM can pull.
Sign-ins. Users created, invited, deactivated. Role assignments. Team membership. IdP group → role mappings. API keys minted, rotated, revoked. Data exports. Each with the actor, the target, before and after values where they apply, an IP address, and a UTC timestamp — so "who gave this person access, and when" has an answer.
Search, filter, export
Filter by category, actor, and time in the app. Export to CSV or JSON. Set a retention window that matches your policy rather than ours.
Get it out of our system
The strongest integrity guarantee isn't a checkmark we render — it's a copy we can't reach. Pull events into your own SIEM and that external record becomes the tamper evidence.
Hash-chained entries
Each entry is chained to the one before it with an HMAC, and the viewer reports whether the chain verifies — so a row altered or silently removed by someone with database access but not our application key shows up. A useful supplementary control, not a defence against a full compromise of the application itself, because the key is reachable by the app. We'd rather explain the limit than sell you a guarantee.
Record-level history too
Field-level edits live on each record's own history, so "who changed this close date" is answered on the record, and the audit log stays about security events.
The AI questions, answered plainly.
Tidela is an AI Selling platform, so this is the section your security team actually needs and most vendors don't write.
Grounded in your own records
AI features reason over your own workspace data. We don't blend customers' data, and we don't use one customer's data to build anything for anyone else. Two features deliberately reach further and say so on screen: research and enrichment consult public web sources to tell you about a prospect.
On demand, and on a schedule you set
AI runs when a user clicks something — what's sent is the record in front of them, at the moment they asked. The exceptions are the scheduled jobs you switch on yourself, such as the weekly digest and account briefs. Nothing sweeps your database continuously.
Drafts, never autonomous sends
The assistants propose; a human approves. An assistant never sends an email — it drafts one for a person to send. Where you've built an email sequence or turned on the weekly digest, a human approved that campaign and Tidela sends on the schedule you set. Writes back into your CRM go through a small server-side allowlist of additive, reversible actions.
Injection-resistant by design
Security decisions are made in our code, not by the model. A malicious instruction hidden in an email body or a website can't talk the assistant into widening its own permissions.
Metered and capped
Daily cost and call-rate caps are enforced ahead of model calls, with request timeouts, so a runaway loop or an abusive script is bounded rather than open-ended.
Usage analytics hold no content
Our internal usage tracking counts events. It does not store prompt text or the contents of your records.
AI is powered by Anthropic's Claude models over their commercial API by default. Workspaces may instead supply their own key for another provider, in which case prompts go to the provider you chose — your decision, and your contract with them. See the subprocessor list for every third party involved in running Tidela.
Infrastructure and data.
Hosting
Tidela runs on DigitalOcean infrastructure in the United States, with a Postgres database, automatic HTTPS on every connection, and encryption in transit and at rest. DigitalOcean maintains its own platform-level compliance certifications, which cover the infrastructure layer, not Tidela's application controls.
Tenant isolation
Every record belongs to one workspace, every query is scoped to the requesting user's workspace, and workspace membership is validated server-side on each request rather than taken from the client. There is no cross-workspace auto-join — a matching email domain never grants access to an existing workspace. This is the control we test hardest, and our July 2026 internal review traced it end to end and found no cross-tenant paths.
Secrets
Integration tokens, MFA secrets, and SSO client secrets are encrypted at the application layer with Fernet and are never rendered back into a page. Platform API keys are held server-side and are not exposed to workspace admins.
Your data leaves when you do
Export accounts, contacts, deals, and projects to CSV whenever you like, or pull everything through the REST API. Ask us to delete a workspace and it's purged — including the account and user details mirrored into our own systems for trial and support context. No exit tax, no hostage negotiation.
Application hardening
Content-Security-Policy and other security headers, CSRF protection, ORM-parameterised queries, login throttling, single-use expiring magic links, and a guarded outbound fetcher that refuses internal network addresses.
Where we're honest about limits
We run in a single region today (the data model is region-aware, so EU or Canadian residency is a deployment question rather than a rewrite). We don't publish an uptime SLA, and we don't yet offer SIEM streaming, passkeys, or field-level masking. Ask and we'll tell you exactly where each one sits.
The API is held to the same rules.
- ✓ Same permissions. API callers get exactly the reach their role allows — the permission check is one shared decision, not a parallel implementation.
- ✓ Scoped keys, with expiry and revocation. Each API key carries its own scopes and can be pinned to a list of permitted source IP addresses, so a leaked key is still bounded by where it can be used from.
- ✓ Request ledger. Every authenticated API request is recorded — fair-use policing and an audit trail in one.
- ✓ OAuth 2.0 with PKCE. For third-party apps acting on a user's behalf, with exact-match redirect URIs and PKCE required for public clients.
- ✓ Revocation that actually revokes. Deactivating a user through SCIM or in the app kills their sessions and their tokens at the same time.
Reporting a vulnerability
Email security@tidela.ai. We'll acknowledge within two business days and keep you posted until it's closed.
Test against your own trial workspace only. Don't access other customers' data, don't run denial-of-service or spam tests, and give us a reasonable window to fix things before publishing. Do that and we won't pursue any action against you for the research.
Machine-readable contact: /.well-known/security.txt
No SSO tax.
We don't hold single sign-on hostage behind an "Enterprise" tier at three times the price for the privilege of connecting your own identity provider — which is exactly what the CRM you're leaving does. Everything on this page costs no extra.
How it's switched on
Enterprise Security is a per-workspace setting we enable for you — ask, or say so during your trial, and it's on the same day at no additional charge. Turning it on starts your workspace's audit trail and activates role enforcement, the MFA policy, and SCIM.
What that means for a trial
A workspace that hasn't switched it on behaves the way a small team wants — everyone can see everything, and role restrictions aren't enforced. If you're evaluating Tidela with a security review in mind, turn it on at the start so you're testing the configuration you'd actually run.
Send this to your security team.
The written packet answers the standard vendor questionnaire — architecture, access control, data handling, incident response, subprocessors — in one document, so your review doesn't turn into a three-week email thread.
Questions from a security reviewer go straight to security@tidela.ai — they reach the person who built it.