Trust & Security

01Our approach

Our security model is layered:

• Vendor-provided security — we build on infrastructure (hosting, AI model providers, telephony, payments) that maintains its own security certifications and audits. We choose vendors specifically for their security posture and contractual commitments. See our Subprocessors page for the full list.
• Operational practices — internal controls covering how we, the people, handle credentials, access, and incident response.
• AI-specific safeguards — measures specific to large language models and voice AI, including data-handling commitments and prompt-injection mitigations.

We treat security as an ongoing practice, not a one-time compliance exercise. As the studio grows, the controls scale up with it.

02Encryption

In transit

All connections to our services use TLS 1.2 or above. This covers client and end-user traffic to chatbot widgets, API calls between our systems and third-party services, and administrative access to backend systems. HTTPS is enforced; plaintext HTTP connections are rejected.

At rest

Data stored within our cloud hosting provider's infrastructure is encrypted at rest using AES-256 (or equivalent provider-managed encryption). This includes operational databases, file storage, and backup snapshots. Encryption keys are managed by the hosting provider's key management service.

Backups

Backups inherit the same at-rest encryption as primary storage and are retained on a defined schedule appropriate to each engagement. Backup access is restricted to the same access controls as primary data.

03Access & isolation

Principle of least privilege

Internal access to systems and client data is granted only to personnel who need it to perform their role. We do not maintain "everyone has access to everything" defaults. Access is reviewed when roles change.

Client data isolation

Each client deployment is logically isolated — credentials, configurations, conversation logs, and integration tokens for one client are not accessible to another client's deployment. Where shared infrastructure is used (which is typical of cloud-hosted services), tenant separation is maintained at the application and database layer.

Administrative access

Administrative access to client systems is documented and minimised. Where we maintain operational access (for example, to monitor performance or apply optimisations under our subscription), that access is governed by your Master Service Agreement and used only for the purposes set out in Section 8 of the MSA.

Credential management

We use a password manager for shared credentials. We do not share passwords through email, chat, or other plaintext channels. Where possible, we use scoped API keys rather than shared user accounts.

04Logging & monitoring

What we log

We log operational events necessary to run, secure and improve the platform:

• Access events (who accessed what, when)
• API errors and exceptions
• Conversation metadata (timestamps, message counts, routing decisions)
• Integration sync events and failures
• Performance and availability metrics

What we don't log

Where possible, we avoid logging the content of end-user conversations beyond what's needed to operate the system. Where conversation content is logged (for example, for client-facing analytics or improving agent quality), it's stored under the same access and encryption controls as other client data.

Retention

Operational logs are retained for a period proportionate to their purpose — generally 30 to 90 days for performance and debugging logs, longer for security-relevant logs (such as authentication events). Specific retention periods for client data are documented in each engagement's Statement of Work and our Privacy Policy.

Monitoring

We monitor for anomalies in access patterns, error rates, and integration health. Alerts route to the responsible personnel. We do not currently maintain 24/7 staffed security monitoring — that's an area we'll add as the studio grows.

05AI safety & data handling

No training on client data

We do not use client data, end-user conversations, or any data flowing through our systems to train AI models — our own or anyone else's. Our agreements with AI model providers (OpenAI, Anthropic, others — see Subprocessors) include contractual commitments that API content is not used to train their models under their standard API terms. We never use consumer-tier AI products (e.g., the ChatGPT or Claude.ai consumer apps) in client-facing capacity.

Prompt injection & abuse mitigation

We apply input sanitisation and prompt-construction practices designed to mitigate prompt injection attacks, attempts to extract sensitive information, and attempts to misuse client-facing agents. No mitigation is perfect — large language models are an evolving area — but we treat this as an ongoing engineering concern, not a solved problem.

Content filtering

Where AI agents we deploy interact with end users, we apply content filtering appropriate to the engagement — both at the model layer (using the provider's built-in safety measures) and through our own configuration (system prompts, refusal patterns, escalation pathways).

Human review & oversight

For high-consequence outputs, we strongly recommend keeping a human in the loop. Our AI systems are designed to qualify, route and book — not to make material decisions on behalf of clients. Where engagements involve outputs that could affect a person materially (financial, legal, safety), the system surfaces those for human review rather than acting unilaterally.

Hallucinations & accuracy

Large language models can produce inaccurate or fabricated outputs. We design conversation flows to ground responses in your provided knowledge base, to defer rather than guess when information isn't available, and to escalate when conversations exceed the agent's scope. End users interacting with AI agents we deploy are typically informed that they're speaking with an AI assistant.

06Authentication

Internal

Multi-factor authentication (MFA) is required on all administrative accounts used to access client systems, AI model providers, hosting infrastructure, and credential stores. We do not maintain shared user accounts where individual attribution is required.

Client-facing

Where we deploy administrative dashboards for clients, we support strong password policies and offer (or require, depending on the engagement) MFA. Session timeouts are configured to reasonable intervals. For client integrations where the client provides credentials (e.g., CRM API keys), we store those credentials in encrypted secrets management — never in plaintext, never in code repositories.

07Incident & breach response

We maintain a documented incident response process. If we become aware of an actual or suspected security incident affecting client systems or data:

Detection & containment

We act to contain the incident, preserve relevant logs and evidence, and assess the scope. The aim of the first phase is to stop further harm.

Assessment

We assess what data was affected, whether personal information was involved, and what (if any) harm to affected individuals is likely. For incidents involving Australian personal information, we operate within the 30-day assessment window required by the Notifiable Data Breaches (NDB) scheme under the Privacy Act 1988 (Cth).

Notification

Where an incident affects a client's data, we notify the affected client without undue delay — typically within 72 hours of confirming the incident's scope, sooner if practical. Where an eligible data breach under the NDB scheme is confirmed, we notify the Office of the Australian Information Commissioner (OAIC) and affected individuals as required by law. Where US state breach notification laws apply (California, Texas and others), we comply with the applicable notification timelines.

Post-incident

After containment and notification, we conduct a written post-incident review covering root cause, remediation, and what changes (if any) we'll make to prevent recurrence. Clients affected by an incident receive a copy of the relevant portion of that review.

What we ask of clients

If you become aware of an incident affecting systems we built for you — including credential compromises, unusual conversation patterns, or third-party access you didn't authorise — please contact us immediately at security@highflowai.com. Faster reporting on either side means faster containment.

08Audit posture & roadmap

What we have today

We rely on the security certifications and audit reports maintained by our subprocessors — most of whom hold SOC 2 Type II, ISO 27001, or equivalent attestations. These cover the underlying infrastructure on which our platform runs. We can share specific vendor attestations on request as part of client diligence.

What we don't have yet

We do not currently hold an independent SOC 2 Type II, ISO 27001, or equivalent certification of our own operations. For a studio of our size, the cost and time required for those certifications doesn't yet match the maturity of the operation — and we'd rather build a real security practice first than chase a certificate that signals more than it represents.

What we're working toward

As the studio grows and the operation justifies it, we expect to pursue formal certification. Our practical interim measure is annual internal security review — a documented walk-through of our controls, gaps, and remediation plan — which informs both our internal practice and the answers we give to client diligence questionnaires.

For enterprise prospects

If your procurement or security team needs more than this page provides — including specific vendor attestations, our internal security review, or a tailored security questionnaire response — contact security@highflowai.com and we'll work through it.

09Reporting a security issue

If you've discovered a security vulnerability, a suspected breach, or any behaviour that suggests our systems may be at risk, we want to know.

How to report

Email security@highflowai.com with as much detail as you can share — what you observed, when, how to reproduce it (if applicable), and any logs or screenshots. If the issue is sensitive, you can request encrypted communication and we'll arrange it.

What we commit to

• Acknowledge your report within 2 business days
• Provide a substantive response within 10 business days
• Keep you updated as we investigate and remediate
• Not pursue legal action against good-faith security research, provided the activity stays within reasonable bounds (no exfiltration of real data, no service disruption, no extortion)
• Credit you in any public communication about the issue if you'd like, or keep your involvement confidential if you prefer

We don't currently offer a paid bug bounty. We do appreciate every report.

10Contact us

For security questions, vendor diligence, or to report an issue: