Excessive mailbox access
A real Gmail or Outlook mailbox carries history, contacts and conversations the agent does not need.
Security overview
Security-first email infrastructure for AI agents
Mail4AI isolates AI agents from real corporate mailboxes while giving them controlled access to email-based workflows.
Designed for controlled pilots first: start on scoped, non-critical workflows, then expand with Team or Enterprise controls after review.
Threat model
The risks we reduce when agents enter email workflows.
Credential exposure
Agent prompts and onboarding documents should never contain mailbox secrets or OAuth tokens.
Email prompt injection
Inbound messages can include malicious instructions that must remain treated as external content.
Attachment risk
Files can be sensitive, malformed or hostile and need controlled exposure before an agent reads them.
Uncontrolled outbound actions
Replies must be constrained to approved recipients and auditable workflow boundaries.
Weak auditability
Security and platform teams need clear traces for inbound, outbound and policy changes.
Core controls
Mail4AI creates a governed email perimeter between the open email world and the agent runtime.
Dedicated inbox per agent or workflow
Each agent gets a separate address, identity and storage boundary.
Inbound allowlists
Only approved senders can reach the agent workflow you define.
Outbound allowlists
The agent can write only to explicitly approved recipients.
Deny-by-default model
Unknown senders and recipients stay outside the agent communication path.
Scoped MCP/API access
Runtimes read and send email through bounded tools instead of broad mailbox delegation.
Tenant and inbox isolation
Agent data is separated across tenants and inboxes to preserve future multi-tenant controls.
Audit logging
Inbound messages, outbound replies and sensitive policy changes remain traceable.
Secret separation
Runtime credentials stay outside prompts, Markdown onboarding and agent-visible content.
Architecture pattern
A controlled boundary before the agent sees email.
External sender
A customer, supplier or partner sends email to a dedicated Mail4AI address.
Policy boundary
Inbound rules decide whether the message belongs to the workflow.
Agent inbox
Accepted email is stored in the scoped inbox, separate from employee mailboxes.
MCP/API surface
The runtime reads the message through governed tools with explicit trust boundaries.
Audited response
Outbound replies pass recipient policies and remain visible in logs.
Data hosting and compliance
Hosted in France / EU
Production infrastructure is operated from France with an EU-first hosting posture.
DPA available
A data processing agreement is available for qualified customers and pilots.
Transport encryption
Public service endpoints use TLS in transit.
Retention by plan
Retention expectations are tied to plan level and pilot requirements.
No real mailbox credential exposure
Agents interact with Mail4AI inboxes, not direct corporate mailbox credentials.
Enterprise controls available during assisted pilots
SSO / SAML / OIDC
Integrate access with the enterprise identity stack when the rollout requires it.
RBAC and central policies
Prepare role-based administration and shared policies across teams.
Customer domain
Use customer-controlled domains with guided DNS and deliverability setup.
SIEM exports
Plan audit exports for teams that need centralized security visibility.
SLA and priority support
Align operating expectations before moving from pilot to production usage.
Security review
Review architecture, data flow and shared responsibility before broader deployment.
Shared responsibility
Mail4AI handles
- Infrastructure isolation
- Platform controls
- Audit logs
- EU hosting
Customers handle
- Workflow choice
- Allowlist configuration
- Human validation policy
- Internal AI usage rules
Security and legal references
Designed for controlled pilots first: start on scoped, non-critical workflows, then expand with Team or Enterprise controls after review.