Whose account does it act from when it sends an email?
Setup took an afternoon. Somebody clicked through a consent screen, chose a mailbox, and the agent began writing to clients that week. The screen said what it was granting, and nobody read it closely, because what was being agreed to was a demonstration working. Six months later your operations manager resigns. Her account is disabled on the Friday, and on the Monday something you rely on stops without saying why.
Sending is a permission with a shape
Every action an agent takes outside itself runs on somebody’s authority. In ArkOne’s reference design for an executive agent, the Cabinet, the roster of real people it works with is the Directory: each colleague with the addresses they write from and the approvals they may give, set out in the paper on the Directory.
That roster recognises people and routes approvals, and the reference design keeps it apart from credentials on purpose: the agent holds its own identity and its own authority to send, so a colleague’s presence on the roster grants the agent nothing.
The alternative is common because it is fast. Connect a mailbox and the agent can send today. The permission that lets it send is rarely the narrow one it needs, so it arrives able to read the archive, search it, and in most arrangements delete from it. Read the granted authority on a vendor’s consent screen and it reaches further than sending. The roster and its approval scopes sit on the Register.
Three accounts, three amounts of reach
Suppose the answer arrives three times over one afternoon, each time from an engineer describing a setup they have run themselves.
| What a good answer sounds like | What you will be offered instead | What that hides |
|---|---|---|
| It has its own account, provisioned by your administrators, with sending and nothing else | It sends from a shared mailbox | A mailbox with a history and a membership list. Ask who else is in it and what the agent can read that was written before it arrived |
| Read access, if any, is a separate grant to a named folder, and you can revoke sending on its own | It connects with your standard single sign-on | The way the door opens, not the width of it. Both answers are compatible with a grant covering the whole mailbox |
| Removing a colleague changes who approves, and stops nothing the agent does | It uses your admin’s account during setup and then runs on its own | Two claims. The first is the one that has consequences, and it is stated as a setup detail |
Exhibit 1. Illustrative. Three replies about the sending account, and the reach each of the weaker two quietly grants.
The second row is where careful buyers relax, for a sound reason: single sign-on is the correct way to authenticate and your security team asked for it. It describes how identity is proven. What was asked is what that identity may then touch.
The third row is worth writing down. An agent stood up on an administrator’s credentials, then said to run independently, makes a claim you can test in a minute: disable that administrator in a copy of your environment and see whether the agent keeps working. Where the claim holds, nothing happens. Where it does not, you have found a dependency on one person nobody at either company knew was there.
What to ask for before the consent screen
The follow-up is a screenshot. Ask for the consent screen your administrator will be shown, in advance, with every permission it requests listed.
Read it for verbs rather than nouns. Send is one permission. Read, search, modify and delete are others, and a request bundling them is a request for the mailbox rather than for the ability to write from it. Where the bundle is unavoidable because of how the mail provider works, that is a fair answer and a real constraint, and it belongs in your risk register with a named owner.
Then ask what the screenshot cannot answer: what your record shows about who authorised each send, the person whose credentials carried it or the person who approved the content. Those come apart the moment anything is disputed, and an account of its own keeps them apart. Set it beside whether it may sign as one of your staff, which asks about the name on the message rather than the authority underneath it.
An account is the smallest item in this negotiation and the one with the longest tail. It decides what stops working when somebody resigns, what a departing employee could be argued to have sent, and how much of your correspondence a supplier’s software has read since the afternoon it was installed.
component: answer-card
Asked plainly
Which email account does an AI agent send from?
Usually one of three: its own account created for the purpose, a shared mailbox the company owns, or a named employee's mailbox connected during setup. The third is the quickest to arrange and the widest in what it grants, because the permission to send from a mailbox is rarely separable from the permission to read it.
Does an AI agent need access to an employee's mailbox to send email?
It needs a way to send, which is not the same as a mailbox. A dedicated account, or a sending service the company controls, gives the agent the ability to send without giving it the ability to read years of correspondence. Connecting a person's mailbox is a convenience with a scope attached to it.
What happens to an AI agent when the employee whose account it uses leaves the company?
If the agent sends through that person's account, disabling their account on their last day stops the agent, usually without warning and usually in the middle of something. If the agent holds its own account, the departure changes nothing except who approves its work, which is what an orderly handover should look like.