Skip to main content

​
Overview

Voxworks Technologies Pty Ltd is an Australian company, built and operated for Australian businesses, and subject to Australian law — including the Privacy Act 1988 and the Australian Privacy Principles. This page summarises the security architecture behind the platform: where your data lives, how it’s encrypted, how access is controlled, and how the platform is hardened against the attack classes specific to an AI voice product. It’s written to support your own vendor security assessment; deeper detail on specific topics lives on the pages linked throughout and in Next Steps.

​
Data residency

Voxworks is built around Australian data residency:
  • Australian jurisdiction — Voxworks Technologies Pty Ltd is incorporated and headquartered in Australia. Your account, your callers’ data, and your organisation’s use of the platform are governed by Australian law, not a foreign jurisdiction.
  • Australian infrastructure — Platform storage, including call recordings and other files you generate on Voxworks, is hosted in Amazon Web Services’ Sydney (ap-southeast-2) region.
  • Australian operating calendar — Time-sensitive platform behaviour, such as batch call scheduling, runs against Australian time and public holidays. See Batch Scheduling for how this shapes when your calls actually dial.

​
Encryption in transit and at rest

In transit. All traffic to and from Voxworks — the app, the API, and call signalling — is encrypted in transit using TLS. At rest, third-party connections you authorise — such as connecting a CRM, calendar, or other integration — have their access tokens and API keys protected with AWS Key Management Service (KMS) envelope encryption. Each secret is encrypted individually and bound to your team and to the specific integration and field it belongs to, so a piece of ciphertext can’t be decrypted against a different team or swapped onto a different credential. Plaintext is only ever held in memory for the moment it’s needed to make the authorised call to that third party — it’s never written back to storage or logs. The underlying database storage, including backups, is encrypted at rest by the managed database infrastructure Voxworks runs on.

​
Recording and file storage security

Call recordings and other files you generate on Voxworks — such as profile images — are stored in private cloud storage in AWS’s Sydney region. The storage buckets are not publicly listable or browsable, and direct requests to them are rejected; a file can only be reached through the Voxworks app or an authorised API request, such as a time-limited link generated for your signed-in session. See Call Recording & Consent for exactly how recording access is authorised, disclosed to callers, and audited. Files you upload directly, like a profile image, go through server-side validation before they’re accepted: checked against an allow-list of accepted formats, verified against the file’s actual content rather than just its claimed type, capped in size, and rate-limited per user. Every upload and deletion is logged.

​
Team-based access control

Every team’s data — contacts, calls, scripts, credentials, and everything else in the platform — is isolated at the database level using row-level security (RLS) policies, not just application-layer checks. A query for one team’s data is scoped to that team before it ever reaches the application, so a bug in a feature’s code can’t leak another team’s records. Within a team, what an individual member can see and do is governed by that member’s role — see Roles & Permissions. Sign-in itself is protected by Multi-Factor Authentication, and destructive account actions are additionally gated behind an email one-time code.

​
Hardening against SSRF and prompt injection

Two attack classes are specific to a platform that connects to external systems and speaks generated language to callers, and both are hardened at the platform level:
  • Server-side request forgery (SSRF). Whenever your automations make an outbound HTTP request — a webhook trigger fetching data, or an HTTP step posting somewhere — the destination is resolved and validated before Voxworks connects to it. Requests that resolve to private or reserved IP ranges, or to known cloud metadata hosts, are blocked. This stops a malicious or misconfigured URL from being used to reach internal infrastructure instead of its intended destination.
  • Prompt injection and jailbreak attempts. Every response your agent is about to speak is screened for signs that a caller is trying to manipulate it — overriding its instructions, extracting its configuration, or talking it into unsafe territory. This safety check runs alongside every other response check and takes priority over all of them: a detected violation means the risky content is discarded before it ever reaches the caller, and the caller hears a short, fixed safe response instead. See Compliance Policies for how your own script-level rules layer on top of this baseline protection.

​
Availability and incident response

Voxworks targets 99.95%+ uptime for the platform. A contractual SLA guarantee with custom terms is available on Enterprise plans — see Plans & Pricing for what’s included at each tier. As an entity regulated under the Australian Privacy Act, Voxworks is subject to the Notifiable Data Breaches (NDB) scheme: eligible data breaches are assessed and, where the scheme requires it, affected individuals and the Office of the Australian Information Commissioner (OAIC) are notified. Voxworks also aligns its security practices with ISO 27001, the international standard for information security management systems.

​
Requesting more detail

This page is a summary for your own due-diligence process, not a substitute for a signed security questionnaire, data processing agreement, or legal advice. If your vendor assessment needs a completed questionnaire, a data-flow diagram, or documentation under NDA, speak to the Voxworks team directly.

​
Next Steps