Email for Agents
Create an inbox
Sign in Create an inbox

Nylas Agent Accounts Alternative: Compliance vs Controls

10 min read · Reviewed by Email for Agents Engineering · Nylas checked

Nylas wins on compliance paperwork, free quota, custom domains, calendar and existing-mailbox reach, and a procurement team should pick them. Pick Email for Agents when the human approval step has to be enforced by the server rather than written by you, and the agent's tool list has to shrink with its grant.

At a glance

Dimension Email for Agents Nylas
Compliance attestations They win this outright. A BAA is Enterprise only. None. We hold no SOC 2 report, ISO certification or HIPAA attestation SOC 2 Type II, ISO 27001, ISO 27701, HIPAA, CSA STAR Level One, PCI-DSS SAQ A
Free tier They win this outright. One live inbox and 100 email units a month per verified owner identity 3 Agent Accounts, 3,000 agent emails a month, 3 GB storage, 200 sends a day per account
Paid plans Builder and Team are proposed, not purchasable; checkout is disabled Essentials $15/mo, Pro $49/mo ($43 on annual), Enterprise by quote; Free, Essentials and Pro are self-serve
Custom domains Require a paid plan, and paid plans are not purchasable yet 1 on Essentials, 10 on Pro, 20 on Pro annual; free *.nylas.email trial subdomain
Calendar and existing mailboxes Neither. Agent-owned inboxes on agents.emailforagents.ai only Calendar, RSVP and Contacts on Agent Accounts; OAuth into Google, Microsoft, IMAP and more
Human approval before send Their MCP docs make the builder responsible for user confirmation. Server-held approval record, seven-day expiry, emits approval.requested and approval.rejected MCP send needs a prior confirm_send_message call; none of the seven documented rule actions holds a send for review
MCP credential and tool list OAuth connection grant only; six tools, filtered by grant Application API key as Bearer token; 38 tools listed; we found no documented per-credential tool filter
Testing without real mail Non-routable .mail.invalid inboxes, simulated transport, efa_test_ keys Trial-domain accounts send real mail; we found no non-transmitting test mode in their docs

Choose Nylas if

  • Procurement needs attestations. Nylas lists SOC 2 Type II, ISO 27001, ISO 27701, HIPAA, CSA STAR Level One and PCI-DSS SAQ A. We hold no SOC 2 report or ISO certification.
  • You handle protected health information and need a signed BAA. Nylas offers one on Enterprise; we offer none on any plan.
  • The agent must work inside mailboxes people already have. Nylas connects Google, Microsoft, Exchange, iCloud, IMAP and Yahoo accounts through one API.
  • The agent books meetings. Agent Accounts come with a primary calendar, RSVP and a Contacts API; we have no calendar at all.
  • You need volume or your own domain today: 3,000 free agent emails a month, and a custom sending domain from $15 a month.

Choose Email for Agents if

  • A send that needs review must stop on the server as an approval record, not rely on your agent calling a confirm tool first.
  • An agent granted read and draft must not see a send tool at all, because tools/list is filtered by the grant.
  • Every key holds named scopes from a vocabulary of 32, cannot exceed the human who created it, and narrows on the next request after that human loses access.
  • Your CI must exercise the inbound loop against a non-routable inbox whose efa_test_ key cannot reach live.

If your security review will not start without a SOC 2 Type II report, choose Nylas and stop reading. Nylas lists that report alongside ISO 27001, ISO 27701, HIPAA, CSA STAR Level One and PCI-DSS SAQ A on its own security page. We hold no SOC 2 report or ISO certification, and no HIPAA attestation either. That is the first fork, and for many buyers it is the only one that matters.

This page settles the other fork: when paperwork is not the gate, which Nylas Agent Accounts alternative gives you controls you can check yourself? It covers what Nylas actually ships for agents today, what it costs, and the one design difference that is not about quota. If you want the wider field, the comparison hub lists every vendor we have checked.

What Nylas Agent Accounts are in September 2026

Agent Accounts are new mailboxes, not connections to old ones. Nylas describes them as “fully functional email and calendar identities that you create and control through the API, with no user accounts to connect”. You create one with POST /v3/connect/custom and "provider": "nylas", the same endpoint Nylas uses for bring-your-own-authentication grants, or with nylas agent account create from their CLI. You get back a grant_id and use it in the path of every later call.

Three facts frame the rest of this page.

It is generally available. The Nylas pricing page carries the banner “Agent Accounts is generally available”, and the launch post is dated 17 June 2026.

Pricing is published. Free, Essentials and Pro are self-serve, every plan includes Agent Accounts, and only Enterprise is quoted.

It is more than email. Each Agent Account gets a primary calendar with event creation and RSVP, full CRUD through the Contacts API, system folders, and IMAP and SMTP submission so a person can open the same mailbox in a normal mail client. Addresses live on a domain you register with MX and TXT records, or on a free *.nylas.email trial subdomain that needs no DNS.

Alongside Agent Accounts sits the product Nylas is known for: OAuth into mailboxes people already own. Their getting-started guide lists Google, Microsoft, Exchange (EWS), iCloud, IMAP and Yahoo behind one API, plus Zoom for meetings. Both kinds of account are grants, addressed the same way in the API path, so one integration can serve an agent’s own mailbox and a person’s.

Where Nylas wins, plainly

Five rows in the table go to Nylas, and none of them is close.

Compliance. The Nylas security page lists SOC 2 Type II covering the security, availability and confidentiality criteria, ISO 27001, ISO 27701, CSA STAR Level One, PCI-DSS SAQ A for fully outsourced cardholder data, HIPAA and the GLBA Privacy Rule. The SOC 2 report is available under NDA through their trust centre at trust.nylas.com, and the page states independent penetration testing conducted annually. The Agent Accounts launch post says every account is covered by SOC 2 Type II, ISO 27001, ISO 27701, HIPAA and GDPR on every plan. One nuance for regulated buyers: the pricing page puts the HIPAA and HITECH BAA in the Enterprise column only, so the controls apply from the free plan but the signed agreement is a sales conversation. We have no report, no certificate and no BAA, and our security page says so in a list rather than a footnote.

Free quota. Nylas Free gives you 3 Agent Accounts, 3,000 agent emails a month, 3 GB of storage and 3 GB of bandwidth, with a cap of 200 sends a day per account and 30 days of inbox retention. Ours is one complimentary live inbox and 100 email units a month per verified owner identity, where a unit is one message received or one recipient sent to. Their monthly figure counts sent mail only and ours also counts every message received, so the real gap is wider than the thirtyfold the headline numbers suggest.

Paid plans you can actually buy. Essentials is $15 a month with 10 Agent Accounts, 10,000 agent emails and one custom sending domain. Pro is $49 a month, or $43 on an annual commitment, with 50 Agent Accounts, 50,000 agent emails and 10 domains (20 on annual). Pro bills overage at $0.40 per extra account ($0.20 annual) and from $0.80 per thousand extra emails ($0.70 annual); Free and Essentials are hard caps with no overage. Our Builder ($19) and Team ($79) plans are proposed launch prices and are not purchasable. Stripe checkout is disabled, which also means custom domains, which need a paid plan, are not something you can get from us yet. See pricing for the exact wording.

Calendar and contacts. An agent that schedules meetings needs somewhere for the invitation to land and a way to accept it. Nylas has that on the same grant as the mailbox. We have no calendar and no contacts API.

Existing mailboxes. If the agent assists a person inside their Gmail or Outlook, Nylas does that and we do not. Every inbox here belongs to the agent.

Where the send approval lives

This is the difference that is not about quota, and it is the reason this page exists.

Nylas’s hosted MCP server, at mcp.us.nylas.com or mcp.eu.nylas.com, lists 38 email, calendar, contacts and Notetaker tools. Its documentation says send_message and send_draft “require a preceding call to confirm_send_message or confirm_send_draft”, and that this “prevents your agent from sending email without explicit confirmation”. The tool list describes confirm_send_message as generating “the confirmation hash required before calling send_message”. Read that carefully. The confirm tool is in the same catalog as the send tool, and it is the agent that calls it. The same page’s security section warns that malicious content can “trick your agent into sending email”, then says: “You are responsible for implementing safeguards: Always require explicit user confirmation before sending email.”

That is an honest description, and the two-step call does catch a model that fires off a send by accident. As documented, though, it does not route the send to a person. An injected email that talks the model into sending can talk it into calling the confirm tool first.

Their server-side policy layer does not fill the gap either. Nylas Policies, Rules and Lists offer seven actions: block, mark_as_spam, assign_to_folder, mark_as_read, mark_as_starred, archive and trash. An outbound block returns HTTP 403, which is a real control. The non-blocking outbound actions, by their own docs, change only the stored sent copy, not what the recipient receives. None of the seven holds a message for review, so as documented an outbound message is either blocked or sent. Their Agent Accounts overview does describe a support agent where an LLM drafts replies and “humans approve the sensitive ones via a webhook flow”, which is the part you build yourself.

Here, the hold is a record on the server. When an inbox policy requires review, the send request returns HTTP 202 with "result": "approval_required", a draft_id and an approval_id, and the API writes an approvals row in state pending with an expiry seven days out, then emits approval.requested. A reviewer’s refusal emits approval.rejected. An approval moves the send on, which you observe as message.queued. Those are the two approval events this build emits. Two more names, approval.approved and approval.invalidated, are declared in the event catalogue and never fire, so do not build a handler for them.

The rest of the design hangs off that record. The approval is bound to a SHA-256 hash of the canonical payload, so a draft edited after review is refused with version_conflict instead of sent. Authority is re-checked when the decision is made, so revoking the agent’s key while its draft waits makes the approval fail. And a credential that holds drafts:submit without messages:send can compose a complete message that always lands in the approval queue, with reason code draft_only_principal. No agent-side call can skip that, because the agent has no call that sends. The mechanics are on controls and walked through in human approval for agent email.

A tool list that shrinks with the grant

The second half of the same argument is what the agent can see.

Nylas’s MCP server authenticates with a Bearer token carrying “your Nylas API key in the Authorization header”, which the page calls “the same key you use for direct API calls”, and the tool catalog on that page is one list. For data isolation it advises you to “configure your agent’s system prompt to ensure each user’s data is only accessed through their own grant”. Nylas’s API reference, explaining why the /grants/me/ shorthand does not work with API keys, notes that “there is no grant associated with an API key”. Nylas does document per-grant provider scopes for connected Google and Microsoft accounts, which limit what that grant can do at the provider. We found no documented way, on the pages listed below, to give an MCP session fewer tools or to scope the API key itself to one grant. That may exist somewhere we did not read. It is not on the MCP page, and that is where a builder would look.

Our MCP endpoint rejects API keys outright. The only credential it accepts is an OAuth connection grant tied to the human who authorised it. The server exposes six tools, list_inboxes, list_threads, list_messages, get_message, create_draft and send_message, and it filters tools/list by the grant before it builds the response, then re-checks the same rule in tools/call. A grant of read plus draft produces a session in which send_message does not appear, and create_draft cannot transmit mail. The model has nothing to be talked into.

A denied call is an audit line after the fact. An absent tool never had a name. That distinction is the subject of the MCP tool surface as a permission boundary.

Controls you can check without a report

A SOC 2 report is an auditor’s opinion that controls operated over a window. It is worth a great deal and we do not have one. What we can offer instead is narrower: every control below is stated in the API reference with the exact string or error it produces, so you can test it in an afternoon.

None of that replaces an attestation for a buyer who needs one. For a buyer who is allowed to judge on evidence, it is evidence they can reproduce. How to run that evaluation is laid out in evaluating agent email security without certificates.

Testing: which mailbox the message lands in

Nylas’s quickstart is built on real mail. A trial *.nylas.email subdomain works the moment you create it, and the guide has you send from the Agent Account and watch a reply arrive, noting that “the recipient sees a normal message from your Agent Account’s address”. That is the right design for proving deliverability. We found no test mode that stops transmission in the Agent Accounts docs we read. Their limits page does distinguish sandbox applications, at 1 request per second, from others at 5.

Our test inboxes take the other approach. They use a non-routable .mail.invalid address and a simulated transport, so an agent under test cannot email a real person. You inject inbound mail with the test:simulate scope through POST /v1/projects/{project_id}/test/inbound, and it lands in the agent’s own inbox. The allowance is small and stated: 3 active test inboxes per workspace, the last 100 messages, 10 MB, content expiring after 7 days. The CI pattern is in testing agent email without sending.

Neither approach is unique in the market. The question is whether your test suite should cross a real transport or not, and on that one the two products differ.

Choosing a Nylas Agent Accounts alternative by requirement

The reasoning behind the two lists at the top of this page fits in four questions.

Is there a questionnaire with a SOC 2 or ISO line on it? Choose Nylas. Nothing on this page changes that answer, and pretending otherwise would waste your procurement cycle.

Does the agent act inside a person’s existing mailbox, or book meetings? Choose Nylas. Their core product is connecting existing Google, Microsoft, Exchange, iCloud, IMAP and Yahoo accounts, and Agent Accounts add a calendar and contacts on the agent’s own grant.

Is volume or your own domain the constraint? Choose Nylas. 3,000 free agent emails a month against our 100 units, and a custom domain for $15 a month against nothing purchasable here.

Is the constraint that a hostile email must not be able to cause a send? That is the case for us. Nylas gives you an agent-called confirm step and a block rule, and leaves the human in the loop to your code. We put the human in the loop on the server, as a record with an expiry, a payload hash and a re-check of authority, and we remove the send tool from any MCP session whose grant lacks messages:send.

If that last question is the one keeping you up, start with the free inbox and the sending controls docs, point a hostile test email at a read-and-draft agent, and check that send_message is not in its tool list.

Sources

Everything stated above about Nylas was read from these pages on . Products change; if a claim here is stale, it is a bug worth reporting.