Security
Last Updated: September 14, 2026
This page describes, in plain terms, how Beltroni AI protects the data that passes through our platform. It's written for both our customers and the security or IT reviewers evaluating us. For how we handle personal data more broadly, see our Privacy Policy.
1. What Data Our AI Agents Are Trained On
Beltroni AI agents are trained using publicly available business information — your website content, published service descriptions, and business details you provide — plus any documents or configuration you explicitly upload as Training Data. We do not ingest sensitive personal information (PII) or confidential third-party customer databases as part of our automated training process, and we do not acquire non-public data about you or your customers from outside sources.
Separately, once an agent is live, it processes operational data you connect to it — for example, call transcripts, chat logs, and calendar or CRM data accessed via OAuth — in order to do its job (booking appointments, answering questions, logging leads). This operational data is handled under the terms of our Privacy Policy, is scoped to your workspace, and is never used to train agents belonging to other customers.
2. Infrastructure & Hosting
Beltroni AI's application layer — including our web platform and voice services — runs on Google Cloud Platform (GCP), deployed via Google Cloud Run. Google Cloud Platform maintains its own SOC 2 Type II, ISO 27001, and HIPAA compliance programs for the infrastructure it operates; details are published in Google's own compliance resource center.
Our application database is hosted on Supabase and is not part of Google Cloud Platform. We're noting this specifically so infrastructure diagrams built from this page are accurate: GCP hosts our compute and voice layer, Supabase hosts our database.
3. Supabase Data Backend
Our data backend implementation follows Supabase's row-level security (RLS) model. RLS is enabled on the tables that hold account and customer data, and no request — including one made with a public API key — can read or write a row unless an explicit policy allows it.
Every database request passes through the same enforcement point. There is no client path to the database that bypasses Supabase's service layer, so no request — regardless of which part of the application it comes from — can reach a row without first being evaluated against that table's RLS policies. That single choke point is also where visibility lives: because every request is forced through it, every request is visible in Supabase's own request and query logs, giving us one consistent place to control and review data access rather than a patchwork of checks scattered across application code.
Why RLS matters: Supabase exposes your database directly to client applications through its API. Without RLS, anyone holding the public anon key could read or write any row in any table. RLS closes that gap by attaching an implicit filter to every query, enforced by the database engine itself rather than by application code that could be bypassed or contain a bug. Each policy checks the caller's identity from their session and JWT claims (for example, auth.uid()) directly inside Postgres, so authorization can't be skipped by calling the API a different way.
How it works: enabling RLS on a table is a default-lockdown switch — once it's on, every request through the API is denied until a policy explicitly allows it. We write separate policies for anonymous (signed-out) and authenticated (signed-in) roles, and each policy is scoped to a specific operation — read, insert, update, or delete — rather than granting blanket access. An update policy also requires a matching read policy, since Postgres needs to evaluate a row against the read rule before allowing a change to it.
Further reading: Supabase's own Row Level Security documentation.
4. Service Guardrails on Agent Configuration
Every agent configuration is screened by our own guardrail layer before it is saved. The check runs server-side, on the API route that persists the configuration — not in the browser — so it applies to every request regardless of how it reaches us, and a configuration that fails is rejected outright rather than flagged and allowed through.
The screen is aimed squarely at impersonation and abuse: agents may not be configured to present themselves as government agencies or law-enforcement bodies, financial institutions, public healthcare programs, or the support desks of major technology and payment brands. It also blocks configurations matching known fraud and social-engineering patterns, and flags authority-title and contact-detail patterns commonly used to make a fraudulent agent sound legitimate.
We deliberately do not publish the specific terms and patterns the screen matches on. Listing them would tell someone attempting to build a fraudulent agent exactly where the boundary sits and how to word their way around it.
5. Encryption
Data in transit between your browser, our AI agents, and our servers is encrypted using TLS. Data at rest in our database is encrypted using our database provider's standard encryption. Your Google OAuth tokens are stored in an encrypted format, as described in our Privacy Policy.
6. Compliance & Audits
Beltroni AI operates to established security standards. Formal certification is a decision we have already made — timed to our enterprise customer's requirement, with a partner already identified.
We rely on Google Cloud Platform's own SOC 2 Type II, ISO 27001, and HIPAA compliance programs to secure the infrastructure our application and services run on.
Security documentation follows the engagement. The Security Posture Whitepaper, architecture diagrams and completed vendor-security questionnaires are included with an Elite Plan subscription and shared under NDA once an evaluation is underway. We don't circulate them ahead of that — it keeps our security detail with the teams actually deploying on it.
Compliance vendors: we are not evaluating providers.
7. Questions
For enterprise procurement teams, the Security Posture Whitepaper is included with an Elite Plan subscription and shared under NDA once an evaluation is underway.