Security Policy · v2.3 · Updated July 29, 2026

Security by design, from your first call to your millionth.

hiroi protects the security, availability, and confidentiality of every call, transcript, contact record, and integration secret. Our controls are designed to align with SOC 2 Trust Service Criteria and to support your GDPR, TCPA, and CAN-SPAM compliance. We have not completed a SOC 2 audit — what that means.

AES-256 at rest TLS 1.3 in transit 72-hour breach notification
Aligned withIndustry standards & frameworks
SOC 2 Type IIControls aligned · not yet audited
GDPREU / UK data subject rights
TCPATechnical safeguards
AES-256Encryption at rest
Four pillars

Defense in depth across every layer of the stack.

No single control protects your data. We run layered controls at the infrastructure, application, data, and operational layers — with continuous monitoring and audit trails across all four.

Infrastructure
Containerized deploys, network segmentation, and TLS termination at the edge. Cloudflare WAF + DDoS protection (SaaS) upstream of everything.
  • Azure Container Apps
  • US East 2 region
  • Cloudflare WAF (SaaS)
Application
Passkeys, 2FA, session-based auth, and org-scoped RBAC. CSRF and XSS controls on every state-changing request.
  • OAuth + Passkeys
  • Org-scoped RBAC
  • Redis rate limits
Data
AES-256 at rest, TLS 1.3 in transit. Call audio is never stored. Secrets hashed, never logged, never in code.
  • AES-256 at rest
  • TLS 1.3 preferred
  • Encrypted backups
Operations
Automated alerting, incident response playbook, 72-hour breach notification, and responsible disclosure for security researchers.
  • 72h notification
  • Configurable retention
  • Responsible disclosure
Security architecture
EdgeTLS 1.3
Cloudflare CDN + WAF (SaaS)DDoS
ApplicationContainer secrets
Container AppsFlask
ACS WebhooksHMAC
DataAES-256
Azure SQL DatabaseAzure
Blob StorageArchives
Architecture

Every tier isolated. Every link encrypted.

SaaS requests enter through Cloudflare, terminating TLS at the edge, before reaching a containerized Flask app running on Azure Container Apps. The database and telephony webhooks sit behind their own network boundary — no direct public exposure.

  • Network segmentation between application, database, telephony, and cache layers, with database access restricted by firewall to the application.
  • Authenticated telephony callbacks. ACS webhooks carry a shared secret checked in constant time before any handler runs — and fail closed if it is unset. Media streams and audio URLs are HMAC-signed per call.
  • Zero secrets in code. API keys, DB strings, OAuth tokens — all in Azure Container Apps secrets.
  • Point-in-time recovery on Azure SQL Database, rapid container rollback, and durable campaign state after crash.
Data handling

How we classify and handle every piece of data.

Every field, record, and file in hiroi falls into one of four classifications — with handling rules that are enforced in code, not just policy.

ClassificationExamplesHandling
Confidential API keys, server secrets, 2FA secrets, ACS connection strings Encrypted or hashed at rest. Never logged, never exposed client-side. PBKDF2-SHA256 for API keys; Fernet encryption for 2FA.
Private Email addresses, phone numbers, call transcripts, SMS content, conversation transcripts Access-controlled by organization membership. Retention limits enforced. Permanently deleted (not archived) at end of retention.
Internal Agent configurations, campaign settings, aggregate analytics Standard org-level access controls. IDOR prevention via JOIN queries requiring org membership.
Public Documentation, widget embed code, legal policies No restrictions. Published openly on hiroi.ai.
Responsible disclosure

Found a security vulnerability? Let us know.

We welcome reports of genuine security vulnerabilities from researchers acting in good faith. We do not operate a paid bug bounty program and do not compensate reporters, but we review every legitimate report, fix verified issues promptly, and credit researchers who request it.

Out of scope: missing CAA / SPF / DMARC records, missing security headers without a working exploit, scanner output without a proof of concept, and findings on third-party services we use (please report those upstream).

Email security@hiroi.ai Best-effort response · no paid bounty
Full policy

Security Policy — detailed controls

01Overview

hiroi is committed to maintaining the security, availability, and confidentiality of the hiroi omni-channel AI agent platform and the data it processes. This includes account data, contact records, call transcripts, SMS content, email campaigns, and Microsoft 365 integration data. Our security controls are designed to align with SOC 2 Trust Service Criteria.

02Infrastructure security

2.1 Hosting

  • Containerized deployment using Docker on Azure Container Apps for isolation and reproducibility
  • Application runs behind Cloudflare CDN (SaaS) with TLS termination and DDoS protection
  • Network segmentation between application, database (Azure SQL Database), telephony (ACS), and cache layers
  • Infrastructure hosted in Azure US East 2 region

2.2 Network security

  • All external traffic encrypted with TLS 1.2 or higher (TLS 1.3 preferred)
  • Content Security Policy (CSP) headers enforced
  • HTTP Strict Transport Security (HSTS) enabled
  • Cloudflare WAF (SaaS) for application-layer attack prevention

2.3 Database security

  • Azure SQL Database with authentication required for all connections
  • Database accessible only from the application network
  • Automated encrypted backups with point-in-time recovery
  • Connection strings stored in Azure Container Apps environment secrets, never in code

2.4 Telephony security

  • Azure Communication Services (ACS) for all voice calls and SMS
  • Inbound ACS Event Grid webhooks authenticated with a shared secret compared in constant time, failing closed when the secret is not configured
  • Media-streaming WebSocket and audio playback URLs authenticated with per-call HMAC signatures
  • Call audio is not recorded or stored; transcripts are stored under the database's encryption at rest, with access restricted by organization membership

03Application security

3.1 Authentication

  • Microsoft OAuth 2.0 (Entra ID): Secure enterprise authentication
  • Passkeys (WebAuthn): Phishing-resistant passwordless authentication
  • Magic links: Time-limited, single-use email tokens
  • Two-factor (TOTP): Second-factor authentication support
  • Sessions managed server-side with HttpOnly, Secure, SameSite cookie attributes

3.2 Authorization

  • Role-based access control (user, admin, organization member)
  • Resource-level authorization (IDOR prevention via JOIN queries requiring org membership)
  • API key scoping (widget-specific, non-transferable)
  • Organization-level data isolation

3.3 Input validation

  • Server-side validation on all inputs
  • Parameterized database queries (SQL injection prevention)
  • CSP headers (XSS prevention)
  • CSRF protection on all state-changing operations
  • Webhook payload signature verification before processing

3.4 Rate limiting

  • Rate limiting across the API — a default limit on every endpoint, tighter explicit limits on sensitive ones, backed by Redis in production so limits hold across workers
  • Per-user and per-IP rate limits
  • Graduated limits for authentication endpoints
  • Widget chat and calling endpoints rate-limited per visitor/caller

04Data security

4.1 Encryption

  • In transit: TLS 1.2+ (TLS 1.3 preferred) for all communications
  • At rest: AES-256 encryption for database storage (provided by Azure SQL TDE)
  • Call transcripts: Stored in Azure SQL under the same AES-256 Transparent Data Encryption as all other application data; call audio is not persisted
  • Secrets: API keys hashed with PBKDF2-SHA256; OAuth, integration, and 2FA secrets encrypted at rest with Fernet
  • Backups: Database backups encrypted at rest using provider-managed keys

4.2 Access controls

  • Principle of least privilege for all system components
  • No shared accounts or credentials
  • API keys generated with sufficient entropy
  • Server secrets never exposed to client-side code

05Widget security

The embeddable chat widget supports two authentication modes:

  • Domain safelist: Origin header validation with exact domain matching
  • Session signed: HMAC-SHA256 signed tokens with configurable TTL

Neither mode exposes API keys or secrets in the browser. Signed tokens are site-specific and expire.

06Telephony & messaging

  • All inbound ACS Event Grid call events authenticated with a shared secret before any handler runs, failing closed if the secret is unset; per-call callbacks carry an additional call-scoped secret
  • A2P 10DLC registration required for US SMS traffic
  • SMS content never logged in plaintext in application logs
  • Opt-out keywords (STOP, UNSUBSCRIBE) processed automatically and irreversibly
  • Provisioned phone numbers are organization-scoped

07Operational security

7.1 Monitoring and logging

  • Comprehensive activity logging for all user and AI agent actions
  • Security event logging (auth failures, unusual activity)
  • Campaign and telephony logs for compliance audit
  • Activity logs retained for 2 years, then permanently deleted by an automated daily job; entries that outlive the account they relate to are retained without directly identifying personal data

7.2 Incident response

01 · Detect
Automated monitoring
Anomaly alerts across auth, API, and telephony layers.
02 · Contain
Isolate affected systems
Suspend accounts, revoke tokens, cut off lateral paths.
03 · Investigate
Root cause analysis
Timeline reconstruction from audit logs and metrics.
04 · Notify
72-hour breach window
Affected users notified within 72 hours of confirmed breach.
05 · Remediate
Patch & counter
Fix deployment with countermeasures and regression tests.
06 · Review
Post-incident
Process improvement and playbook updates.

7.3 Vulnerability management

  • Dependencies monitored for known vulnerabilities via automated scanning
  • Security patches applied promptly, prioritized by severity
  • Responsible disclosure program for external researchers
  • We do not currently commission third-party penetration tests and do not operate a paid bug bounty program

08Retention & disposal

Data is retained according to our Privacy Policy retention schedule. When data reaches end of retention:

  • Personal data is permanently deleted or anonymized — not archived
  • Call transcripts are securely deleted from storage
  • Backup copies are removed within the backup rotation cycle
  • Deletion is logged in the audit trail

09Business continuity

  • Automated database backups with point-in-time recovery
  • Container-based deployment enables rapid recovery and rollback
  • Cloudflare CDN (SaaS) provides geographic redundancy for edge traffic
  • Campaign state is durable: paused campaigns resume from last completed step after recovery

10Compliance alignment

10.1 SOC 2

Our controls are designed to align with AICPA SOC 2 Trust Service Criteria across Security, Availability, Processing Integrity, Confidentiality, and Privacy.

What "aligned" means, and what it does not. hiroi has not completed a SOC 2 Type I or Type II audit, and no SOC 2 report exists or can be provided. We have not commissioned a third-party penetration test, and we do not hold ISO 27001, PCI-DSS, FedRAMP, or HIPAA certification. The certifications named elsewhere on this page belong to our infrastructure providers — Microsoft Azure, Stripe, Cloudflare — and cover their services, not ours. This page describes controls we actually operate; it is not an attestation by an independent auditor. We will say so here if that changes.

10.2 GDPR

Data processing agreements with sub-processors; data subject rights (access, portability, erasure, restriction, objection); consent management; 72-hour breach notification to controllers. Our Data Processing Agreement incorporates the EU Standard Contractual Clauses with completed Annex I and Annex II, plus the UK Addendum and the Swiss amendments.

10.3 TCPA / CAN-SPAM

Automatic opt-out processing for SMS; do-not-contact flags that cannot be overridden by campaigns; unsubscribe link support; scheduling controls to prevent calls/SMS during restricted hours. These are technical safeguards that support your compliance — they do not make your use of the platform compliant, and we do not scrub contact lists against the National DNC Registry.

10.4 HIPAA

The hosted hiroi cloud is not offered as a HIPAA-compliant service, and we do not sign Business Associate Agreements for it — please do not send protected health information through it. Self-hosted Enterprise deployments run inside the customer's own Azure tenant, where the customer's own Azure BAA covers the underlying infrastructure; a BAA with hiroi for an Enterprise engagement is scoped case by case during contracting. Azure AI Content Safety screens for hate, sexual, self-harm, and violent content and for prompt injection — it is not a PHI or PII detector.

11Reporting vulnerabilities

If you discover a security vulnerability, please report it to security@hiroi.ai. We will:

  • Review every legitimate report and respond when triage is complete
  • Fix verified vulnerabilities promptly, prioritized by severity
  • Credit researchers who request acknowledgment
  • Not take legal action against good-faith security researchers acting within responsible disclosure guidelines

Out of scope: informational DNS/email hygiene findings (missing CAA, SPF strictness, DMARC policy), missing security headers without a working exploit, scanner output without a proof of concept, social engineering, physical attacks, and issues in third-party services we use. We do not operate a paid bug bounty program and do not compensate reporters.

12Contact

For security-related inquiries:

TrentApps LLC (d/b/a hiroi) — Security
117 S Lexington St, Ste 100
Harrisonville, MO 64701, United States
Email: security@hiroi.ai