​

Technical control audit

Status: observed code audit, September 8, 2026. This document records what the current repository actually enforces for commercial intelligence, contact enrichment, and external-action readiness. It is evidence for the Trust & Data Governance Pack; it is not a claim that a provider, workflow, or legal basis is already approved.

​

Executive finding

The current code has useful provenance and safety primitives for market research and contact-path classification, but the contact-enrichment boundary is not yet a legal/governance boundary. A user-triggered request is treated as authorization to enrich records. The request does not carry a declared purpose, authorization reference, source-rights acknowledgement, or suppression state, and the persistence model does not retain enough metadata to enforce provider-specific display/export/retention/deletion terms. Therefore contact enrichment must remain behind the launch gates in launch-gates.md. The public legal pages should describe it as a gated, workspace-authorized capability until the controls below are implemented and verified.

​

Evidence matrix

​

Required control contract before enabling contact operations

The implementation should make these checks explicit and fail closed:

1. The actor selects a declared purpose and the UI records the authorization event, workspace, actor, selected records, policy version, and timestamp.
2. Every endpoint carries origin/provider, source URL or source identifier when available, verification state, confidence, attribution, rights status, allowed uses, retention/expiry, and a deletion or suppression handle.
3. A suppression/opt-out check runs before enrichment, export, draft creation, and any outbound send. A suppression result must be explainable without exposing unnecessary personal data.
4. Provider-specific terms are evaluated per field, not inferred from the provider name. Unknown rights remain blocked for display/export.
5. Deletion and expiry remove or quarantine contact data from records, indexes, exports, drafts, campaign providers, and audit-linked replicas as applicable. The system must retain only the minimum evidence needed to prove the action.
6. Any Smartlead or future outbound adapter must have a separate send authorization and unsubscribe/bounce synchronization contract. Enrichment permission is not send permission.

​

Staging-report reconciliation

The current beta direction is Nylas, not Smartlead. Nylas connects Gmail or Outlook and sends only campaigns that Brein has separately authorized. The send-only E2E, OAuth behavior, and provider controls are verified for the beta. Brein does not read, list, search, or manage the user’s inbox or replies in this scope. Staging also contains Tomba pilot governance and provider-lineage work. Keep the beta allowlisted and do not broaden the scope without a new review.

​

Scope boundary

This audit does not conclude that the current code violates a particular law. It concludes that the product cannot presently evidence the controls needed to make a transparent, rights-aware product claim for contact enrichment or outreach. Legal copy, provider activation, and commercial launch should remain conditioned on these technical controls and the underlying contracts/source rights.