Security Policy

Effective Date: October 1, 2025

HaileyAI Corporation (“HaileyAI,” “we,” “us,” or “our”) is committed to protecting the confidentiality, integrity, and availability of customer data. This Security Policy provides an overview of the practices, controls, and standards implemented across our production systems to safeguard information processed through our services.

1. Governance and Oversight

HaileyAI maintains a formal security program overseen by designated security leadership. Our policies and practices are reviewed and updated at least annually to ensure alignment with industry standards, evolving regulations, and customer needs. All personnel with access to customer data receive regular training on data security, privacy, and secure development practices. Security policies, system documentation, and audit findings are maintained under version control and reviewed by executive leadership.

2. System Architecture

HaileyAI operates as a serverless orchestration layer deployed within secure, U.S.-based cloud infrastructure. Customer data is never copied or replicated to HaileyAI-owned infrastructure. Our architecture consists of isolated, purpose-built functions that handle specific workloads (data lookups, authentication, analytics, call processing, alerting) with no shared-state dependencies between functions. All components are subject to enterprise-grade infrastructure security controls in addition to HaileyAI’s application-layer protections.

3. Authentication and Authorization

3.1 Asymmetric JWT (ES256)

HaileyAI uses ES256 (ECDSA P-256, SHA-256) asymmetric signing for all authentication tokens. The private key is used exclusively by the authentication service for signing; all other services verify tokens using the public key only. The algorithm is pinned in the verifier — any token presenting a different algorithm is rejected. This eliminates the shared-secret risks associated with symmetric signing schemes.

Access tokens have a short time-to-live and are held in application memory only — never stored in browser storage (localStorage, sessionStorage, or cookies accessible to JavaScript).

3.2 HttpOnly Cookie Architecture

Refresh tokens are delivered as HttpOnly, Secure, SameSite=Strict cookies scoped to the authentication endpoint. They are never accessible to client-side JavaScript. User roles and session state are held in memory only and are not visible in browser developer tools. A frontend timer drives silent token refresh before access token expiry, ensuring seamless session continuity without exposing credentials.

3.3 Refresh Token Rotation with Reuse Detection

Every refresh token is single-use. Each token carries a unique identifier that is tracked server-side. When a refresh token is consumed, its identifier is marked as used. If a previously consumed token is presented again — indicating possible token theft or replay — all active sessions for the affected user are immediately terminated. Expired tokens are cleaned automatically by a daily scheduled process.

3.4 Password Security

Passwords are stored using PBKDF2 with SHA-512, high iteration counts, and a unique random salt per password. New and changed passwords are subject to complexity requirements (uppercase, lowercase, digit, and special character).

3.5 Rate Limiting and Anti-Enumeration

Login endpoints enforce rate limiting with configurable attempt thresholds per IP and username combination, followed by timed lockout. Lockout events are logged for audit purposes. The same error message is returned for invalid usernames and incorrect passwords, preventing user enumeration.

3.6 API Authentication

External integrations authenticate via API key headers with timing-safe comparison. Webhook endpoints use HMAC-based authentication with timing-safe verification. Audio recording access is protected by HMAC-SHA256 signed URLs with time-bound expiry.

4. Input Validation and Injection Prevention

Every user-supplied input is validated server-side before processing. Client-side validation is treated as a user experience convenience only and is never relied upon for security. HaileyAI employs purpose-built validation and sanitization functions for each input type, including text fields, phone numbers, filter parameters, storage keys, and database query literals. All user-supplied strings are escaped before interpolation into database queries to prevent injection attacks. No dynamic code execution (eval, exec, spawn, or equivalent) exists anywhere in the codebase.

5. Security Headers

All API responses include the following security headers: HTTP Strict Transport Security (HSTS) with a one-year duration, includeSubDomains, and preload; X-Content-Type-Options: nosniff; X-Frame-Options: DENY; Referrer-Policy: strict-origin-when-cross-origin; and Cross-Origin-Opener-Policy: same-origin. Deprecated headers (such as X-XSS-Protection) have been removed to avoid introducing browser-side vulnerabilities.

The dashboard enforces a strict Content Security Policy (CSP) with no unsafe-inline for scripts. External scripts are pinned to specific versions and verified with Subresource Integrity (SRI) hashes. Cross-origin requests are validated against an explicit origin allowlist; unauthorized origins are rejected.

6. SSRF Protection

Outbound requests from proxy functions are validated against a strict domain allowlist before execution. Protocol is enforced to HTTPS only, and hostnames are matched against the allowlist. Invalid URLs or disallowed domains are rejected and logged. All other outbound fetch targets are sourced from environment variables, never from user input.

7. Secrets Management

All secrets, API keys, and signing keys are stored in encrypted application settings — never hardcoded in source code. Rotation schedules are enforced on a regular cadence for all credential types. Migration to a centralized key vault with audit logging is planned.

8. Logging and Monitoring

HaileyAI logs all security-relevant events, including login success and failure, token refresh, refresh token reuse (token theft indicator), logout, CSRF origin blocks, rate limit lockouts, invalid JWT presentations, insufficient role access, SSRF blocks, input validation failures, oversized payload rejections, and administrative actions such as user creation and configuration changes.

Sensitive data is never logged: passwords, tokens, API keys, secrets, and full credentials are excluded from all log output. Log entries include structured fields: ISO 8601 UTC timestamp, username, sanitized client IP, action, outcome, and reason code.

9. Data Protection

Encryption in transit: TLS 1.2 or higher on all endpoints. Encryption at rest: AES-256 via platform-native storage encryption. Token signatures: ES256 ECDSA. Recording access: HMAC-SHA256 with time-bound expiry. Password storage: PBKDF2-SHA512 with high iteration counts.

Data residency: All customer data is stored and processed exclusively within the United States. HaileyAI does not transfer or host customer data outside the United States.

Data retention: Call records are retained for the duration of the engagement. Session tokens and rate limit records have short time-to-live values and are cleaned automatically. AI language model interactions are transient, and no plaintext customer data is retained in provider logs. Customer data is never used for third-party model training.

10. OWASP Top 10 Compliance

HaileyAI’s production systems have been assessed against the OWASP Top 10 (2021) framework. All categories have been addressed with specific controls:

Broken Access Control — JWT with role claims, resource-level validation, and administrative re-verification on sensitive operations. Cryptographic Failures — ES256 asymmetric signing, PBKDF2 with high iteration counts, timing-safe comparisons on all secret checks. Injection — Server-side input escaping for all database queries, strict sanitization for storage operations, no dynamic code execution. Insecure Design — Rate limiting, token reuse detection, anti-enumeration, password complexity enforcement. Security Misconfiguration — Strict CSP, comprehensive security headers, generic error responses with no internal detail leakage. Vulnerable Components — Pinned dependency versions with SRI verification, quarterly dependency audits. Authentication Failures — Short-lived tokens, HttpOnly cookies, server-side logout, account lockout. Software and Data Integrity — SRI on external scripts, HMAC verification on webhooks, deny-by-default authentication. Logging and Monitoring Failures — All authentication and security events logged with structured fields, no secrets in logs. Server-Side Request Forgery — Domain allowlist with protocol enforcement on all proxy functions.

11. Security Scanning and Baselines

HaileyAI maintains ongoing security scanning with the following baseline grades:

Web Application Security: A grade (headers, CSP, cookie security). SSL/TLS Configuration: A- grade (TLS 1.2/1.3; minor findings related to platform-managed cipher suites). Browser Best Practices: 92+ score (CSP and security best practices). Internal OWASP Audit: Clean (multi-run consistency verified).

Scans are re-run after each security hardening cycle to verify improvements and detect regressions.

12. Secure Deployment Practices

HaileyAI follows a deploy-then-activate pattern for security-sensitive features: new capabilities are deployed in an inactive state, gated behind configuration flags, and activated only after production verification. This enables real-environment validation without exposing live traffic to untested changes.

All deployments follow a sequential process with live log verification — each change is confirmed via production logs before proceeding to the next. No secrets are transmitted through chat, email, or other insecure channels; all secret handling is performed through secure shell sessions with file redirection.

13. Subprocessors

HaileyAI may engage carefully vetted subprocessors to support service delivery, including infrastructure hosting, voice processing, AI language model processing, and analytics. All subprocessors are contractually bound to security and confidentiality standards at least as rigorous as those maintained by HaileyAI. Data shared with subprocessors is encrypted and tokenized, and restricted to the minimum necessary for service fulfillment. HaileyAI does not permit customer data to be used for training third-party models. A current list of subprocessors is available to customers upon request.

14. Business Continuity and Disaster Recovery

HaileyAI infrastructure is designed for resiliency with redundant systems, automated warm-up processes, and secure backups. Recovery procedures are maintained to minimize data loss and service interruption. Recovery time objectives and data retention periods may vary by customer contract.

15. Incident Response

HaileyAI maintains a formal incident response process covering detection, confirmation, notification, and remediation. Security events are detected via automated log monitoring. Confirmed security incidents are reported to affected customers within the timeframes specified in the applicable contract. Routine events such as blocked attacks, failed login attempts, and automated scans are not classified as security incidents.

For incident reporting or security concerns, contact: security@gohailey.ai

16. Compliance

HaileyAI complies with applicable United States federal and state privacy, data protection, telecommunications, and AI-specific laws, including the Telephone Consumer Protection Act (TCPA), the California Consumer Privacy Act (CCPA), the California Privacy Rights Act (CPRA), and other applicable frameworks. HaileyAI will continue to update its policies and practices to align with evolving legal requirements.

17. Questions or Concerns

If you have questions about HaileyAI’s security practices, wish to request our current subprocessor list, or need to report a security concern, you may contact us at: security@gohailey.ai