An agent can send. It cannot grant itself permission.
Handing an AI agent the ability to send email is reasonable — receipts, password resets, and order confirmations are exactly the work agents should carry. The question is what the agent can do beyond sending. Marmunk’s design answer: the agent operates inside an envelope it cannot change, and anything that widens that envelope requires a human.
The approval boundary
In Marmunk, an agent can send within approved limits and read its own send outcomes. It cannot approve a new sending domain, raise rate or volume limits, manage suppression, or mint new credentials for itself. Those are human operations in the dashboard, deliberately outside the tool surface the agent sees.
This is not a UI accident — it is the product’s core boundary. The MCP server and the REST API expose only the operations a workflow needs to run; the operations that change what the workflow is allowedto do are separated out. An agent that has been prompt-injected, or that simply reasons its way to “more capacity would help,” has no path to act on it.
Hard caps, not soft quotas
Every plan is a hard cap: monthly recipients, daily recipients, sending domains. When the envelope is exhausted, sends fail closed — the API returns a limit error rather than quietly sending beyond it. There are no metered overages, so there is no failure mode where a runaway agent loop runs up a bill or floods recipients.
A failed send is also a visible send: it appears in the trace with its status, so a human reviewing the account sees both the runaway loop and where it stopped.
Scoped, expiring credentials
Agents authenticate two ways: hosted MCP with OAuth (the human connects the agent once, interactively), or headless Bearer Agent credentials created in the dashboard and given an expiry. Either way the credential is scoped to email send/read for one tenant — it is not an account master key, and it cannot manage domains, billing, or other credentials.
Because agent credentials are separate from human ones, rotating or revoking an agent’s access never touches the rest of the account — which makes “demote the agent, keep the product running” a one-step operation.
The safety checklist
Before connecting an agent to any email system — Marmunk or otherwise — check five things:
1. Can the agent change its own limits or add sending domains? (In Marmunk: no.) 2. Is the credential scoped and expiring? 3. Are volume caps hard (fail closed) rather than soft (bill overages)? 4.Does the agent report outcomes in the status system’s own vocabulary, or paraphrase “accepted” into “delivered”? 5. Is there a durable, inspectable record of every send the agent attempted?
Read Connect your agent for the credential setup, and Accepted vs delivered for why outcome vocabulary matters.