Transparency report.

Period covered	2026-01-01 – 2026-06-30
Telemetry actually spans	2026-05-18 – 2026-06-28 — 42 reporting days of 181
Reporting installs	~10 distinct over the period; 1 as of publication
Findings surfaced	24,908 total · 2,681 critical (10.8%)
Tier 3 refutation rate	74.6%
User-acted false-positive rate	0.008% — not evaluable (section 02)
External audit	None commissioned (section 08)
Government or legal requests	Zero (section 09)

Tier 3 refuted three quarters of everything Tier 2 escalated. The escalation architecture worked as designed — and the same number says the on-device classifier alone would have been unusable.

Google Drive dominated findings at 74.1%. Haven found far more in cloud-drive sharing posture than in mailboxes, which was not the original expectation.

97.8% of Drive scan attempts failed — 7,624 against 169 completions, of which 99.2% were expired-credential rejections, not scanning faults. See section 07.

Aggregate counts, rolled up across the period from daily payloads. Per-install identifiers are never collected; the aggregator joins on UTC day boundaries only.

By severity

Severity	Count	Share
Critical	2,681	10.8%
High	5,845	23.5%
Medium	1,679	6.7%
Low	14,703	59.0%

By source

Source	Count	Share
Google Drive	18,451	74.1%
Gmail	3,249	13.0%
Outlook	1,781	7.2%
OneDrive	848	3.4%
Local files	283	1.1%
IMAP	186	0.7%
iMessage	92	0.4%

At this cohort size the distribution reflects a handful of individual accounts, not a population. One heavily-shared Drive moves the whole table.

By kind

Kind	Count
drive_anyone_with_link	11,599
drive_stale_external_share	5,266
tier2_signal	2,668
drive_external_share	1,396
one_time_secret_url	1,116
drive_domain_wide_share	1,040
plaintext_password	768
us_bank_routing	381
us_bank_account	300
jwt_token	84
credit_card	83
Rules-pack detectors (all slugs)	72
ssn_us	40
openai_api_key	36
aws_access_key_id	29
suspicious_mail_filter	18
explicit_image	13
google_oauth_client_secret	2

False-positive rate — not evaluable

Haven’s product requirements set a ≤8% exit gate. The raw computation gives 0.008% — 2 false-positive markings against 24,908 findings. That is not a pass. It is an artifact of non-engagement: twenty-one remediation actions of any kind were recorded across the entire period. Users overwhelmingly did not triage what Haven surfaced, so the denominator never entered the regime the gate assumes.

Reporting 0.008% as a pass would be the single most misleading number this document could contain. The gate remains unevaluated and stays open until a cohort actually works through a findings list.

First-critical-finding rate — not computable

A ≥85% gate that requires intersecting a per-install cohort with first-scan results. The aggregator deliberately holds no per-install identifiers (section 10), so it cannot be computed from the data Haven collects — by design. Either the metric or the collection boundary has to change. The boundary is not moving, so the metric will be redefined for the next edition.

Action	Slug	Count
Archived	archive	5
Moved to trash	trash	4
Labeled	label	4
Marked resolved	mark_resolved	3
Revoked link	revoke_link	2
Marked not sensitive	mark_false_positive	2
Context downgrade	context_downgrade	1
Total		21

Twenty-one actions against 24,908 findings is the central finding of this report about Haven’s own usability, and it is why the false-positive gate is not evaluable. Surfacing is solved. Getting anyone to act is not.

Undo rate: 3 of 21 actions were undone — 14.3%. The 30-day undo window means Haven receives no signal for windows that expire un-undone, so this is a floor, not a total.

Time-to-resolve: no data. The age-bucket rollup was not populated by schema v4 payloads in this period. Fixed for the next edition.

Every outbound call crosses a single broker. A continuous-integration lint fails the build if an HTTP client is constructed anywhere else in the codebase.

Channel	Destination	Volume
Tier 2 model bytes	models.havenprotect.app	2.00 GiB
Tier 3 adjudication	inference.havenprotect.app	27,781 calls
Image classification	image.havenprotect.app	13 findings
Telemetry aggregate	backoffice.havenprotect.app	72 daily payloads
Rules pack	rules.havenprotect.app	292 activations
Update manifest	updates.havenprotect.app	728 activations

Dropped for lack of transport: 52. Occasions where an outbound call was attempted with no transport available and was dropped rather than queued. No user content is buffered across such a failure.

Tier 2 — on-device classifier

Model activations	315
Manifest activations	316
Bytes shipped	2.00 GiB
Signature / manifest check failures	0

Zero check failures across 316 manifest activations: the signed-manifest channel behaved correctly for the whole period.

Tier 3 — Haven-operated hosted adjudicator

Verdict	Count	Share
Refuted	20,733	74.6%
Confirmed	4,359	15.7%
Insufficient	2,689	9.7%
Total	27,781

Tier 3 discarded roughly three of every four candidates Tier 2 raised. A refuted verdict never reaches the user — it is dropped at the scanner layer — so users saw 4,359 confirmations out of 27,781 adjudications.

Two readings, both true: the escalation architecture is doing exactly the job it exists for, and Tier 2 in isolation would have been unusable, generating roughly four times the noise a user should ever see. Anyone evaluating Haven’s on-device-only mode should weigh that.

Call failures: 0. Model: Gemma 4, served on Haven-controlled hardware under exclusive operational control.

Zero-retention attestation — not independently verified

The serving environment is configured for zero application-layer retention and ephemeral infrastructure storage. No third party has verified it. Independent attestation has not been commissioned. Users should treat zero-retention as Haven’s documented configuration and stated commitment — not as an audited fact.

Manifest activations	728
Apply attempts	86
Relaunches scheduled	85
Manifest check failures	28
Opt-out rate	0%

28 manifest check failures against 728 activations (3.8%) were transport failures, not signature failures. No update was ever applied from an unverified manifest.

Authorization outcomes

Connector	Started	Completed	Failed
Gmail	76	57	9
Google Drive	27	16	9
Outlook	47	24	20
OneDrive	11	11	0

Outlook’s 20 failures against 24 completions is the worst ratio on the board, and reflects a period of active iteration on the combined Microsoft grant.

Scan reliability — a defect, disclosed

Connector	Completed	Failed
Google Drive	169	7,624
OneDrive	50	2
Local files	89	0

97.8% of Google Drive scan attempts failed during this period — but almost none of it was a scanning fault. Broken down by reason:

Failure reason	Count	Share
Expired or rejected credentials (HTTP 401/403)	7,565	99.2%
Network unavailable (incl. rate limiting)	59	0.8%
Response parse failure	0	—
No transport	0	—

Rate-limit responses are deliberately classified separately from authorization failures, so these are genuine dead-credential rejections rather than Google throttling Haven.

The failures were a two-week burst, not a chronic condition. They run from 2026-05-28 to 2026-06-11 — peaking at 1,290 in a single day — and then effectively stop. Seven installs were affected; 82% of the volume came from one.

The cause was Haven’s own OAuth status, not the Drive connector. Google OAuth verification was not approved until 2026-07-25. Until then the application sat in Google’s “Testing” publishing status, where refresh tokens expire after seven days. Once a tester’s token expired, every subsequent scan was rejected. This was a known and documented risk before it happened; it happened anyway. That root cause is resolved — the application has been in production status since the approval.

The volume came from a retry storm, which is also already fixed. A scan that failed did not stamp its account as having been attempted, so the background cadence gate saw an account overdue for a scan and re-fired it on the next 60-second tick — producing up to 1,290 attempts a day against a credential that could never succeed. The fix, which stamps the attempt even on failure so the gate backs off to the normal six-hour interval, shipped 2026-06-02. The daily failure counts taper from that date as installs picked up the update and reach zero by 2026-06-13, which is what the burst’s shape in the data actually shows.

No open defect remains from this. The credential expiry is resolved by production OAuth status; the amplification is resolved by the cadence fix. What is left is a design question rather than a bug: after repeated authorization failures the agent still retries on the normal schedule instead of stopping outright and asking the user to reconnect. The user is shown a connection error on the account either way.

No external security audit has been commissioned. It is deferred on cost grounds pre-revenue. That deferral is a real gap against Haven’s own published requirements, not a satisfied one.

Third-party review that has happened, and which is not a substitute:

Google CASA Tier 2 / OAuth verification — approved 2026-07-25 for gmail.modify and full drive scopes. Assessed by TAC Security. Scope is Google API data handling, not Haven overall. Annual recertification required.

Microsoft Entra Publisher Verification — verified as Haven Privacy LLC. This is an identity check, not a security assessment. Haven holds neither Microsoft 365 Publisher Attestation nor Microsoft 365 Certification, and should not be described as “Microsoft certified.”

Windows Authenticode (organisation validation as Haven Privacy LLC) and Apple Developer ID with notarization — code signing and identity, not audits.

Request type	Received	Complied
Law-enforcement data requests	0	0
Subpoenas / court orders	0	0
National security requests	0	0
Takedown / removal demands	0	0
User-data preservation requests	0	0

Zero of every category.

Haven’s architecture limits what could be produced under compulsion. Message contents, file contents, and finding details never leave the user’s device. Tier 3 adjudication sends a bounded excerpt and receives a verdict of at most 256 bytes; nothing is retained server-side. What Haven holds is the email address on an invite, a license key, a billing relationship, and day-granular aggregate counts with no per-install identifier.

Haven publishes no warrant canary. A canary that has never been tested carries no information, and committing to one creates an obligation a future edition may not be free to discharge honestly.

These are unanswerable rather than withheld:

Which findings any individual user had. Rollups are day-granular counts with no per-install identifier.

What any finding contained. No message body, filename, file content, or matched value crosses the telemetry boundary — only a bounded kind slug drawn from a closed universe.

Who any user corresponds with. No addresses, domains, or recipients.

Per-user retention or engagement curves. No install identifier means no cohort join — which is also why the first-critical-finding gate in section 02 is not computable.

These limits are enforced structurally: the outbound payload type is exhaustive, the finding-kind universe is bounded, and a continuous-integration lint fails any build that adds an egress path outside the broker.

Source. The daily aggregate payload schema, version 4, as received by Haven’s backoffice.

Aggregation. Summed across every daily payload received within the period. No estimation, extrapolation, reweighting, or outlier removal. Where a field was unpopulated it is reported as missing rather than inferred.

Known gap. Telemetry reporting only reached production on 2026-05-18, so the period covers 42 reporting days of 181. Figures are period totals, not annualised.

Self-verification. A user with their per-install network activity log can confirm that every outbound row in their log appears under the matching channel in section 04. Mismatches are reportable through the in-app feedback channel.

Does the ≤8% false-positive gate survive contact with a cohort that actually triages? The 74.6% Tier 3 refutation rate suggests the pre-adjudication signal is noisy. The post-adjudication rate is what the gate should measure, and it is untested.

Why do users not act? Twenty-one remediations against 24,908 findings is a product problem, not a detection problem, and it is the most important thing in this report.

Can the first-critical-finding gate be redefined without introducing a per-install identifier? If not, it should be retired rather than left standing as an uncomputable commitment.

Drive scan reliability — root cause, fix, and verified failure ratio.

Zero-retention attestation — what independent verification is affordable pre-revenue, if any.

Questions or corrections: privacy@havenprotect.app. Corrections to a published edition are made in place with a dated note, never silently.