When Criminals Read Your Email for Months: Why No Human Access Matters at Ṣọ
What Does "No Human Access" Actually Mean for Email Security?
Last week a federal jury convicted three more defendants in one of the largest Business Email Compromise schemes ever prosecuted. Total convictions: 25. Total stolen: approximately $215 million across 47 states and 19 countries. The methodology, per the DOJ press release dated April 30, 2026, was patient: hack a business email account, monitor the conversations for weeks, learn the business and the contacts, then send fraudulent payment requests crafted to match the victim's normal communication patterns.
That last sentence is the entire point. The attackers won not because they were sophisticated coders but because they had read the victim's email long enough to write fraudulent emails that were indistinguishable from legitimate ones. Patience was the weapon. Access to the inbox was the precondition.
This is the threat that "No Human Access" exists to address. Not just access by criminals, but access by anyone — including the email security vendor's own employees, contractors, and operations teams. If your email security tool retains customer email and gives analysts the ability to read it, the same patience-based attack pattern exists inside the vendor that exists inside the criminal organization. Different motives, same access surface.
This post walks through what No Human Access means at Ṣọ specifically, what it doesn't mean, and how it's enforced architecturally rather than as a policy promise.
How Does the Industry Currently Handle Customer Email?
Most enterprise email security vendors operate at the mail gateway. Customer email passes through the vendor's servers before reaching the recipient's inbox. The vendor's infrastructure analyzes the message, applies a verdict, and forwards it on. In most configurations, copies are retained for retrospective analysis, training, and incident response.
The retention model creates the access surface. Once email content is persisted on vendor infrastructure, multiple categories of people can theoretically read it.
Analyst teams investigate suspicious emails escalated by automated detection. When the model flags a message as uncertain, a human reviewer reads the full content to make the call.
Incident response operators investigate breaches across customer environments. When a compromise is detected, IR teams pull historical email records to trace the attacker's movement.
Machine learning teams train detection models on customer email data. Anonymization helps, but the underlying email content has to exist in some form for the training pipeline to consume it.
Customer support and account management receive escalated tickets that sometimes require reviewing specific emails. "Why did this message get marked as phishing?" is a routine support question that often requires looking at the actual message.
Compliance and audit teams review email content as part of regulatory reporting, eDiscovery, or breach notification obligations.
Third-party contractors sometimes have access to support, training, or operations functions where email content surfaces. The contractor relationships are usually disclosed in privacy policies, often only in vague terms.
Each access path has a legitimate operational reason. The aggregate effect is that customer email at most legacy vendors is readable by some number of humans, with that number rarely fewer than dozens and frequently in the hundreds across an enterprise customer base.
What Does Ṣọ's "No Human Access" Mean Architecturally?
Ṣọ's architecture eliminates each of the access paths above. Not by policy. By design.
No analyst escalation path. When Ṣọ's models are uncertain about an email, the verdict is returned to the user as "uncertain" and the user makes the call. There is no internal queue where humans review ambiguous emails. This is a deliberate constraint that limits some detection capability in exchange for the architectural guarantee.
No incident response access to email content. When a security incident requires investigation, Ṣọ's IR work happens on metadata that doesn't include email content (detection rates, model performance, infrastructure logs). Customer email is not part of the IR data set because it doesn't exist on Ṣọ infrastructure after analysis completes.
No model training on customer email. Ṣọ's detection models are trained on public data, synthesized data, and our own controlled test environments. Customer emails are never used for training, anonymized or otherwise. This is a constraint on model improvement velocity that we accept in exchange for the privacy guarantee.
No customer support workflow that surfaces email content. When a user submits feedback about a verdict (false positive or false negative), the email content is hashed before storage. The hash is irreversible. No one at Ṣọ, including the founder, can read the original email from the hash. The hash serves a specific operational purpose: matching the same problematic email pattern across submissions to improve detection. It does not allow reconstruction of the original message.
No contractor or third-party access to email content. There are no contractor relationships that involve reading customer email content. Operations, support, and engineering all work without that capability.
The pattern that holds across all of these: the access path doesn't exist because the data doesn't exist on Ṣọ infrastructure after the seconds of analysis. You can't grant someone access to data that has been deleted.
How Is "No Human Access" Different from a Privacy Policy Promise?
Policy promises and architectural commitments fail differently.
A policy promise depends on employee behavior, organizational discipline, and the vendor's ongoing commitment to honor stated commitments. Policies can be changed with a single internal decision. They can be honored inconsistently across teams. They can erode over time as business pressures shift. Auditing a policy promise requires trusting that the vendor accurately represents its own internal practices.
An architectural commitment depends on the absence of capabilities in the codebase. If there are no admin tools that surface customer email, no analyst dashboards that queue customer messages for review, no logging code that writes email content to durable storage, then no employee can grant themselves access regardless of intent. Auditing an architectural commitment requires inspecting the system, not the policy document.
Ṣọ's No Human Access guarantee is enforced by both: a policy commitment that customer email won't be read, and an architecture that doesn't have the tools to read it even if a future Ṣọ employee wanted to.
This matters because policy alone is not enough. Most large data breaches at vendors with strong stated privacy policies happen because the policy didn't constrain the system. The data was readable. The access controls were configurable. The temptation or the operational necessity outpaced the policy.
What About Feedback? Doesn't That Require Reading Email?
When a Ṣọ user marks a verdict as wrong (a missed phishing attempt or an over-eager false positive), the feedback flow handles email content differently than a typical support workflow.
Most email security tools, when a user submits feedback, send the original email back to the vendor for analyst review. The analyst reads the email, validates the user's report, and uses it to retrain the detection model. This workflow is operationally efficient. It also requires human access to customer email.
Ṣọ's feedback flow does not work that way. When you submit feedback, Ṣọ generates an irreversible hash of the email content and stores the hash, not the email. The hash captures the structural pattern of the email well enough to match it against future submissions but does not allow reconstruction of the original message.
Hashing is a one-way mathematical function. The hash of an email is a fixed-length value that can be computed from the email but cannot be reversed to recover it. There is no algorithm, no key, no operational procedure that turns the hash back into the email. The original message is gone.
What this enables: when a similar phishing pattern arrives in another user's inbox, Ṣọ's detection can recognize the same hash signature and apply the verdict consistently. What it doesn't enable: anyone reading the original email at any point.
This is a legitimate trade. Feedback is operationally useful. Reading customer email is not. Hashing keeps the useful part and discards the privacy-destroying part.
How Does the Architecture Compare to Major Privacy-Focused Cloud Services?
Ṣọ's No Human Access pattern is structurally similar to commitments made by major privacy-focused cloud services that operate at scale.
Apple's Private Cloud Compute runs AI inference on Apple-owned servers but enforces architectural guarantees that Apple employees cannot access user data even with admin credentials. The hardware and software are designed to prevent that access at the silicon level, with public verification mechanisms.
Anthropic's Zero Data Retention API tier processes customer prompts and outputs without retaining them or making them available to Anthropic employees for review. The tier is offered specifically for enterprise customers who need architectural assurance, not just policy commitment.
Signal's contact discovery processes user contact lists on Signal servers without persisting them or making them readable by Signal employees. The service uses secure enclaves and cryptographic constructions to enforce the constraint architecturally.
Each of these services accepts operational trade-offs in exchange for the privacy guarantee. Apple's Private Cloud Compute has slower inference compared to public cloud alternatives. Anthropic's Zero Data Retention tier has different support workflows. Signal's contact discovery has scaling constraints. The trade-offs are real, and they are why most cloud services don't implement equivalent guarantees.
Ṣọ's trade-offs follow the same pattern. Slightly slower model adaptation to novel threats because we don't train on customer email. No human escalation path on uncertain verdicts. Higher engineering cost for hashed feedback compared to plaintext support workflows. We accept these trade-offs because the privacy guarantee is the product, not a marketing claim about it.
What's Verifiable, and What Isn't?
Honesty matters here, especially after our April content overstated what was verifiable.
Verifiable from your browser: if you open developer tools while Ṣọ is running, you can see HTTPS calls going to Ṣọ infrastructure containing email content for analysis. You can see the verdict come back. The transit is observable.
Verifiable from architectural inspection (with appropriate access): the absence of admin tools, analyst dashboards, and customer-email-surfacing workflows. A third-party security audit can confirm these absences. We have not yet published one. We plan to.
Not currently independently verifiable: the no-logs commitment, the deletion-after-processing commitment, and the no-training commitment. These rely on the same trust model that governs Apple's Private Cloud Compute and Anthropic's Zero Data Retention tier. We're committing to publishing audit results when complete.
This honesty matters. Earlier this year we used framing about Ṣọ's architecture that overstated what was verifiable in real time. We've corrected that framing across our content and we'll keep correcting it as we go. The privacy story Ṣọ is built on is real. Some of it requires audit-level verification for full confirmation, and we're explicit about that distinction.
What Does This Mean for Your Inbox?
Three concrete consequences of the No Human Access architecture for the average Ṣọ user.
Your email content is not searchable by Ṣọ employees, including the founder. There is no internal tool that allows anyone at Ṣọ to look up "all emails from sender X" or "all emails containing phrase Y" across the customer base. The data doesn't exist on our infrastructure to be searched.
Your email content is not part of any Ṣọ data set, training corpus, or analytics aggregation. Detection model improvements come from public threat feeds, synthesized data, and our own controlled environments, not from your inbox.
Your email content is not subject to subpoena response, regulatory disclosure, or breach notification. The standard subpoena response from a vendor with retained customer email involves producing the requested messages. The standard Ṣọ response is producing nothing because we have nothing to produce. The architectural commitment to not retain email content extends to government access requests as well.
This is the same architectural pattern that makes the $215M case attackers' weeks-long email surveillance impossible at Ṣọ. The attackers in that case had the same access surface that legacy email security analyst teams have. Different motives. Same access surface. The defense is removing the access surface, not promising better behavior on top of it.
Frequently Asked Questions About No Human Access
Can Ṣọ help me investigate a phishing attempt I received?
Yes, but the workflow is different from legacy vendors. You can submit feedback through the app. Ṣọ uses the hashed signature of the email to improve detection across the user base. We can't read the email, but we can match similar patterns against future detections. If you need a human to read your email and tell you what's in it, Ṣọ is not the right tool. If you want detection that improves over time without anyone reading your email, this is the right architecture.
What happens if a Ṣọ employee tries to violate this policy?
There is no admin tool to violate. The architecture is enforced through the absence of capabilities, not through the presence of policies. A Ṣọ employee with full system access still cannot read customer email because the email isn't on Ṣọ infrastructure after analysis completes.
Is this true for the Free tier as well as the Premium tier?
Yes. The architectural commitments apply to all Ṣọ users regardless of tier. Free tier users get the same No Human Access guarantee as Premium tier users.
What about during the seconds of active analysis? Is the email accessible then?
In principle, the email exists in memory on Ṣọ servers during the seconds of active analysis. There are no admin tools that surface that data to humans during processing, but a sufficiently determined attacker with full system access could in theory observe email in transit through the analysis pipeline. This is the same constraint that governs every server-side processing service, including Apple's Private Cloud Compute. The window is seconds long and the access surface is restricted to a small operational team with no business need to look. After the seconds, the email doesn't exist anywhere on Ṣọ infrastructure.
How do you compare to fully end-to-end encrypted email services like ProtonMail or Tutanota?
End-to-end encrypted email services keep email encrypted such that even the provider can't read it. Ṣọ is different. We process email server-side but don't retain it. End-to-end encryption is a stronger architectural property for storage privacy. Ṣọ's architecture is more comparable to the analysis layer over your existing email provider (Gmail, Outlook, iCloud) than to E2E email services. The two architectures address different threat models.
What if I want to verify the No Human Access claim independently?
A third-party security audit is on our roadmap. We will publish the results when complete. Until then, the verifiable parts are the absence of admin tools and the architecture's design principles, both of which can be inspected with appropriate access.
Executive Summary: TL;DR
The $215M BEC case prosecuted last week demonstrated what happens when criminals gain access to email accounts and have the patience to read them for weeks. Patient access to the inbox is the weapon, not technical sophistication.
Most legacy email security vendors maintain similar access surfaces inside their own organizations. Analyst teams, IR operators, ML teams, support staff, and contractors can read customer email at most large vendors. The motives are different from the criminals'. The access surface is similar.
Ṣọ's No Human Access guarantee removes the access surface architecturally. There are no admin tools that surface customer email. There is no analyst escalation path. There is no model training pipeline that consumes customer email. Feedback is hashed before storage. No customer data is persisted on Ṣọ servers after analysis.
This is enforced through the absence of capabilities, not through policy promises. The architecture is similar in pattern to Apple's Private Cloud Compute, Anthropic's Zero Data Retention API tier, and Signal's contact discovery. Each accepts operational trade-offs in exchange for an architectural privacy guarantee.
We're explicit about what's currently independently verifiable (transit and the absence of admin tools) and what relies on architectural trust until we publish a third-party audit (the no-logs, deletion, and no-training commitments).
If your inbox is part of your professional reputation, your client relationships, your donor records, or anything where a vendor analyst reading it would be a problem, the No Human Access architecture is the structural answer.
Don't be victim 1,001. Install Ṣọ in 2 minutes at soemailsecurity.com.
Sources: US Attorney's Office, Northern District of Ohio, press release dated April 30, 2026; Apple Private Cloud Compute technical documentation; Anthropic Zero Data Retention API tier policy; Signal contact discovery technical documentation; Verizon 2024 Data Breach Investigations Report.
iOS: apps.apple.com/us/app/so-mail/id6756896070 Android: play.google.com/store/apps/details?id=com.app.somail
Protecting your inbox without ever reading it.