Security

Last updated: 2 September 2026

Your pipeline, your mailboxes, and your calls are some of the most sensitive data your company has. This page describes, plainly, how Ishara protects them today: what we do, and what we do not claim.

Row-level security in the database

Ishara runs on Supabase Postgres with row-level security enforced in the database itself. Access rules live on the tables, not only in application code, so a query that reaches the database is still scoped to the workspace and role of the person making it. Analytics follows the same rule: dashboards run as the viewer, so a shared dashboard never shows someone records their own role cannot see.

Mailbox access by OAuth only

Gmail and Outlook accounts connect through each provider's own OAuth flow. We never ask for or store your mailbox password. We hold the tokens the provider issues, use them only to sync and send for the mailbox you connected, and you can disconnect a mailbox at any time from mailbox settings, per account.

Per-interaction call visibility

Call recordings and transcripts carry a visibility policy set per interaction. Org-wide ingest does not mean org-wide access: who can open each call is decided call by call, so a sensitive conversation can stay restricted while routine calls stay shared with the team.

Email suppression by reason

Suppression is enforced as a hard gate before every send, and it is scoped by reason: a marketing opt-out blocks marketing permanently without blocking transactional messages such as sign-in codes and invitations, and tracked messages carry one-click unsubscribe. Opt-out records are never discarded, because deleting one would cause the very messages the recipient refused.

PDPL-aware rails

The email rails were designed with the Saudi Personal Data Protection Law (PDPL) and similar regional laws in view: consent and opt-outs are recorded by reason and checked at send time. Designed with, not certified against; see the section on what we do not claim.

Provenance, undo, and audit

Every stored value is provenance-tagged (user, import, automation, formula, AI, enrichment, or system), so you can always see where a field came from. Destructive actions support undo, deletions go through a count-and-confirm trash with a retention window, and changes are written to a full audit trail so mistakes can be traced and unwound rather than silently lost.

AI processing boundaries

AI features run under a workspace policy your admins control, and only for the features you enable. Research answers carry citations, call insights cite the utterance they came from, and nothing an AI produces writes to a record until a human accepts it in the review queue.

No selling of personal data

We do not sell personal data, and we do not use your workspace content for advertising. How personal data is handled, including the public-source reference directories, is covered in the Privacy Policy.

What we don't claim

We do not currently hold third-party security certifications, and we won't imply otherwise. If your diligence process requires a specific attestation or a security questionnaire, email us and we will answer honestly about where we are and what is on the roadmap.

Responsible disclosure

If you find a vulnerability in Ishara, please report it to support@lisan.com before disclosing it publicly. Include steps to reproduce and, if you can, the affected component. We will acknowledge your report, keep you informed while we fix the issue, and credit you if you want credit. Please do not access data that isn't yours while testing.

Related

How we handle personal data is covered in the Privacy Policy; the rules of use are in the Terms of Service.