Security, in full

Last reviewed: July 16, 2026

Some buyers are required to check. If you’re a law firm vetting us under Rule 1.6(c), start at the section written for you — same facts, gathered where you need them.

So here’s the whole thing, including the parts most vendors leave out.

Who else sees your callers’ data

This is the question that matters most, and almost nobody answers it.

When someone calls your business, their words don’t stay in one place. Voice AI is a chain of vendors, and you should know every link before you sign anything.

Every vendor above operates in the United States for our account. There is no offshore processing.

Where this stands with Retell: we have a signed data processing agreement with them — including EU standard contractual clauses — and they hold a SOC 2 Type II attestation. What we’re still confirming in writing is their onward retention terms with the model providers above; their formal subprocessor documentation is on request, and this page changes when it’s in hand. Until then, the chain is published so you can evaluate it yourself — and if your practice requires a specific arrangement, ask us before you sign and we’ll get you the answer in writing rather than a guess.

Where your data lives, and how long

Location. Database and application in the United States — Ohio and Virginia. Automation infrastructure in Virginia. Nothing offshore.

Recordings and transcripts at Retell: 90 days, then deleted automatically. We set that deliberately — long enough to investigate a disputed call inside your guarantee window, short enough that we’re not sitting on a permanent archive of your customers’ worst days.

Transcripts in our database: retained while you’re a client. Deleted on request.

When you leave: we delete your data on request. Today that’s a manual process we run by hand rather than an automated one — we’d rather tell you that than imply a button exists. Retell’s copy ages out on its own 90-day clock.

Who can touch what

Nobody but you sees your data. Every table in the database enforces row-level isolation at the database layer, not in application code. That means the isolation holds even if application code has a bug. It’s verified by an automated test on every deploy that authenticates as a real restricted user and confirms the boundary.

Every endpoint checks a role, not just whether someone is logged in. Being authenticated isn’t authorization.

Belmont’s own admin access is separated from anything a client can reach.

Multi-factor authentication is enabled on every account that supports it — source control, database, hosting, payments, domain registrar, and Google Workspace. The domain is transfer-locked.

One exception, and we’ll name it: our voice platform account is email-based sign-in with no MFA option — Google sign-in exists on their platform but can’t be linked to an existing account. That account is reachable only through an MFA-protected Google Workspace inbox on a registrar-locked domain. The day we can link it or they ship MFA, we do, and this paragraph changes.

What’s encrypted, and by whom

In transit: TLS on everything. No plaintext path anywhere in the system.

At rest: our infrastructure providers encrypt storage at the disk level (AES-256), and they’re independently audited for it.

On top of that, we encrypt specific things ourselves:

• Calendar credentials — AES-256-GCM at the application layer, before they ever touch the database, with the key held only in server-side secrets. If someone got the database, your calendar tokens are still ciphertext.
• Booking links — the token in your confirmation email is stored only as a SHA-256 hash. We can’t read the link we sent you.

What’s in plaintext, so you know: call transcripts, caller names and numbers, message bodies, adverse-party names. They’re protected by row-level isolation and encrypted disks, not by field-level encryption. We tell you this because a vendor who says “everything is encrypted” without qualification is either confused or counting on you not asking.

No secret ever reaches the browser. Every credential lives server-side. Verified in code.

What the intake does — and doesn’t

Our intake captures the adverse party’s name, verbatim, on every call, and surfaces it for your review before the consultation.

We do not run a conflict check. We have no access to your matter records and we don’t claim otherwise. The system collects the name and puts it in front of you. You check it. Any vendor telling you their AI clears conflicts is describing something they can’t do.

The AI is an AI

Your callers are told, plainly, if they ask. The intake agent never implies it’s a lawyer, never suggests speaking with it creates a relationship with your firm, never gives legal advice, never estimates case value, and never comments on deadlines. Those are hard constraints in the agent’s instructions, not preferences.

It captures facts and books consultations. Everything else is yours.

For law firms

Attorneys have their own duty to satisfy — ABA Model Rule 1.6(c)’s reasonable efforts to prevent disclosure, which includes vetting the vendors that touch client information. The four answers you need, in one place:

• Who hears your callers. The full vendor chain — including the AI model providers — is published above: Who else sees your callers’ data. Every link named, nothing bundled into “trusted partners.”
• How long recordings and transcripts live. 90 days at the voice platform, deleted automatically; our database copies deleted on request: Where your data lives, and how long.
• Conflicts. The intake captures the adverse party’s name verbatim and surfaces it for your review — we never claim to run a conflict check: What the intake does — and doesn’t.
• What the AI will never say. It discloses that it’s an AI, never gives legal advice, never implies representation, never estimates case value, never touches deadlines: The AI is an AI.

Each line above links to the section that carries it — this summary makes no claim of its own.

How we build

Secrets can’t reach the repository. Three independent layers: a pre-commit scan on every developer machine, a full-history scan in CI on every push, and push protection at the hosting layer. A secret has to defeat all three.

Every push runs type checking, a production build, a dependency vulnerability audit, and two custom checks that fail the build when the security surface changes without the change being declared. That second part is unusual and it’s the one we’re proudest of: our documentation of what’s exposed can’t drift from what’s actually exposed, because the machine won’t let it.

Automated alerts when a vulnerability is disclosed in a dependency we ship.

Rate limits fail closed where it counts. Any request that spends money or starts a call is denied if the limiter itself breaks. Cheap public pages fail open by design — a broken limiter shouldn’t take your booking page down with it.

What we don’t have

Every vendor’s security page lists what they have. Here’s what we don’t, so you can decide for yourself rather than find out later.

• No third-party penetration test. We haven't paid an external team to attack the system. We plan to.
• No SOC 2 or ISO 27001. Our infrastructure providers are certified — Supabase and Vercel hold SOC 2 Type II. We aren't. A solo firm claiming SOC 2 is claiming something that costs more than it earns at our size.
• Our incident response plan has been run once, not rehearsed. A vendor in our chain disclosed a breach; we ran the plan on it end to end — timestamp, scope, severity, containment decision, written incident file. It found we weren't affected, verified from our own records rather than memory — and it found a real gap of ours: vendor security bulletins weren't reaching us. That's closed. One real run doesn't make a rehearsed program, and the plan has never been exercised on an incident of our own with the 24-hour notification clock live. That clock stands: you'd hear from us within 24 hours of confirming any exposure of your data, before we finish investigating, not after.
• No automated data deletion. Deletion is manual and we do it on request.
• No DPA on the shelf. If your firm requires one, ask and we'll work through yours.
• No cyber liability insurance. We're evaluating it.
• We're one person. Belmont Motion is a solo practice. No employees means no personnel security program — it also means nobody else has access to anything, and there's exactly one person accountable to you. Read that whichever way you like, but read it accurately.

Reporting a vulnerability

Found something? Email support@belmontmotion.com with the details. We’ll confirm receipt within one business day and tell you what we’re doing about it. We won’t argue with you and we won’t threaten you.

Why this page is shaped like this

Most security pages are a list of reassurances. This one names its own gaps, its own subprocessors, and the one account without MFA — because you’re going to ask, and because a vendor who volunteers the hard parts is telling you something a vendor who doesn’t can’t.

Everything here was verified against the actual system, not against a template. Last reviewed July 16, 2026.