SECURITY REVIEW
AI email agent security review: the questions to ask a vendor
Ask nine things: how tightly access is scoped, what triggers a run, what one run can read, who approves a send, how recipients are restricted, what rate limits apply, what the audit log lets you reconstruct, how fast access revokes, and who owns the agent day to day. A vendor who cannot answer these with specifics is not ready for a shared inbox.
Who this is for, and how to use it
This is for the person who has to sign off before an AI agent gets any kind of access to a shared inbox: a security reviewer, an IT owner, or the operator who will end up running the review queue day to day.
Take the nine questions below into a vendor call and write the answers down. A vendor that answers each one with a specific mechanism has thought about this. A vendor that answers with a general assurance — "we take security seriously", "it's designed to be safe" — has not given you anything you can evaluate.
None of these questions ask about certifications, audits, or compliance standards. They ask what the product actually does: what it can reach, what triggers it, who authorizes it, and how fast you can turn it off.
NINE QUESTIONS
The question groups, in order
- 01
Scope granularity
Can permissions be set per workflow, or only per integration as a whole?
WHY IT MATTERS
If access is granted once for the whole integration, every workflow you add later inherits the same broad reach. A risky use case ends up governed by the same rules as a cautious one.
WHAT A WEAK ANSWER LOOKS LIKE
“It has full inbox access”, or “granular permissions are on the roadmap” — treating a single all-or-nothing connection as adequate governance.
- 02
What triggers a run
What event starts a run, and how precisely can that trigger be scoped — a specific sender, domain, subject pattern, or label?
WHY IT MATTERS
A trigger that fires on anything resembling “new email” puts every message in the inbox through the agent, including the ones that should never reach it.
WHAT A WEAK ANSWER LOOKS LIKE
A description of what the agent does once it runs, with no description of what causes it to run or how to exclude messages from matching.
- 03
What one run can read
When a run starts, does it see the single matched message and thread, or does it get open-ended access to search or read the rest of the mailbox?
WHY IT MATTERS
This sets the blast radius of a bad prompt, a bug, or a compromised workflow. Standing access to the whole mailbox and access scoped to one matched thread are very different failure modes.
WHAT A WEAK ANSWER LOOKS LIKE
“It has read access to the inbox”, without describing what a single run actually receives when it starts.
- 04
Who authorizes a send
Can a workflow be configured to send only after a person approves it, and does that apply to every outbound message from that workflow or only some?
WHY IT MATTERS
Sending is the consequential, external-facing step. Whether approval is a foundational gate or an optional extra tells you how the vendor thinks about risk.
WHAT A WEAK ANSWER LOOKS LIKE
“It sends automatically once confidence is high” — substituting a model's confidence score for a person's decision.
- 05
How recipients are restricted
Can the system restrict or flag who a reply can go to, and is an added or changed recipient checked as its own event?
WHY IT MATTERS
An unintended or added recipient is one of the most damaging outcomes an email agent can produce. It needs to be a distinct, checked policy event, not incidental text inside a generated reply.
WHAT A WEAK ANSWER LOOKS LIKE
Recipients are mentioned only as part of “the agent writes accurate replies”, with no separate check described.
- 06
What rate limits apply
Is there a ceiling on how many actions a workflow can take in a given period, and what happens when it is reached?
WHY IT MATTERS
A limit caps the damage from a workflow that starts behaving in a way nobody expected, whether from a bad match, a loop, or a bug, instead of letting it continue unchecked.
WHAT A WEAK ANSWER LOOKS LIKE
No limit exists, or a limit resets silently with no notification to anyone.
- 07
What an operator can reconstruct from the audit log
From the log alone, can you tell why a run started, which rule it matched, what it was permitted to do, who approved it, and whether a repeated action is a retry of the same event or a new one?
WHY IT MATTERS
An incident investigation runs on the log, not on memory. A log that shows only “message sent” cannot answer why, under what permission, or by whose approval.
WHAT A WEAK ANSWER LOOKS LIKE
The log records outcomes (“reply sent”) but not the rule, the permission level, or the approver behind them.
- 08
How fast access can be revoked
Is there an immediate control to stop new runs, and does it act at the workflow level or only by disconnecting the whole integration?
WHY IT MATTERS
An incident needs a surgical stop. A control that only works by tearing out the entire integration turns off every workflow to contain one.
WHAT A WEAK ANSWER LOOKS LIKE
“Raise a support ticket”, or any answer that requires disconnecting the whole integration to pause one workflow.
- 09
Who owns the agent
Who inside your organization is accountable for the rules, exceptions, and pause decisions, and do they have direct visibility into the queue and the runtime?
WHY IT MATTERS
An agent without a named, visible owner accumulates unreviewed exceptions and a growing review backlog nobody is watching.
WHAT A WEAK ANSWER LOOKS LIKE
No named owner, or ownership sits with a team that has no visibility into the queue or the runtime day to day.
TAKE IT WITH YOU
Copy it, or download the plain-text version
The same nine questions, without the explanation, formatted to paste into a document or an email to a vendor.
AI EMAIL AGENT SECURITY REVIEW: QUESTIONS TO ASK A VENDOR DuoInbox — duoinbox.com/resources/ai-email-agent-security-questions/ Nine questions to take into a vendor call before letting any AI agent touch a team inbox. Write the answers down. 1. SCOPE GRANULARITY Can permissions be set per workflow, or only per integration as a whole? 2. WHAT TRIGGERS A RUN What event starts a run, and how precisely can that trigger be scoped — a specific sender, domain, subject pattern, or label? 3. WHAT ONE RUN CAN READ When a run starts, does it see the single matched message and thread, or does it get open-ended access to search or read the rest of the mailbox? 4. WHO AUTHORIZES A SEND Can a workflow be configured to send only after a person approves it, and does that apply to every outbound message from that workflow or only some? 5. HOW RECIPIENTS ARE RESTRICTED Can the system restrict or flag who a reply can go to, and is an added or changed recipient checked as its own event rather than read as incidental text inside the reply? 6. WHAT RATE LIMITS APPLY Is there a ceiling on how many actions a workflow can take in a given period, and what happens when it is reached? 7. WHAT AN OPERATOR CAN RECONSTRUCT FROM THE AUDIT LOG From the log alone, can you tell why a run started, which rule it matched, what it was permitted to do, who approved it, and whether a repeated action is a retry of the same event or a new one? 8. HOW FAST ACCESS CAN BE REVOKED Is there an immediate control to stop new runs, and does it act at the workflow level or only by disconnecting the whole integration? 9. WHO OWNS THE AGENT Who inside your organization is accountable for the rules, exceptions, and pause decisions, and do they have direct visibility into the queue and the runtime? A vendor who cannot answer one of these with specifics, rather than a general assurance, is telling you something. Weigh a vague answer the same way you would weigh a vague answer to any other security question. Related reading: https://duoinbox.com/guides/ai-email-agent/ https://duoinbox.com/guides/gmail-mcp-for-ai-agents/ https://duoinbox.com/controls/ https://duoinbox.com/security/
FAQ
Questions about this checklist
- Is this list specific to one vendor's product?
- No. Every question here applies to any AI agent that reads or acts on a shared inbox, regardless of vendor. None of it depends on a specific product's implementation.
- Does a vendor need a complete answer to every question before you evaluate them?
- Not necessarily. Some of these are roadmap items for an early-stage product. What matters is whether the answer is specific and honest about what exists today versus what does not, rather than vague or evasive.
- How is this different from asking for a security certification?
- A certification attests that an independent auditor reviewed a set of processes at a point in time. These questions ask what the product actually does — how access is scoped, what triggers it, and who can stop it. A vendor can hold a certification and still give a weak answer to a question here, and can give a strong answer here without holding one.
- Should this replace a written security policy or a formal vendor review?
- No. It is a starting point for the conversation, not a substitute for your organization's own review process, contractual terms, or data handling requirements.
DuoInbox early access
DuoInbox will face these same questions.
Bring triggers, permissions, review states, and audit activity into one shared operating surface.
Request early access