Guides
You control what data reaches your agent
Prompt injection is one reason a data firewall helps — not the brand promise.
Mail’s primary job is data control: you decide what an agent may read. Progressive Allow and Block. An address for the agent, not your inbox. Default deny. The agent cannot escalate.
Prompt injection is a secondary reason that shape helps. Untrusted email is a classic injection path. Keeping most content away from the agent until you Allow it shrinks blast radius. That is useful. It is not why the product exists, and it is not a claim that Mail is an anti-jailbreak product.
This guide explains the control model first, then how that control helps with injection risk — and what it does not do. No weasel words.
The honesty clause (read this first)
Mail limits what untrusted content can reach the agent. It does this with default deny, human Allow/Block, and Allowed-only MCP/API reads. The agent cannot escalate.
Mail is not a full LLM jailbreak / model-alignment shield.
It does not stop every prompt injection once content is Allowed.
It reduces blast radius by keeping most content away from the agent until a human says yes.
If content is Allowed, the model still processes that content. A cleverly crafted Allowed message can still attempt injection against the model. Mail does not claim to sanitize, rewrite, or “prove safe” every Allowed payload. The protection is at the data boundary: what gets in, under whose authority — not at the model’s internal alignment layer.
That distinction is the whole point of this guide.
What “data firewall” means here
In Mail, the firewall is the trust wall:
Unknown → Pending → Allowed / Blocked
Default deny. Mail (and related data gated the same way) that has not been Allowed is not readable by the agent through MCP or API. Pending stays pending. Blocked stays blocked. The agent cannot move itself from Pending to Allowed.
A new sender writes to m-<botname>@mail.alix-services.com. Until you Allow, the agent does not see the body, does not summarize it, does not act on instructions buried inside it. The untrusted content exists on the wall. It does not yet exist in the agent’s working set.
You confirm ownership with a magic link to the owner email — tap the link, no shared password — then Allow or Block on your phone. The agent can start immediately with “start using Mail”; the 24-hour owner email confirm is not a signup blocker. Authorization stays human.
That is a data firewall: progressive grant of what may reach the agent, not a promise that the model cannot be manipulated by anything that does.
How this helps against prompt injection
Prompt injection needs a channel. Something untrusted has to enter the context the model sees.
Mail shrinks that channel by design:
- Default deny. Unknown and Pending mail never reaches the agent. A spray of cold messages — phishing-shaped “instructions,” spoofed ops mail, random newsletters — does not automatically become agent context.
- Human Allow. Only what you Allowed enters the Allowed set. You are the gate. That is slower than “read everything,” and that is the feature.
- Allowed only on MCP/API. Even after some grants exist, the agent’s programmatic path is Allowed-only. It cannot escalate to Pending or Blocked data by asking cleverly, retrying, or inventing a broader scope.
- No self-widening. There is no agent-side path from “I need more mail” to “I now have more mail.” The human stays sovereign.
In defense-in-depth language: Mail is a blast-radius control on the data plane. Fewer untrusted messages in context means fewer injection attempts ever get a chance to run. That is real protection. It is not complete protection against injection as a class of attack.
What it does not do (crystal clear)
Not a jailbreak / model-alignment shield
Mail does not sit inside the model. It does not claim to detect jailbreaks, strip adversarial instructions, or guarantee that Allowed text is free of steering attempts. Model vendors and alignment research own that layer. We do not pretend otherwise.
Not “safe once Allowed”
If you Allow a sender or a message, that content can reach the agent. If that content contains an injection, Mail has already done its main job for that item: you chose to let it in. The remaining risk is model- and prompt-layer risk. Reduce it with good agent design, least-privilege tools, and judgment about what you Allow — not by claiming the trust wall rewrites reality after Allow.
Not a CASB, DLP suite, or enterprise content filter
We do not claim enterprise DLP/CASB replacement, full content scanning, or policy packs that classify every sentence. See Mail vs enterprise DLP / CASB / MCP gateways for the fair split. Mail v1 is single-tenant, one owner, one VPS: a controlled agent mailbox plus progressive authorization.
Not a guarantee against social engineering of the owner
If an attacker tricks you into Allowing something you should Block, the wall did what you told it to do. Default deny helps. It does not replace human judgment.
A useful mental model
Think in layers:
| Layer | Question | Mail v1 |
|---|---|---|
| Data boundary | Can this untrusted content reach the agent at all? | Yes — default deny, Allow/Block, Allowed-only MCP/API, no escalate |
| Model / prompt | If content is in context, can it steer the model? | Out of scope as a product claim |
| Tool / action | If steered, what can the agent do? | Keep tools least-privilege elsewhere; Mail does not invent action governance beyond Allowed reads |
Mail owns the first row. Conflating the first row with the second is how marketing overclaims get written — and how trust gets burned.
Practical habits that match the product
- Allow narrowly. Prefer specific senders and project addresses over “everything from this domain forever” thinking, even when the UI is simple. Habit matters.
- Block aggressively on first contact. Cold mail that asks the agent to ignore prior rules, exfiltrate secrets, or open links on your behalf is an easy Block.
- Remember Allowed is a grant record. In v1, what you Allowed is the answer to “what could my agent see?” Treat Allow as authorization, not as a temporary peek.
- Pair with honest agent design. Even with a tight Allowed set, don’t give the agent tools that can move money, send mail as you, or wipe systems without separate human gates.
None of that turns Mail into an alignment product. All of it uses the data firewall as intended.
Why honesty is the differentiation
Many products will eventually claim “protection against prompt injection.” Some will mean filtering. Some will mean model fine-tunes. Some will mean hope.
Mail means something narrower and checkable: untrusted content does not reach the agent until you Allow it; Allowed-only reads; the agent cannot escalate.
That helps against prompt injection by reducing exposure. It does not eliminate prompt injection for Allowed content. It is not a full LLM jailbreak / model-alignment shield.
People adopting AI who care about trust can work with that. Overclaim they cannot.
Start here
Tell your agent: start using Mail
start using Mail