Most accidental disclosures are ordinary actions with one wrong detail: a lookalike address, a personal mailbox, hidden author comments, an old reply thread or the attachment that should never have been executable.
CleanSend inspects that complete context at the last safe moment. It evaluates recipients, message content, classifications and attachment facts against a versioned deterministic policy before delivery.
The last safe moment
A draft is still cheap to fix. CleanSend turns every send attempt into an immutable inspection containing the policy version, engine version, safely masked detector evidence and outcome. The sender sees what triggered, where it triggered and what must change.
A security decision should explain itself before it interrupts the work.
Clean, warn, hold or block
Routine mail passes cleanly. A warning asks the sender to acknowledge a specific risk with a reason. A hold routes ambiguity to security review. A block cannot be acknowledged, excepted or approved away: the lookalike recipient, macro-enabled workbook, executable or double extension must be removed or corrected.
Deterministic
Recipient, content, attachment and metadata facts drive reproducible policy decisions.
Proportionate
Routine cleaning is automatic; judgment is reserved for genuine ambiguity.
Bounded
Exceptions match exact rules, senders and domains and always expire.
A clean copy, not a silent overwrite
Office and PDF attachments accumulate author names, comments, revision history, custom properties and embedded paths. Cleaning creates a new artifact and hash. The original hash, removed properties, actor, time and clean-copy hash remain together as evidence.
Recipients, content, classifications, file structure and hidden metadata.
Mask sensitive matches and identify the exact location and policy rule.
Correct recipients, clean or remove files, encrypt, classify or acknowledge.
Approval triggers a fresh policy run before the message can leave.
Approval is never a bypass
A held message can be released only after a reviewer records a decision and CleanSend runs the current message through the active policy again. If a new executable appears after the request was raised, the release fails. The approval cannot carry an old risk assessment across changed content.
How it is built
CleanSend uses the System32 house stack: a Go API with SQLite and a Next.js 16 / React 19 interface. Its demo workspace contains 420 messages, 1,050 recipients, 680 attachments, 1,900 metadata items, fourteen policy versions, 48 rules, 760 findings, 180 remediations, 46 release requests and 22 exceptions. Tests cover clean-copy hashes, hard blocks, acknowledgements, release reinspection, new blockers, exact exception scope, evidence masking and policy-version history.
CleanSend is available now in the System32 catalog. Open a held message, inspect the masked evidence and follow the release through its final policy check.