Nuvrail puts a human approval step between an AI agent and its email writes. The open-source, AGPL-3.0 project acts as an IMAP/SMTP proxy: reads pass through, while sends, moves, deletes and flag changes wait for explicit approval, according to its GitHub repository.
The agent connects to Nuvrail as though it were a normal mail server. Nuvrail then connects to the real server, putting the approval boundary in the email connection instead of relying on instructions telling the model to ask permission.
An October 28, 2026 listing surfaced the project as a Show HN submission. That establishes a discovery date, not a confirmed launch date; the repository evidence does not identify the original announcement timestamp.
The design detail worth noting is that Nuvrail lets the agent continue before approval arrives. That makes the workflow more practical, but creates two states to reconcile: what the agent believes it has done and what has actually happened to the mailbox.
How the Proxy and One-Tap Review Work
IMAP handles mailbox access and organization; SMTP handles outgoing mail. Nuvrail sits in both paths, so it can intercept changes without requiring an agent-specific approval integration. A client still needs to support these protocols and be configured to use the proxy.
The README describes this sequence:
- An agent requests a write, such as moving a message to Trash or sending an email.
- The gateway intercepts it and immediately returns
OK [STAGED]. - A phone or browser notification presents the proposed action.
- A human approves or rejects it.
- Approval causes execution against the real server. Rejection reverts the proxy’s local state and is surfaced to the agent on its next command.
That staged acknowledgment carries weight. It means the proxy has accepted a proposal, not that the mail server has completed the operation.
| Agent operation | Nuvrail’s documented handling |
|---|---|
| Read mail | Passes through without human approval |
| Move a message | Staged until approved |
| Change flags, including a deletion flag | Staged until approved |
| Send outgoing mail | Staged until approved |
Issue EXPUNGE to permanently remove deleted messages | Blocked at the gateway |
The distinction between marking a message deleted and permanently removing it matters. In IMAP, \Deleted is a flag; EXPUNGE removes messages marked for deletion. Nuvrail says it stages the former and blocks the latter. An approved deletion flag should therefore not be interpreted as permission for the agent to issue a permanent purge.
The project website broadly describes the agent proceeding after approval. The README gives the more precise operational account: the agent can keep working while writes wait. I’d use that documented behavior when designing an integration, because a successful-looking client response must not become evidence that an email was delivered.
Staged State Is the First Thing to Test
Nuvrail’s promise to revert local state after rejection creates a concrete consistency requirement. The proxy must preserve a useful working view while preventing unapproved changes from reaching the mailbox.
Consider an agent that proposes moving a message, then continues with another action involving that message. If the move is rejected, the second action may depend on a mailbox state that never became real. This is a test scenario derived from the documented staging model, not a reported Nuvrail defect.
Several cases deserve explicit acceptance tests:
- Dependent actions: Stage a move followed by another operation on the same message, then reject the move.
- Conflicting decisions: Approve one proposed change and reject another involving the same message.
- External changes: Modify the mailbox from a separate client while an approval is pending.
- Reconnection: Disconnect and reconnect the agent before a decision, then check how pending and rejected actions appear.
The README says rejection is surfaced on the agent’s next command. Teams should verify what their particular client and agent do with that information. A model that interprets rejection as a temporary error could simply propose the same action again.
My view is that this is the central integration test: can the agent distinguish proposed, approved, executed and rejected? Human approval protects the mailbox only if the surrounding workflow also handles those states correctly.
The approved action should also remain tied to what the reviewer saw. Tests should check whether changes to recipients, message content or destinations require a new decision. The supplied documentation does not establish those binding guarantees in detail.
Credential Protection Determines Whether the Gate Holds
Nuvrail’s approval boundary works only for traffic that passes through it. An agent with a separate route to the mail provider could bypass the proxy entirely.
That makes credential handling an architectural concern. Teams should establish which credentials the agent receives, which credentials Nuvrail uses upstream, and whether the agent can reach the provider through another tool or API.
A useful deployment review should cover:
- Where upstream mail credentials are stored and which processes can retrieve them.
- Whether secrets can appear in logs, backups, environment dumps or agent-visible files.
- How credentials are revoked or rotated.
- Which interfaces are exposed to the network and where transport encryption terminates.
- Whether the agent retains any direct mailbox access outside Nuvrail.
These are deployment requirements inferred from the proxy architecture, not claims that Nuvrail has a particular credential weakness.
Self-hosting gives the operator control over the approval service, but it also places that service inside the operator’s security perimeter. The gateway and approval account become sensitive infrastructure: compromising either could undermine the protection the proxy is intended to provide.
There is also a clear scope limit. Because reads pass through, Nuvrail is not a confidentiality boundary against an agent reading sensitive mail. It controls the documented write path. Access to message contents still needs its own authorization decisions.
Notification Privacy Extends Beyond Encryption
Nuvrail says notifications present an action summary with the subject, sender and destination. The repository also describes notification payloads as end-to-end encrypted and says email bodies are fetched only after authentication. These are project claims, not independent security findings.
Those details create two separate privacy questions: what notification infrastructure can access, and what a person near the receiving device can see.
| Review detail | Privacy question to test |
|---|---|
| Subject | Can sensitive project, customer or personnel information appear on a lock screen? |
| Sender | Does the preview reveal a confidential relationship? |
| Destination | Could a recipient address or mailbox location expose internal activity? |
| Message body | Does access consistently require authentication, including after a session expires? |
End-to-end encryption can protect a notification payload in transit while leaving the decrypted preview visible on an unlocked device or lock screen. Those are different boundaries.
I’d keep the notification minimal and put sensitive details behind an authenticated review screen where practical. The basis is straightforward: an approval alert needs enough context to attract attention, but it does not necessarily need to expose an email subject to everyone near a phone.
Reviewers still need sufficient information to make a meaningful decision. For an outbound send, that means checking what the review interface reveals about recipients and content. A fast approval button is useful only if the person tapping it understands what will leave the mailbox.
Approval Outages Must Not Become Permission
The supplied documentation does not establish detailed guarantees for every approval-infrastructure outage. Teams should distinguish an unavailable notification channel from an unavailable approval UI, gateway or upstream mail server.
Frequently Asked Questions
3 questions
1Does Nuvrail Require a Custom Agent Integration?
It is designed to work through standard IMAP/SMTP connections. The client must be configured to use Nuvrail’s proxy endpoints, and its handling of staged responses still needs testing.
