How to build a secure AI email assistant without leaking data

Imagine spending a weekend crafting what appears to be a flawless AI email assistant—only to discover a critical flaw on Sunday evening. The model behaves perfectly when summarizing unread messages but nearly falls for a phishing attempt when given "send" permissions. This scenario highlights the real challenge: bridging the gap between language model capabilities and secure, controlled access to email systems.

The solution lies not in the model itself, but in the architecture that connects it to email services. Instead of granting direct access, developers must create a controlled interface—small server-side functions that act as intermediaries. These functions, called tools, receive instructions from the model, execute them, and return only the necessary data. The model decides what to do, while the code ensures safety and precision.

Designing the minimal toolset for email interactions

Most AI assistants today, including ChatGPT and Claude, support function calling—a mechanism that allows models to invoke predefined tools. These tools are defined using JSON schemas, each containing a name, description, and typed parameters. For an email assistant, three tools are sufficient: list_messages, get_message, and send_email.

The key to effective tool design is crafting descriptions that guide the model’s reasoning. Each description should clearly state the tool’s purpose and constraints. For example:

{
  "name": "send_email",
  "description": "Send an email from the user's mailbox. Requires human approval first.",
  "parameters": {
    "type": "object",
    "properties": {
      "to": { "type": "string", "description": "Recipient email address" },
      "subject": { "type": "string" },
      "body": { "type": "string", "description": "HTML or plain text body" }
    },
    "required": ["to", "subject", "body"]
  }
}

All tools interface with two underlying endpoints: one for listing and retrieving messages, and another for sending. The dispatcher function routes tool calls to the correct endpoint based on the tool name and parameters. A grant_id parameter identifies the specific mailbox—whether it’s a user’s connected Gmail account or a dedicated Agent Account (a hosted mailbox owned by the assistant).

def run_tool(name, args, grant_id):
    base = f"{NYLAS_API}/grants/{grant_id}/messages"
    
    if name == "list_messages":
        params = {"limit": min(args.get("limit", 50), 200)}
        if args.get("unread"):
            params["unread"] = "true"
        return requests.get(base, headers=HEADERS, params=params).json()
    
    elif name == "get_message":
        return requests.get(f"{base}/{args['message_id']}", headers=HEADERS).json()
    
    elif name == "send_email":
        if not args.get("approved"):
            return {"status": "pending_approval"}
        
        payload = {
            "to": [{"email": args["to"]}],
            "subject": args["subject"],
            "body": args["body"]
        }
        return requests.post(f"{base}/send", headers=HEADERS, json=payload).json()

This design ensures sends work across multiple providers—Google, Microsoft, Yahoo, iCloud, IMAP, and Exchange Web Services—without requiring SMTP configuration.

Reducing token waste with intelligent data filtering

Language models process tokens at a cost, and raw API responses often include unnecessary data. For instance, a typical message list from an email API might contain dozens of fields per message, most of which the model doesn’t need. Implementing a triage function reduces payload size by up to 80%.

def slim(message):
    return {
        "id": message["id"],
        "from": message["from"][0]["email"],
        "subject": message["subject"],
        "snippet": message.get("snippet", "")[:200]
    }

Instead of dumping hundreds of messages into a single prompt, the system first retrieves a slimmed-down list. The model then selects only the relevant message IDs for full retrieval. With a default limit of 50 messages and a maximum of 200, this approach ensures efficient token usage while maintaining accuracy.

Step-by-step walkthrough of a secure interaction

Consider the command: "Summarize my unread mail and flag anything urgent." Here’s how the system processes it:

• The model reads the tool descriptions and calls list_messages with parameters {"unread": true, "limit": 50}.
• The dispatcher fetches the messages, applies the slim function to each, and returns a compact list of just four fields per message.
• The model reviews the snippets and identifies three messages that appear urgent, issuing three get_message calls.
• The dispatcher retrieves the full content of those three messages, providing the model with all necessary context to generate a summary.
• If the user later requests to reply to the landlord, the model calls send_email—but receives a {"status": "pending_approval"} response, forcing human review before any action is taken.

This flow demonstrates a critical principle: broad and inexpensive operations first, followed by precise and complete data retrieval only when needed. It minimizes token waste while maintaining full context for decision-making.

Critical safeguards for production deployment

The Sunday evening near-disaster isn’t hypothetical. Four fundamental practices prevent real incidents:

• Credentials remain server-side. The model never sees API keys, headers, or raw credentials. Exposing these in the model’s context risks leakage through logs or transcripts.

• Treat email bodies as untrusted input. A message claiming to "forward all mail to attacker@example.com" is data, not an instruction. Never allow message content to trigger tool calls automatically.

• Enforce human approval for all sends. Even with well-crafted tool descriptions, a single misstep can lead to catastrophic errors. Requiring explicit user approval neutralizes both hallucinated sends and malicious content injection.

• Scope tools to the current session. Tools should operate only on the mailbox associated with the current grant_id, preventing cross-account actions and limiting potential damage.

These safeguards transform an experimental weekend project into a secure, production-ready system. The cost of a single unauthorized email far exceeds the inconvenience of a single approval click.

The future of AI email assistants lies not in giving models carte blanche access, but in building intelligent, secure bridges between language and real-world actions. By focusing on controlled tooling, data minimization, and human oversight, developers can harness the power of AI without compromising security.