1. Security approach
DIRI AI uses risk-based controls intended to protect confidentiality, integrity and availability. Security is shared: DIRI AI protects the service and configured infrastructure; customers protect their users, devices, credentials, content choices and administrator decisions.
This overview describes the control design. It does not claim ISO 27001, SOC 2, PCI DSS certification for DIRI AI, penetration-test coverage or uninterrupted service. Provider certifications do not become DIRI AI certifications.
2. Identity, access and tenant controls
The controls include:
- unique user identities and protected production session cookies;
- server-side, role-based and tenant-scoped authorisation;
- administrator-managed invitations, roles and member removal;
- least-privilege access to production systems and provider accounts;
- segregated non-production and production environments and configuration;
- rate limits and anti-abuse controls; and
- audit records for security-relevant administrator and subscription events.
DIRI AI tests cross-tenant access, reviews privileges and verifies account-recovery controls. Multi-factor authentication should be enabled on provider and privileged accounts and made available to customers where supported.
3. Data protection
Supported traffic uses TLS in transit. Managed providers encrypt stored data at rest using their standard controls, with provider and transfer information in the Subprocessor List. Secrets must be held outside source code and ordinary logs. Payment card entry is delegated to the payment provider so DIRI AI does not need the full card number.
Voice recording storage is off by default. Telemetry must be sanitised and Customer Content excluded from routine logs where feasible. Production debugging must be time-limited, authorised and recorded.
4. Application security
DIRI AI uses change review, automated tests, dependency and secret checks, trusted-ingress controls and signed provider callbacks to protect application changes and external integrations.
Provider access, signup and billing are protected by applicable access, legal, billing and security controls. Those controls are not weakened merely to make a feature available.
5. Monitoring and incident response
The service uses sanitised application error telemetry, operational metrics, audit logs and provider events. DIRI AI reviews monitoring coverage, quota, alert delivery and operational ownership after material changes. Internal metrics are not marketing analytics.
Suspected incidents are triaged, contained, investigated, remediated and documented under the Incident Notification Policy. Personal-data breach obligations are assessed separately from ordinary availability events.
6. Availability, backups and recovery
The architecture uses managed hosting, database, cache/queue and object-storage providers. DIRI AI tests backup, restore, queue retry and data-lifecycle configuration. No recovery-time or recovery-point objective is promised in standard plans until formally measured and contracted.
Standard plans have no percentage uptime SLA. This does not limit mandatory consumer conformity or remedy rights.
7. Provider risk
Providers are reviewed for purpose, access, contractual terms, security information, processing locations, transfer mechanism, retention and deletion. Only the minimum necessary data is sent. The Subprocessor List identifies providers used for covered functions.
8. Customer responsibilities
Customers must:
- use strong unique credentials and multi-factor authentication where available;
- keep devices, browsers and integrations updated;
- grant the minimum roles, review membership and remove leavers promptly;
- avoid uploading unnecessary sensitive or real-client data;
- verify exports before account closure and protect downloaded files;
- configure lawful retention and employee notices; and
- promptly report suspected compromise without publicly disclosing exploitable detail.
9. Vulnerability reporting
Send a concise report to security@diriai.com with the affected route, reproduction steps, impact and a safe proof. Do not access another customer's data, disrupt service, use social engineering, exfiltrate data or demand payment. Stop testing after confirming the issue and allow reasonable time for investigation.
No public bug bounty or broad safe-harbour programme exists unless separately published. Good-faith reports will be handled responsibly, but this overview does not authorise conduct otherwise unlawful.
10. Contact and version
Security reports: security@diriai.com. Privacy incidents: privacy@diriai.com. Version: 1.2.0. Date: 30 August 2026.