Know what you submit, and what is retained.

Information you submit

Inputs can include an email subject/body, original .eml bytes, URLs, message-carried headers, attachment metadata, and—through an authorized receiver—SMTP client, envelope, and HELO facts. Account/profile information, organization membership, API usage, case records, and operational identifiers also support the service.

Derived records can contain normalized identities, domains, IPs, hashes, content summaries, model runs, decisions, campaign relationships, and signed evidence. Those fields can still be sensitive even when a lookup key is hashed.

How investigation data is used

The server parses the submitted evidence, evaluates available authentication and identity signals, extracts URL strings, enriches eligible infrastructure, correlates findings under policy, and saves the authorized result. Workspace campaign matching compares normalized entities with prior investigations in the same organization.

The documented model pipeline sends bounded subject/body text to MailGuard and extracted URL strings to Swift on the private AWS CPU inference service. These are pretrained classifiers, not a generative chat workflow or a new model trained by VeriTrustLab. Accepted original files are not exhaustively classified byte by byte.

Standalone detector/API usage records and saved email investigations are different data paths. Usage logging does not mean every direct model API call creates a dashboard investigation.

Infrastructure and configured service providers

The 12 October reference describes Vercel API orchestration and Supabase Auth/database/private Storage in Tokyo, with the model and SMTP runtimes on AWS in Mumbai. These are documented deployment locations, not a universal data-residency promise.

Eligible public domains/IPs can be sent to configured DNS, RDAP, IPinfo, or AbuseIPDB services for authentication, registration, infrastructure, and reputation context. Private/special/reserved IPs are not submitted to public geo/reputation providers. Provider outages and missing fields remain visible as coverage gaps.

Where pilot delivery is configured and authorized, the SMTP runtime imports raw messages through the Gmail API and uses a separate TLS relay path for the reporting group. Gmail credentials remain server-side; the documented runtime uses import and metadata scopes without runtime send/delete/body-reading permission. This is a scoped operator-managed configuration, not an automatic mailbox connection for every user.

Original files and derived evidence

Browser .eml intake reserves a tenant/user-bound upload, then sends original bytes directly to private Storage using an authorized short-lived URL. Analysis validates the stored bytes against the declared size and SHA-256. Expired, foreign, or mismatched reservations fail explicitly.

The documented email-intake bucket limits original email to 10 MiB and message/rfc822. Other private buckets have distinct purposes, including authorized gateway originals and time-limited privacy exports. Generic media/deepfake analysis is intentionally outside the SIH production surface. A bucket allowing a media type does not imply an active image, audio, video, or deepfake detector.

Saved Evidence Passports include an immutable evidence snapshot and manifest. Their digests preserve integrity; they do not anonymize every identifier or independently re-fetch stored originals during JSON package verification.

Retention, expiry, and legal holds

Retention depends on the selected policy, artifact type, workspace configuration, and verified worker execution. A retention deadline or a temporary-file request is not proof that deletion has already happened.

Retention workers check legal holds, remove eligible objects, verify absence, and update lifecycle records and receipts. Holds can preserve organization, user, scan, and file references. Backups, organization-owned evidence, and provider-side copies can require separate handling; there is no unconditional delete-everything-within-24-hours promise.

Sessions, API keys, and access

Server-managed production cookies are HttpOnly, Secure, and SameSite=Lax. Account and workspace access is checked against verified identity and active membership. Privileged server operations need organization predicates in addition to the database and Storage policy boundaries.

Raw developer API keys are displayed only once. Stored records contain key hashes, masked/prefix values, scope/lifetime/status metadata, and usage information rather than the raw key. Protect exported reports and credentials according to your organization’s access policy.

Access, export, and erasure review

Authorized users can reopen saved investigations and export supported evidence/report formats. Exports may contain identifiable evidence, relationships, and summaries; inspect them before sharing. Redacting a signed JSON package changes its integrity and must not be presented as an unchanged valid export.

Authenticated workspaces can request a data export or erasure review through the account governance workflow. An erasure request prepares authorized review of holds, organization-owned evidence, Auth sessions, backups, and subprocessors. The privacy.erase worker is not an automatic comprehensive destructive erasure engine.

Contact the platform operator for deletion or access actions not exposed in the product. Read the security controls and analysis limitations alongside this data-handling description.