SECURITY AT SÍ CALL

Security you can verify, not just trust.

Enterprise buyers don’t want adjectives — they want controls they can check. Here is exactly how Sí Call encrypts your data, isolates your tenant, restricts access, and keeps a durable, time-stamped record of everything the AI does — cryptographically tamper-evident on the government tier. Stated plainly, with no certifications we haven’t earned.

Encrypted at rest, in transit, and in our logs.

Encryption is table stakes, so we make it boring and explicit rather than vague.

Encryption

aIn transitTLS 1.3Every request between callers, your browser, and our services is encrypted with modern TLS. No plaintext hops.

bAt restAES-256Stored data is encrypted at rest by default. Government tenants additionally get per-tenant AES-256-GCM keys for audit data.

cIn logsAuto-redactedSecrets and credentials are scrubbed from logs automatically, so tokens never linger in observability tooling.

How we handle your data

01US data residency — the app refuses to start outside US regions. There is no production deployment yet, so nothing is stored anywhere.

02Webhook payloads are signature-verified, with replay protection on inbound events.

03Rate limiting and CSRF protection are enforced across endpoints.

04Sensitive customer data is minimized in logs by design, not by manual review.

Least privilege, enforced in code — and one tenant can never reach another.

Access is scoped at the role, the action, and the tenant boundary. Defense in depth, not a single gate.

Access controls & isolation

01Role-based access controlTools and sensitive actions are gated by role. The receptionist can only invoke what its role permits — least privilege is enforced in code, not policy alone.

02Step-up authenticationHigh-impact actions require a fresh, stronger proof of identity at the moment they run — not just a session that was valid an hour ago.

03Passkeys / WebAuthnPhishing-resistant passkey sign-in is supported for operators, removing shared-secret passwords from the most sensitive accounts.

04Tenant isolationEach tenant’s data is partitioned and scoped to that tenant. Government tenants can layer per-tenant encryption keys on top of logical isolation.

The record is a security control — so we treat it like one.

When every action is written down as it happens, accountability stops being a promise and becomes a property of the system — and on the government tier, the log is cryptographically chained so alterations are detectable.

The record

01Every call filedTranscript, recording, summary, outcome — time-stamped at filing.

02Every action logged“Every call answered, every action logged” is an architecture, not a slogan.

03Government tier: tamper-evident audit logsAVAILABLE NOWCryptographic audit chain — government-tier logs are cryptographically chained, so altering or removing a past entry is detectable.

GOVERNMENT TENANTS CAN VERIFY THE CHAIN AND EXPORT FOIA-READY RECORDS

Found something? We want to hear from you.

Security is a collaboration. If you believe you’ve found a vulnerability, report it directly and we’ll work it in good faith. Email a clear report — steps to reproduce, impact, and any proof of concept. Please give us a reasonable window to remediate before public disclosure, and avoid privacy violations, data destruction, or service degradation while testing.

Coordinated disclosure

01Report to security@sicall.ai

02We acknowledge reports and keep you updated on remediation.

03Good-faith research under this policy will not be pursued legally.

Compliance posture

What’s certified, what’s in progress, and what’s on the roadmap.

We separate “how we’re built” from “what an auditor has signed.” You should never have to guess which is which.

01Designed following SOC 2 principlesLiveOur access controls, audit logging, and change practices are aligned to the SOC 2 trust principles today. This describes how the system is built — it is not a completed audit.

02No SOC 2 report — and no examination underwayOn the roadmapSí Call holds no SOC 2 report, has not engaged an auditor, and has no examination in progress. We will start one when a customer's security review requires it, and this row will say so when the observation window actually opens — not when we intend to open it. Until then the row above is the accurate statement: the controls are built to the trust principles, and no third party has attested to them.

03No FedRAMP authorization — ours or inheritedOn the roadmapSí Call holds no FedRAMP authorization and has not applied for one. Google Cloud's authorization of its own regions is Google's, and application authorization is never inherited from infrastructure. If a buyer needs an authorized vendor, that is not us today, and no phrasing on this page is meant to blur it.

04GovRAMP / FedRAMP path for governmentOn the roadmapA GovRAMP-first authorization path (with FedRAMP reciprocity) is on our roadmap, alongside government deployment into Google Cloud Assured Workloads and Azure Government inference. Application authorization is a third-party assessment — never inherited from the cloud — so we will not claim it until it is achieved.

On the record

Encryption you can name, not just nod at.

TLS 1.3 in transit. AES-256 at rest, with per-tenant AES-256-GCM keys for government audit data. Secrets scrubbed from logs by design. Every claim on this page maps to a control our Trust Center documents with evidence — nothing here is an adjective.

Trust Center & evidence

Get the full document package.

The Trust Center holds our threat model, control-by-control evidence, procurement answers, service levels, and disaster-recovery plan — everything your security review needs in one place.

Open the Trust Center →