Security Statement

Administrator access is protected by Supabase Auth and httpOnly session cookies.

Dashboard routes are protected, and application queries are designed around tenant-scoped company access.

Administrative actions such as campaign preparation, regeneration, editing, approval, exclusion, launch, export, feedback review, and settings changes are handled through server-side routes.

Horus-i separates campaign lifecycle, simulation behavior lifecycle, generation metadata, and delivery lifecycle instead of overloading a single status field.

Employee and campaign data is used only for authorized awareness workflows, reporting, coaching feedback, and operational safeguards.

Exports and dashboards are gated so previews, unsafe rows, excluded rows, failed deliveries, suppressed deliveries, bounced deliveries, and dry-run sends do not become reportable results.

People Data Labs enrichment runs behind a provider adapter boundary with safe outbound match parameters, request hashing, duplicate-call prevention, and per-record status tracking.

Raw enrichment provider payloads are restricted and must not reach prompts, generated content, Resend payloads, normal admin UI, logs, exports, or reporting.

A default-deny sanitizer permits only explicitly allowed professional fields and denies sensitive personal categories and unknown provider fields.

LLM generation uses a provider-neutral input boundary built from safe fields only, versioned prompt templates, output hashing, and structured validation.

Generated content is checked for required structure, unsafe content, sensitive content, and allowed tracking URLs before it can be reviewed or approved.

Generated and fallback simulation drafts are not approved by default. Approval is gated on valid, safe, non-excluded, draft-state content.

Resend delivery is server-side only and uses approved-content-only payloads with Horus-i tracking link replacement, safe tags/headers, and per-attempt idempotency keys.

Simulations move to sent only after Resend accepts the message or after explicit non-production dry-run acceptance.

Retries create new delivery attempts and do not overwrite prior attempts. Duplicate accepted sends and in-flight duplicate sends are blocked.

Resend webhooks are verified with a Svix-compatible signature check and stored idempotently.

Delivery state updates are mapped from provider events such as sent, delivered, delayed, failed, bounced, complained, and suppressed.

Resend open and click events are diagnostics only. Horus-i tracking routes remain the source of awareness behavior for reporting.

Operational audit events are redacted and store IDs, statuses, hashes, prompt versions, validation codes, fallback reasons, retry flags, and provider diagnostics.

Audit logs must not contain raw provider payloads, raw prompts, email content, secrets, or direct recipient emails.

Retention guidance covers restricted raw enrichment payloads, webhook diagnostics, and audit events so sensitive operational data can be kept only as long as needed.

Horus-i should be configured with verified sending domains, approved sender identities, provider secrets stored server-side, and environment-specific safeguards.

Customers should limit administrator access, review campaign content before launch, monitor delivery outcomes, and align use with internal security, privacy, and legal requirements.

Security issues should be reported through the support or administrative contact channel provided with your Horus-i account.