Security
Finished before the first pilot, not after
Fromenance is a communication provenance platform that asks institutions to route customer mail through it, so the security posture below was a requirement before the first pilot rather than a roadmap item. This page says what we store, how long we keep it, how tenants are isolated, and who our subprocessors are; the DPA makes it contractual.
Data handling
Recipient addresses never reach us on the API path
The SDK computes hmac-sha256 of the lowercased, trimmed address with your tenant secret and sends only the hash. The communications table has no address column. Where we must see an address (a forward or the journal path), it is encrypted with a per tenant key and purged 30 days after use.
Raw messages: encrypted, tenant scoped, time limited
The raw MIME of every submission is stored in R2 under a tenant prefix, encrypted with a tenant scoped key held in Workers secrets and rotated yearly, retained per your setting (default 90 days), then deleted with a deletion record in the audit log.
Fingerprints are one way
We keep the normalized text only long enough to compute a SimHash and a SHA-256; it is not persisted. A fingerprint cannot be turned back into a message.
Replies never echo the message
The verdict reply never quotes the suspicious message, never includes its links, never names its sender. The verdict block is locked text.
Cross tenant views see indicators and counts only
Our backoffice intelligence view, and the network layer on the roadmap, operate on indicators and counts. Never on submissions, never on raw MIME, never on content.
US data residency
All data is stored in the United States in v1. Subprocessors are listed below and in the DPA.
What we store and for how long
| Data | Form | Retention |
|---|---|---|
| Registered communication | Verify code, recipient HMAC, SimHash and SHA-256 fingerprint, message id, From address, sent time, link domains, template and campaign ids | Tenant retention window, default 90 days |
| Forwarded or uploaded message | Raw MIME or screenshot, encrypted in R2 under the tenant prefix | Tenant retention window, default 90 days, deleted with an audit record |
| Submitter address | HMAC for matching; encrypted copy for the reply only | Encrypted copy purged 30 days after the reply |
| Verdict | Outcome, rule, signals, matched registration id, override trail | Life of the tenant account |
| Indicators | Kind, normalized value, first and last seen, counts | Life of the tenant account |
| Rejected inbound | Mail that failed the trust check, with the reason | 24 hours |
| Audit log | Actor, action, target, before and after | Life of the tenant account |
Trust and abuse
Inbound trust check
Mail to your tenant inbox is dropped unless the sending hop passes DKIM or ARC for a domain you own with a valid _fromenance TXT token. Rejected mail is held 24 hours for diagnosis, then deleted.
Replay handling
A valid code on the wrong message or the wrong recipient resolves to Not verified for the customer and a high priority replay flag internally.
Verify page abuse controls
Rate limited per IP (60 per minute) and per site key, requires an allowed origin, and escalates to Cloudflare Turnstile when a site key exceeds its normal rate.
Fraud list poisoning
Anyone can forward anything to your inbox through your rule. Fraud list entries come only from analyst action or, on the roadmap, confirmed campaign clustering. Never automatically from a single submission.
No LLM on the verdict path
Extraction is regex, MIME parsing, and SimHash; matching is HMAC comparison and Hamming distance. Screenshot OCR runs in Workers AI and its output is untrusted text that only feeds those extractors. Any future lure classifier produces a fixed schema label and can never change a verdict from Verified.
Idempotent, signed, replay windowed
Every provider webhook signature is verified with a 5 minute replay window. Every creating POST accepts an Idempotency-Key stored for 24 hours.
Platform security
Authentication
Admin app users sign in with Better Auth using email magic link and passkeys. The backoffice sits additionally behind Cloudflare Access with a hardware key requirement. SSO (SAML and OIDC) is on the roadmap.
API keys and site keys
API keys are hashed at rest, shown once, scoped (register, read, admin), revocable, with last used tracking. Site keys are public, bound to your tenant and your page's origin, and carry no secret.
Tenant isolation in the data layer
Every tenant owned table carries tenant_id and every query goes through a scoped repository that requires it. R2 prefixes are per tenant. An automated suite asserts no cross tenant read on every endpoint.
Encryption
Encrypted columns hold AES-256-GCM ciphertext produced with a per tenant data key wrapped by a master key that lives only in Workers secrets. TLS everywhere. Secrets never appear in configuration or source.
Audit log
Every write in the admin app and the backoffice is logged with actor, action, target, before, and after. Backoffice impersonation is read only and audited.
Operations
Secrets live in Workers secrets only. Neon and R2 credentials rotated quarterly. Dependency scanning. Deployment only from CI on the main branch. Observability through Workers Logs, Analytics Engine, and Sentry.
Subprocessors
Nothing runs outside Cloudflare, Neon, and Resend at runtime. Stripe holds billing, Sentry receives error events. Changes are announced to tenants 30 days in advance as described in the DPA.
| Subprocessor | Purpose | Location |
|---|---|---|
| Cloudflare, Inc. | Hosting, edge compute, edge storage (D1, R2, Queues), Workers AI for screenshot OCR, Turnstile | United States |
| Neon, Inc. | Postgres system of record | United States |
| Resend, Inc. | Inbound and outbound email | United States |
| Stripe, Inc. | Billing | United States |
| Functional Software, Inc. (Sentry) | Error monitoring | United States |
Compliance roadmap and disclosure
SOC 2
SOC 2 Type 1 is targeted within 12 months of the first paying tenant. Until then, this page, the DPA, and a completed vendor security questionnaire are what we offer a bank's third party risk review. Ask and we will complete yours.
Responsible disclosure
Report vulnerabilities to security@fromenance.com. We acknowledge within two business days, keep you informed, and do not pursue researchers who act in good faith, avoid privacy violations and service disruption, and give us reasonable time to fix. Please do not test against tenant inboxes or production tenant data; use the demo tenant on this site.
Security incidents affecting a tenant's data are notified to that tenant without undue delay and no later than 72 hours after we confirm them.
Send us your vendor security questionnaire.
We answer it against this page and the DPA. If your review prefers to start without mail routing, the web verify page needs no mail plumbing at all.