credential isolation in multi-tenant agent email systems

Your agent handles email for twelve tenants. Tenant A's SMTP password sits in the same memory space as Tenant B's OAuth token. One overly broad IAM role, and Tenant A's agent starts sending messages through Tenant B's credentials.

This isn't theoretical. Shared credentials in multi-tenant systems are the fastest path to a breach that hits every customer on your platform, not just the one where the bug lives. When the shared resource is email, the damage compounds: leaked credentials mean forged messages and destroyed sender reputation, on top of compliance exposure you can't brush off.

How to implement credential isolation for multi-tenant email agents#

Credential isolation in multi-tenant email agent systems means each tenant's authentication secrets (SMTP passwords, OAuth tokens, API keys) are independently stored and accessed so no agent session can touch another tenant's credentials. The most effective approaches are:

1. Per-tenant IAM roles with scoped permissions
2. Session-scoped tokens injected at agent invocation
3. HSM-backed key vaults for credential storage
4. Email-domain-to-tenant mapping for automatic routing
5. MCP tenant context propagation
6. Envelope-level isolation on every outbound message

Each method addresses a different layer of the problem. Most production systems combine three or more of them.

Per-tenant IAM roles#

The simplest architectural boundary is a dedicated IAM role per tenant. When an agent session starts, it assumes a role that grants access only to that tenant's credential store, sending quota, and inbox data. AWS Prescriptive Guidance recommends this pattern for multi-tenant agent systems: the role's policy explicitly denies access to resources tagged for other tenants.

This works at the infrastructure layer but doesn't cover application logic on its own. An IAM role controls what the agent can access. It doesn't control what the agent does access within your code. You need both.

Session-scoped tokens#

When your orchestrator invokes an agent for a specific tenant, it should inject a short-lived, tenant-scoped token into the session. This token authenticates the agent to your email infrastructure and expires when the session ends.

The flow: your control plane receives a request for Tenant C. It mints a token scoped to Tenant C's inboxes and credentials, passes it as a session attribute, and the agent uses only that token for the duration of the task. If the agent calls the email API with a different tenant's scope, the request fails.

Microsoft Entra ID uses a similar approach for multi-tenant applications, where cross-tenant access settings restrict which identities can authenticate across boundaries. The same principle applies to agent sessions: scope the credential at invocation time, not at configuration time.

HSM-backed key vaults#

Storing tenant credentials in plaintext (or even in encrypted environment variables) creates a single point of compromise. One breach of the agent's runtime, and every tenant's secrets are exposed at once.

Hardware Security Modules fix this by holding encryption keys in tamper-resistant hardware. Each tenant's email credentials are encrypted with a unique key inside the HSM. The agent requests decryption at runtime, and the HSM enforces access policies before releasing the plaintext. Even if someone dumps the agent's memory, credentials for other tenants remain encrypted with keys that can't be extracted.

This is the blast radius question: if a credential leak happens, how many tenants are affected? With per-tenant HSM keys, the answer is one. Without them, the answer is usually all of them.

Email domain as a tenant signal#

Mapping email domains to tenants gives you an isolation mechanism built into the protocol itself. When an agent receives a message addressed to support@tenant-a.com, the domain tells your routing layer which tenant context and credentials to load.

This is where the security risks of sharing your inbox with an AI agent become concrete at scale. If multiple tenants share a single inbox or domain, there's no domain-level signal to enforce isolation. Each tenant needs its own sending domain, or at minimum its own inbox address with clear tenant mapping in your routing layer.

MCP tenant context propagation#

The Model Context Protocol provides a standardized way for agent clients to pass context to tool servers. In a multi-tenant email setup, the MCP client includes the tenant identifier in the request context. The MCP server uses that identifier to fetch tenant-scoped credentials and enforce tenant-specific rate limits, logging every action against the correct tenant.

AWS's multi-tenant architecture guidance shows this pattern: tenant context flows from client to server, and the server acquires scoped credentials from the identity service based on that context. The agent never touches credentials outside its current session's scope.

Envelope-level isolation#

Credential isolation covers authentication. But email has another layer that matters just as much: the message envelope.

The SMTP envelope (MAIL FROM, RCPT TO) determines routing and reputation attribution. If two tenants share a sending IP and one of them sends spam, both tenants' deliverability tanks. Envelope-level isolation means each tenant's messages carry distinct sender identifiers, ideally from separate domains or subdomains, so bounce rates and spam complaints land on the correct tenant.

What happens when your AI agent sends email from your personal inbox shows the damage when sending identity isn't properly scoped for a single user. Multiply that across a multi-tenant platform, and one tenant's bad behavior poisons everyone's reputation.

Silo, pool, or hybrid?#

The three standard multi-tenant architectures handle credential isolation differently:

For high-volume AI email agents, the hybrid model usually wins. You get cost efficiency from shared compute with isolation guarantees from separate credential storage. The agent runtime is shared, but every credential retrieval passes through a tenant-scoped access layer.

Credential rotation without downtime#

Here's the gap most teams discover too late: how do you rotate a tenant's email credentials without breaking active agent sessions?

The cleanest approach is dual-credential windows. When rotation starts, provision the new credential alongside the old one. Active sessions continue with the old credential until they finish. New sessions pick up the new one. After a grace period (a few minutes is typical for email operations), revoke the old credential.

Queued outbound messages make this harder. Messages authenticated with the old credential need to either send before revocation or re-authenticate with the new credential at send time.

Practical recommendations#

If you're building a multi-tenant system where AI agents handle email, credential isolation isn't something you tack on later. It's the difference between a contained incident and a breach notification to every customer on your platform.

Start with per-tenant tokens injected at session invocation and separate sending domains per tenant. Add an HSM or managed key vault for credential storage. This layered approach (sometimes called defense in depth) means no single failure compromises tenant boundaries. Layer in MCP context propagation if your agents use tool servers, and envelope-level isolation if tenants share sending infrastructure.

LobsterMail handles several of these concerns at the infrastructure level. Each inbox gets its own scoped credentials, sending reputation is isolated per account, and the API enforces tenant boundaries on every request. If you're building agent email and don't want to architect credential isolation from scratch, get your agent its own isolated inbox here.