Overview
Mr Vero runs voice agents, messaging agents, and back-office automation that handle real conversations with your customers and modify data in your connected systems. That makes the trust boundary unusually wide. This page describes the controls we put in place to keep your data safe, the providers we rely on, and where the responsibility line sits between you and us.
We are an early-stage company. We do not yet hold formal SOC 2 or ISO 27001 certification. We have, however, built the platform from day one against the Australian Privacy Principles and the security expectations of regulated industries (aged care, real estate, healthcare adjacent). Where we have not yet been independently audited, we say so.
Infrastructure and data residency
Hosting. The Mr Vero platform runs on Microsoft Azure. Primary application and database workloads are deployed to the Australia East region (Sydney). Real-time voice infrastructure (OpenAI Realtime, Twilio media streams, low-latency speech inference) routes through the United States by necessity, as our voice model providers are US-resident.
Tenant isolation. Mr Vero is a multi-tenant platform. Each customer is provisioned as a separate logical tenant. Every database query in the application layer is filtered by tenant identifier through a centralised tenant context, and shared data infrastructure is partitioned along tenant boundaries. There is no path in the API surface that bypasses tenant filtering.
Data segregation. Different categories of data live in separate database schemas with no cross-schema foreign keys: business and CRM data, security and identity data, and channel-specific data (email, voice, calendar). This means a defect in one subsystem cannot read or modify data in another.
Encryption
In transit. All traffic between you, our APIs, and our backend services is encrypted with TLS 1.2 or higher. Connections that fail TLS negotiation are rejected.
At rest. Application databases, blob storage (call recordings, document attachments), and backups are encrypted at rest using AES-256. Encryption keys are managed by Microsoft Azure with platform-managed key rotation.
Secrets. Credentials for connected systems (CRM API keys, OAuth tokens, IMAP/SMTP passwords) are stored in an opaque credential store, encrypted at rest, and only decrypted at the moment they are needed to authenticate against the upstream provider.
Access control
Customer-facing. Authentication is handled by our own identity service. Within your tenant, access to features and data is governed by a granular permission system: each API endpoint is gated by a named permission, and roles bundle permissions for common job functions.
Internal. Production access is limited to a small number of named engineers. All production access requires a separate authenticated session with multi-factor authentication. We do not use shared credentials. Access to customer data in production is logged and reviewed.
Least privilege. Service-to-service authentication uses scoped credentials. AI agents operate under per-tenant tool permissions: an agent can only call the tools and reach the data it has been explicitly granted.
Monitoring and logging
Application logs. Every request, agent step, tool call, and channel event is captured in structured logs. Logs include the tenant identifier, the actor (user or agent), and a correlation identifier so we can trace a single user action through the entire stack.
Security logs. Authentication events, permission decisions, credential access, and tenant boundary checks are retained for 12 months for incident investigation and Australian Privacy Principle 11 compliance.
Anomaly detection. We monitor for unusual patterns: spikes in outbound call volume, off-hours admin actions, failed authentication clusters, and unexpected cross-tenant access attempts. Suspected incidents page on-call engineering.
Incident response and breach notification
Internal response. When we detect or suspect a security incident, an on-call engineer triages within one hour, contains the issue, and escalates to leadership. We preserve evidence (logs, snapshots) for forensic review.
Eligible data breach assessment. If we have grounds to suspect an eligible data breach under Part IIIC of the Privacy Act 1988 (Cth), we complete a formal assessment within 30 days of becoming aware. Where the assessment confirms an eligible data breach, we notify the Office of the Australian Information Commissioner (OAIC) and affected individuals, including a description of the breach, the kinds of information involved, and recommended steps to protect themselves.
Ransomware reporting. Where the 72-hour ransomware payment reporting obligation applies, we comply.
Customer notification. If your tenant is involved in an incident, we notify you directly. We do not wait for regulatory deadlines to tell you what happened.
Sub-processors
The Service relies on the following third parties to deliver core functionality. Each is bound by a data processing agreement that requires equivalent protections to our own.
| Provider | Purpose | Region |
|---|---|---|
| Microsoft Azure | Application hosting, primary databases, blob storage, key management | Australia East (Sydney), Australia Southeast (Melbourne) |
| Amazon Web Services | Selected supporting infrastructure and observability tooling | United States |
| OpenAI | Large language model inference; real-time voice (speech in, speech out) | United States |
| Anthropic | Large language model inference (Claude family) | United States |
| Selected language model inference; Workspace integrations (Gmail, Calendar, Drive) where you connect them | United States | |
| Twilio | Inbound and outbound voice telephony, SMS messaging, real-time media streams | United States, regional points of presence |
| Stripe | Subscription billing and payment processing | United States, with regional acquiring partners |
We will give you at least 30 days notice before adding a new sub-processor that processes Customer Data. If you object to a new sub-processor, your remedy is to terminate your subscription before that sub-processor begins processing your data.
Compliance posture
Australian Privacy Principles. The platform and our internal practices are designed against the Australian Privacy Principles (APP 1 to 13). Our handling of personal information, automated decision-making, cross-border disclosure, security, and access and correction rights is described in our Privacy Policy.
GDPR and CCPA. We address core GDPR and CCPA obligations: lawful basis, transparency, data subject rights, sub-processor disclosure, cross-border transfer mechanisms, and the right to opt out of automated decision-making. We are not a controller for the personal information of your end customers; you are. We act as a processor on your behalf.
Certifications. We do not hold SOC 2 Type II or ISO 27001 certification at this time. We treat the controls underlying those frameworks as our internal target, and we publish what we actually do here so you can make an informed decision.
EU AI Act. Where the EU AI Act applies to your use of the Service, we provide the technical documentation and transparency information required to support your obligations as the deployer of the AI system.
Customer responsibilities
Mr Vero shares the security responsibility with you. The platform is hardened, but several controls only work if you do your part.
Consent and compliance. You are responsible for obtaining the consents required by law before your AI agents call, message, or record anyone. This includes call-recording consent, AI disclosure (where required), and the prior express written consent rules for marketing communications under the TCPA, the Spam Act 2003, GDPR/PECR, and CASL.
Do-not-call register. You are responsible for maintaining and honouring opt-out requests within the timeframes required by the law in each jurisdiction your contacts are in.
Account hygiene. Use unique credentials, enable multi-factor authentication, and revoke access promptly when staff leave. We give you the controls; using them is on you.
Connected systems. AI agents can modify records in CRMs, calendars, email systems, and other tools you authorise. Maintain independent backups of any system that holds data you cannot afford to lose.
Monitoring agent behaviour. Review call transcripts, message logs, and data changes regularly. AI agents are autonomous, not supervised. Catching off-pattern behaviour early is a control only you can exercise.
Reporting a security concern
If you believe you have found a security vulnerability in the Mr Vero platform, or you suspect your tenant has been involved in a security incident, please contact us through our contact channel and request a security briefing. We acknowledge security reports within one business day and respond substantively within five.
We will not pursue legal action against researchers acting in good faith who report vulnerabilities responsibly, do not access more data than is necessary to demonstrate the issue, and do not disrupt other customers.
Last updated: 29 April 2026
Maintained by: Teklabs Digital Pty Ltd, Queensland, Australia. Mr Vero is a product of Teklabs Digital Pty Ltd.