Security Posture

Security At A Glance

• Nonce-based Content Security Policy (CSP). No unsafe-inline in script-src.
• Single Content-Security-Policy header, set in middleware per request.
• Strict transport security (HSTS preload) and modern TLS (TLS 1.3 supported).
• Security headers: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
• Temporary session model: a call-sidecar session is created per call and joined with a 6-digit code.
• Minimal collection: designed to capture only what is needed for in-call alignment while the session is active.

Data Lifecycle

1. Agent creates a session through the agent workflow. Caller joins via a 6-digit code.
2. During active sessions, chat/messages, acknowledgements, and optional uploads are stored to provide real-time sync.
3. Session access is blocked when status is closed/ended, when blocked is set, or when expiry timestamps are reached.
4. Explicit end flow removes the session document and message payloads, and scheduled cleanup jobs remove stale session data and storage prefixes by cutoff.

No background profiling, no selling data, no ad retargeting.

Web Platform Security

• CSP nonce is generated per request in middleware and passed via request headers.
• GA and JSON-LD scripts are nonce-bound; inline script execution is not broadly allowed.
• Static security headers are enforced in Next.js config.
• Single CSP header is emitted to avoid policy ambiguity from duplicates.
• HTTPS is enforced with HSTS preload and encrypted transport.

Application Controls

• Agent session creation requires authenticated org membership checks.
• Caller join path validates 6-digit code format, code/session status, and expiration before access is granted.
• Caller claim is a one-time bind to anonymous auth identity using callerGate and callerAnonUid controls in rules.
• Caller message writes are privacy-gated; acknowledgement flow can be required before standard chat.
• Upload controls enforce feature flags and file constraints (type and size) before object write.

Request-rate abuse throttling is in progress. Current hardening prioritizes auth boundaries, session state checks, and strict rule-based data access.

Data Storage

EOV6 uses Firestore for session state and message synchronization, and Firebase Storage for optional in-session file uploads.

• Firestore: sessions, sessionCodes, org configuration, and acknowledgement state.
• Storage: upload objects scoped by session code prefix.
• Cleanup behavior combines explicit end actions and scheduled deletion jobs for stale session data.

For full control mappings and implementation detail, contact us for full controls documentation.

Privacy & Compliance Posture

• EOV6 is designed as a temporary call-sidecar, not a long-term CRM archive.
• Data minimization and session-scoped handling are default design constraints.
• This page does not claim certifications or attestations that are not currently published.
• Procurement and legal teams can request current control documentation through the contact channel.

Responsible Disclosure

Send security reports to hello@eov6.com with the subject line Security report.

• Include reproduction steps, affected route(s), and expected vs. observed behavior.
• Do not access or retain customer data beyond what is needed to report the issue.
• Target response windows: acknowledgement within 2 business days, status update within 5 business days.

Status & Roadmap

• Rules hardening and flow-level rule tests continue across caller and agent paths.
• Aggregated operational audit/reporting surfaces are in progress.
• Additional abuse-rate controls are in progress.