How do we hand an AI agent an email API key without giving it our sending reputation?

We do not hand it the key that sends our own mail. It gets a separate key that can send and nothing else, with a ceiling it cannot raise. We have not handed that key to an agent yet.

WarmySender's own outbound mail is small and load-bearing. Sign-in codes, lifecycle notes, mailbox health alerts, and workspace invites. Some of those notes are no longer triggered by a person pressing a button. A detector decides that a mailbox health alert or a bounce cooldown notice should go out. A detector that starts re-firing sends the same note to the same person until something outside the detector stops it.

Today that something is code we wrote in our own application. Alerts fold into one open row, with a counter, so a chronic condition does not page us forever. That fix lives in our code. It does not live in the sending layer, which will deliver whatever we hand it. And a sign-in code and a win-back note travel on the same key. If the win-back job misbehaves at two in the morning, sign-in is inside the blast radius. That is the reputation problem we are solving. It is our mail, not a general essay about agents.

The key, when we hand one over

Three properties. We will not skip any of them.

The key can send, and sending is the whole of what it can do. It cannot edit its own ceiling, and the published line is that no request the agent makes raises one. A bug in the agent can only do what that key is allowed to do. Sign-in mail gets its own key, with its own ceiling, so an alert job cannot spend the credential that lets a customer into the product.

The ceiling is a count of sends for a period, hourly, daily, or monthly, plus a separate per-minute rate. We have not chosen our numbers. The sample body on the public page is not a figure we have committed to. What we are committing to is the shape: the agent cannot raise either number, a spent ceiling refuses the send, nothing is queued behind that refusal, and the refusal names what a person can do next. A retry is not one of those things. The refusal says waiting will not help.

The loop guard sits under the key, not inside the agent. The published line is four identical sends inside 60 minutes. The send that crosses that line is held for a person. It is not dropped on the floor, and it is not delivered. The agent is told the send is waiting, and told which call a person uses to release it or to leave it there. A guard we write in the same process as the agent is a guard the agent's bug can skip: a retry that builds a new client, or a second script that copied the key, never sees it.

The stop is one request. A person turns it on, and only a person turns it off. It can cover one key or every key on the account. Stopping our own mail in a hurry today means a deploy or a settings change. That is the wrong tool at the moment you need it, which is the reason the stop has to be a request and not a release.

What a refusal is for

The useful part of a refusal is that it names the next action. A fair amount of our integration work, on every sending path we have used, has been translating a terse failure into something a person can do. A ceiling refusal tells you the period is spent and that raising it is a person's decision. A held send tells you a person has to look. A stopped key tells you a person already did. An agent that reads all three as "try again" will fill a queue or hammer a ceiling. The integration cost is handling those three answers. If we never hit them, we have lost nothing. If we hit them, we found a detector before a customer did.

The honest limit

AgentiSend is built by the same team as WarmySender, so this is a decision from the people who built both, not a review and not a rating. The product is live and sending real mail. Our own notification mail is not part of that. The path those messages use today is the path they used last month. We are publishing the method before the handoff on purpose. A warmup company that described a plan as a finished result would be doing the thing we tell customers not to do.

There is a second limit, and it is the one that keeps this from being a slogan. A ceiling bounds volume. It does not read the alert and decide the detector was wrong. A well-formed email that should never have been sent still leaves, until it repeats often enough to be held or until it spends the ceiling. We still have to fix the detector. The sending layer will not do that for us.

We also will not use this for mail nobody asked for. There is no lead list on this path, and we are not adding one. Our notification mail goes to people who already have an account.

We would not hand an agent a key on a domain we have not watched. The companion to this note is the view we insist on seeing before any of our own customer mail moves: the published bounce and complaint lines, and the daily authentication rows. Until that view has our own mail in it, the key stays with a person.

The controls are written up at email guardrails for an agent, and the product is at agentisend.com.