Security is part of how Clario is built, not a layer bolted on afterward. This page summarizes the controls that protect your call data, bid data, and revenue operations.
Private workspaces by design
Each customer works in a private, dedicated workspace at your own subdomain. Access to your call, bid, and revenue data is limited to your own authorized users. Separation is enforced in the database itself — every tenant-scoped table carries a row-level security policy bound to the workspace on the connection, applied even to the table owner, so a query that fails to identify a workspace returns nothing rather than everything. Application code cannot opt out of it. Enterprise customers may opt into dedicated infrastructure.
Data minimisation: no caller identity in auction data
The most sensitive data in this category is the one we chose not to keep. A real-time bidding ping describes a consumer who has not connected to your business — and on an auction you do not win, never will. Clario records the commercial shape of that auction and not the person behind it.
- The number is discarded at the point of capture. Before an auction record is written, the caller's telephone number is replaced with a keyed one-way (HMAC-SHA256) identifier. The plaintext number is never persisted, so it cannot be retrieved, exported, or produced on request — there is nothing to produce.
- The key lives outside the database. The HMAC key is held in the service environment, not in any table, so a copy of the database — including a stolen backup — cannot be used to test numbers against the stored identifiers.
- Raw payloads are scrubbed on write. Auction request and response bodies are stored for diagnostics with caller fields removed and phone-shaped values redacted, so a number cannot survive in an unstructured corner of the record.
- What is retained: bids and bid responses, accept/reject/duplicate/rate-limit outcomes, latency, destination, publisher, campaign, and — for the caller — postal code, state, and the last four digits only.
- No role can see more. This is a property of the stored data rather than a permission setting, so it holds for every user, every administrator, and Clario's own operators equally.
- Per-auction records age out on a rolling fourteen-day window, after which only aggregates remain.
Records of calls that actually connected to your business are treated differently and deliberately so: those are your operating records and stay complete, caller number included. The distinction is set out in our Privacy Policy.
Enabling RTB capture is gated in-product behind terms describing exactly this, and the acceptance is recorded per workspace.
Access control & authentication
- Role-based access — each user’s permissions are scoped to their role, with elevated approval required for sensitive and account-changing actions.
- Protected sign-in with sessions that expire automatically; inactive sessions are ended.
- Optional two-factor authentication for an added layer of account protection.
- Sign-in protections that slow automated password-guessing attempts.
- A full audit trail — every action is recorded from proposed through confirmed to executed, and surfaced to administrators.
The AI is fenced in
Liza operates against a fixed, approved set of actions. It can read your data and propose changes, but:
- every write requires explicit operator confirmation before it executes;
- money-touching tools are excluded from the AI entirely;
- destructive tools are hidden and unavailable to the AI; and
- AI usage is subject to per-user and per-day spend caps; Enterprise plans may bring their own AI provider keys.
Encryption
All traffic to the platform and this website is served over HTTPS/TLS. Stored data relies on the encryption-at-rest capabilities of the underlying hosting environment.
The credentials that matter most get a second layer independent of the host. Your connected platform credentials, any AI provider keys you supply, and two-factor authentication secrets are encrypted at the application layer before they are written, using a key held in the service environment rather than in the database. They are decrypted only in memory at the moment they are used, and are never displayed in the interface or returned by the API. A copy of the database on its own does not yield them.
Credentials & integrations
Connections to Ringba, Retreaver, CallGrid, and TrackDrive use credentials you provide, scoped to what the integration needs, and are resolved per workspace — a request acting for one customer cannot reach another customer's platform account. Where the platform captures RTB traffic, the original configuration is snapshotted before any change, so capture can always be turned off and the prior settings restored without disrupting live traffic.
Monitoring & data integrity
An autonomous engine continuously watches data-flow and revenue health and raises findings for operator review rather than acting silently. Financial figures are reconciled before they are used, and stale or mismatched data is blocked rather than reported.
Sub-processors
We use a limited set of providers (hosting, your configured AI/transcription providers, and a messaging provider for Liza on Telegram). See our Privacy Policy for details.
Shared responsibility
We secure the platform; you are responsible for protecting your account credentials, managing user roles appropriately, safeguarding your AI provider keys, and meeting the call-compliance obligations described in our Terms of Service.
Responsible disclosure
If you believe you have found a security issue, please email security@elclario.com. We welcome good-faith reports and will work with you to validate and resolve them.