How should security teams design human approval for AI agents that send email through shared inboxes?

Security teams should separate routine mail from higher-risk sends by applying policy at runtime, not just at login. Allow ordinary messages to proceed, block prohibited content such as credentials or financial data, and require human approval when the recipient is unfamiliar or the audience is broader than expected. The key control is evaluating the specific call, intent, and destination before the message leaves the mailbox.

Human approval for AI agents in a shared inbox only works if the control sits on the actual outbound action. A one-time login check does not tell you whether the current email is routine support mail, a sensitive disclosure, or a message that now reaches an unfamiliar recipient group. The decision point has to follow the message, the target, and the context.

That design matters because shared inboxes often blur ownership. The agent may have legitimate access to draft, triage, and reply, but not every reply should inherit the same trust. Runtime approval lets the team separate low-risk customer service from high-risk communications without blocking the workflow entirely.

When the approval gate is tied to the outbound send event, you can evaluate the specific call before the message leaves the mailbox. That is the right place to check destination, content class, and whether the agent is acting within the intended scope.

What should trigger human review in a shared inbox workflow?

The cleanest trigger set is based on risk, not on whether the sender is an AI agent. Ordinary messages should flow automatically when they stay within the expected audience and content pattern. Review should be required when the recipient is unfamiliar, when the email expands beyond the normal audience, or when the content crosses into protected categories such as credentials or financial data.

A practical policy usually combines content filters with destination rules. Content rules handle obvious red lines, while destination rules catch situations where a normal-looking message becomes risky because it is going to the wrong person, a new external contact, or a broader distribution list than the agent would normally use.

For teams that want a reusable control pattern, AI Agent Authorisation Guide is the most directly relevant internal reference because it centers on per-action approval, task-scoped access, and delegated authority. For broader identity design, Zero Trust for AI Agents reinforces the same runtime verification model: trust the request, not just the session.

How do you keep approval useful instead of slowing the mailbox to a stop?

Approval should be selective, fast, and explainable. If every send requires a person, the system becomes unusable and people will route around it. If nothing requires approval, the agent can act too broadly. The design goal is to reserve human intervention for cases where the blast radius or ambiguity rises above the normal service pattern.

That usually means the approval prompt should show the reviewer the exact recipient, subject, message body, and the reason for escalation. The reviewer needs enough context to decide quickly whether the message is expected, whether the audience is appropriate, and whether the content is safe to release.

Teams can strengthen the control by pairing approval with logging and auditability. If a message is approved, blocked, or rewritten, that decision should be attributable after the fact. For operationalizing that, AI Agent Observability, Audit and Incident Response Guide gives the right model for tracing agent actions and verifying what happened when a message was sent or stopped. When the mailbox can be abused as a control surface, this kind of traceability is what makes approval defensible rather than ceremonial.

Risk and Threat Considerations

Shared inbox approval becomes fragile when the control only protects access, not action. A compromised or overextended agent can still send a harmful message after a valid login, which turns the mailbox into a delivery channel for data exposure, impersonation, or social engineering. The risk is highest when the agent can contact external recipients or handle sensitive account material.

Failure mechanism: the agent inherits send authority and can execute a dangerous email at runtime because the policy does not inspect the specific message, destination, or content before transmission. That allows a legitimate session to produce an illegitimate action.

Impact: organisations can leak credentials or financial information, misdirect sensitive correspondence, or send convincing but inappropriate messages at scale from a trusted mailbox.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Human approval at send time prevents agents from abusing delegated mailbox authority.
	ASI09 — Human-Agent Trust Exploitation	Shared inboxes can exploit human trust if agent-sent email looks routine but is risky.
Recommendation — Enforce per-action approval when a message exceeds the agent's intended authority. Review messages that could mislead recipients or exploit assumed human trust.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Runtime approval limits the agent to the minimum send authority needed.
	AU-2 — Event Logging	Approval decisions and outbound sends need audit evidence for accountability.
	IA-5 — Authenticator Management	Shared inbox agents often rely on credentials or tokens that must be governed across use.
Recommendation — Restrict send authority so the agent can act only within defined bounds. Log approvals, denials, recipients, and content changes for each send. Rotate and scope the credentials that enable mailbox access and sending.

Practitioner Guidance

What to prioritise: Put the approval check on outbound send, not on mailbox login, and scope it to the smallest set of high-risk conditions that truly need human judgment. If you over-trigger the gate, users will ignore it; if you under-trigger it, the agent becomes a trusted sender with no meaningful brake.

What to verify: The reviewer should see the exact recipient, message content, and escalation reason before approving. If the UI does not make those three things obvious, the human check is too weak to rely on.

Practitioner takeaway: Good design preserves automation for ordinary mail while making the risky send path explicit, reviewable, and attributable at the moment the message leaves the mailbox.