Bring Your Own Cloud (BYOC) for AI Agents: Deployment Models Compared

Bring your own cloud means running a vendor's software inside infrastructure you own, so the data stays in your account instead of theirs. For agent infrastructure the stakes are higher than for most software, because an agent inbox is not a send-only pipe. It stores threads, attachments and whatever the customer wrote back, and the agent reads all of it without a person in the loop.

Three deployment models exist. Hosted SaaS, where the vendor runs everything and your mail sits in their account. BYOC, where the software runs in your AWS, GCP or Azure account and the vendor still operates it. Self-managed, where you run it and you patch it.

The trade is the same in each case: how much of the compliance boundary you own against how much operational work you take on. BYOC sits in the middle, and it is the model that answers a residency requirement without making you the operator. AgentMail offers BYOC through Outposts, which runs in your own AWS account.

What is bring your own cloud (BYOC)?

BYOC means the vendor's software runs inside a cloud account you own and control, while the vendor keeps operating it. You own the account, the network, the encryption keys and the compliance boundary. The vendor ships releases, watches health, and fixes things when they break.

That middle position is the whole point, and it is what separates BYOC from self-hosting. In a self-hosted deployment you take delivery of a binary or a Helm chart and you are now the operator. You decide when to upgrade, you debug it at 2am, and you carry the risk of running a version the vendor stopped testing eight months ago. In BYOC the vendor still carries that. The split is usually described as control plane and data plane: the vendor's control plane orchestrates and observes, your data plane holds the data and does the work.

The term is overloaded, which is worth knowing before you search for it. In contact centres BYOC means bring your own carrier. In consumer software it sometimes means bring your own container or bring your own cloud storage. This piece is about the enterprise software deployment model.

Why are enterprise buyers asking for BYOC on agent infrastructure?

Because an agent inbox is a different risk object from a send API, and security teams worked that out faster than most vendors expected.

A transactional send API receives a payload you constructed, delivers it, and keeps a log. An agent inbox receives whatever anyone sends to that address. Customer replies with account numbers in them. Support threads with screenshots attached. Vendor invoices. Password reset links. Then the agent reads all of it, on its own schedule, with no person deciding which parts it should skip. That content sits in the inbox as a thread, searchable, for as long as retention allows.

The volume question arrived at the same time. HUMAN Security's 2026 State of AI Traffic and Cyberthreat Benchmark Report (March 2026) put year-over-year growth in agent traffic at 7,851 percent, with the caveat that 2024 volumes started from a very low base. Cloudflare's Matthew Prince said in June 2026 that automated traffic had reached 57.5 percent of requests to HTML content, a figure that covers all bot types rather than agents specifically. Neither number tells you how much agent email a given company handles. Both tell a security team that the category stopped being hypothetical.

So the question in the review stopped being whether to allow agent email and became where it lives. Data residency requirements, which used to be a European procurement detail, now show up in North American deals as a routine line item.

For enterprise deals specifically, this is often the deciding question. A mid-market buyer can usually accept hosted SaaS with a DPA. A bank, an insurer or a healthcare operator often cannot, and in those reviews the deployment model is not a preference but a gate: no acceptable answer on where inbound customer content lives, no deal.

Hosted SaaS, BYOC or self-managed: which model fits?

Most teams should stay on hosted SaaS. BYOC is worth the setup when a named requirement forces it: a residency clause, a customer contract that prohibits third-party storage of their content, or a security review that will not approve the deal otherwise. Adopting it because it feels safer is how you end up owning an AWS account nobody on your team wants to maintain.

What does a security review actually ask for?

The questions below are the ones that come up repeatedly, phrased close to how questionnaires phrase them. They are worth answering before the review rather than during it.

• In which region does the data rest, and can we pin it?
• Is content encrypted at rest and in transit, and who holds the keys?
• What egress exists from the deployment, to which destinations, and can we block it?
• What can the vendor reach in our environment, and through which path?
• How long are messages and attachments retained, and how do we force deletion?
• Which subprocessors touch the data, including the sending path?
• What is logged, where do logs go, and do they contain message content?
• Who is responsible for which part of incident response?
• What happens to the deployment if we terminate the contract?

Notice that only the first two are about storage. The rest are about the control path, which is the part BYOC changes most and the part vendors describe least clearly. A deployment sitting in your account is not private if the vendor's operator can open a shell into it and nobody is logging that.

Why is BYOC rare for email infrastructure?

Moving inbound email into a customer's account is harder than moving a database, and the reasons are structural rather than a lack of interest.

Sending reputation is shared and slow to build. A hosted provider warms IP pools across thousands of senders and manages the feedback loops, blocklist delistings and domain reputation that keep mail landing. Split that across a hundred separate customer accounts and you have a hundred cold reputations to warm, each with its own failure modes.

Receiving is stateful in ways sending is not. Inbound mail has to be accepted at an MX record, parsed, threaded against prior messages, indexed for search, and fanned out to webhooks with retries. That is a storage system, a search index and a queue, not a stateless API. Each of those has to be provisioned, upgraded and backed up inside the customer's account.

And the operational surface multiplies. Every customer environment is a version, a region, a set of IAM policies and a different idea of what outbound network access is acceptable.

This is why BYOC showed up first in categories where the data plane is one well-understood system. Confluent, Aiven and Redpanda offer it for streaming. Zep offers it for agent memory. Email arrived later because the data plane is several systems at once.

For the most part, it still has not arrived. Resend, SendGrid, Mailgun and Postmark run hosted services where your mail lives in the vendor's cloud. Mailgun and Nylas will pin data to a US or EU region, but the region sits inside their account, not yours. The self-managed route exists through open source like Postal or licensed software like EmailEngine, which puts you in the operator seat for parsing, storage and deliverability. Amazon SES runs under your own AWS account, but it is a sending primitive with limited receiving, so everything an agent inbox needs on top of it, threading, search, retention and webhooks, is yours to build and run. A vendor-operated BYOC deployment for full inbox infrastructure does not otherwise exist in the category.

How does AgentMail Outposts work?

An administrator picks an AWS region in the AgentMail dashboard and launches a CloudFormation stack. That stack creates the inbox infrastructure inside your account. Email content never leaves it.

Your application code changes by one line. Same API, same SDKs, one different baseUrl at client initialisation. Inbox creation, threading, search and webhooks behave as they do on the hosted service, because it is the same software.

AgentMail handles patching and upgrades remotely, so the deployment does not drift. Outposts is an enterprise-tier offering and is not available on self-serve plans. AWS was the supported cloud at launch in July 2026, with more planned. The full announcement is in Introducing AgentMail Outposts.

What does BYOC cost the vendor?

This is the part buyers rarely see, and it explains why the option is not on every pricing page.

BYOC moves risk down for the customer and operational work up for the vendor. Once your software runs in a hundred accounts you cannot log into, everything that used to be a deploy becomes a distributed systems problem. Rolling out a release means rolling it out to environments on different versions, in different regions, behind different network policies. Diagnosing a failure means getting telemetry out of an account that may not allow arbitrary egress. Rolling back means rolling back somewhere you have no console. When that layer is missing, recovery degrades into screenshots, copied logs and support calls, which is the failure mode Alien was built to remove.

Alien ships and operates vendor software inside customer AWS, GCP, Azure and Kubernetes accounts, with releases, telemetry, remote commands, rollback and revocation from a single dashboard. It is the deployment layer under a BYOC product rather than a product a buyer adopts directly.

For a buyer, the practical version of this is a question to ask any vendor offering BYOC: how do you ship a fix into our account, how do you see that it worked, and what happens if it does not. A vendor without a clear answer is offering self-hosting with a support contract attached.