What changes for security when your AI-built app runs in your own cloud

Some AI app builders now let teams run what they build inside their own cloud account. That can mean more isolation and control, and it also means more of the security work lands on your side. We'll look at one recent announcement for context, then walk through who owns what once an app runs in your cloud.

The announcement, in its own words

On October 16, 2026, Replit announced "Bring Your Own Cloud" (BYOC) for Microsoft Azure, Google Cloud and Amazon Web Services (Replit blog). We're describing it only as the post does, not reviewing it. The post lists three options and says each "gives your team a different level of responsibility for deployment and operations" (Replit blog):

• Full BYOC runs the full platform in your cloud tenant: compute, storage, the file system, integrations and the agent harness. The post says this lets your security team govern which internal resources the agent reaches and "apply controls to outbound connections." It's offered as a private preview to enterprise customers (Replit blog).
• BYOC for Published Apps hosts published projects in your cloud tenant while the vendor manages its platform. The post describes private endpoints, secure tunnels with mTLS that "only communicate outwards" from your infrastructure, infrastructure managed as code, support for your existing cloud security tools, and customer-managed encryption keys for customers whose agreement includes full physical isolation. It's in early access for enterprise customers (Replit blog).
• Image Exports give your team a Docker image, a Terraform file and an SBOM (a list of the software components in the image) to deploy yourself. The post says your team "deploys and operates the application" and must provide some building blocks the platform normally supplies, "such as managed auth, and connectors." It's in early access for enterprise customers (Replit blog).

The pattern is the useful part, whichever tool you use. The more of the stack you run, the more of the security work is yours. The post doesn't spell out who owns each item below in each option, so check that with your vendor.

Running in your own cloud isn't automatically more or less secure. It moves the work.

Shared responsibility, in plain English

All three major clouds use the same idea. The provider secures the cloud itself, and you secure what you put in it. AWS describes this as security "of" the cloud versus security "in" the cloud. For services where you manage the servers, AWS says the customer handles the guest operating system, "including updates and security patches" (AWS shared responsibility). Microsoft lists responsibilities you "always retain," starting with your data (Azure shared responsibility). Google Cloud notes that the split changes with the service type, and that even with fully managed services you remain responsible for your access controls and your data (Google Cloud shared responsibility).

Who owns what once you self-host

1. IAM (who can do what in your cloud)

Usually yours. You decide which people, services and deployment pipelines get which permissions. All three clouds recommend least privilege:

• AWS: "Apply least-privilege permissions" (AWS IAM best practices).
• Google Cloud: don't grant broad basic roles in production "unless there is no alternative" (Google Cloud IAM).
• Azure: grant users "the least privilege to get their work done" (Azure RBAC best practices).

If a vendor's tools deploy into your account, give that access only the permissions it needs, and review it regularly.

2. Secrets

Yours. Database passwords, API keys and signing keys belong in a managed secrets store, not in code, images or Terraform files:

• AWS Secrets Manager helps you "manage, retrieve, and rotate" credentials and API keys (AWS Secrets Manager).
• Google Secret Manager stores "API keys, passwords, or certificates" (Google Secret Manager).
• Azure Key Vault can "tightly control access" to tokens, passwords and other secrets (Azure Key Vault).

Plan for rotation from day one. If you use customer-managed encryption keys, you also own who can use and revoke them. The same rule applies before you deploy anywhere: a secret that ships in your frontend bundle is public, and our quick check for secret keys in a frontend bundle shows how to look. If a coding agent works in your repo, our Cursor guide covers keeping secrets out of its reach.

3. Patching

Often yours, depending on what you run. If you run servers, or container images you build yourself, keeping the operating system and dependencies updated is typically your job (AWS shared responsibility). Tools can automate this. For example, AWS Patch Manager "automates the process of patching managed nodes" (AWS Patch Manager). An SBOM, if you get one, helps you see what needs updating.

4. Auth (how your users sign in)

Yours if the platform's managed auth doesn't come with the app. The announcement says Image Exports require you to provide building blocks "such as managed auth" (Replit blog). Before launch, make sure sign-in, sessions and access rules work and have been tested. If your app uses Supabase, our Supabase RLS guide covers data access rules.

5. Logging

Yours to turn on, keep and review. Cloud audit logs record who changed what:

• AWS CloudTrail records actions taken by a user, role or service as events (AWS CloudTrail).
• Google Cloud Audit Logs answer "who did what, where, and when?" (Google Cloud Audit Logs).
• Azure has the activity log for subscription-level events (Azure activity log).

Decide where logs go, how long you keep them, and who reviews them. Keep secrets out of application logs.

6. Network exposure

Yours. You decide what's reachable from the internet. AWS security groups control "inbound and outbound traffic" (AWS security groups). Google Cloud firewall rules "allow or deny connections" to VMs (Google Cloud firewall rules). Azure network security groups allow or deny inbound and outbound traffic (Azure NSGs). Keep databases and internal services on private networks, and open only what users need. An outside scan can confirm what's reachable from the internet, but it can't see your IAM, secrets or logs. Our guide on how to judge a free security scanner explains what a scan can and can't tell you.

Practical checklist

• We know which option we're using and what the vendor still manages (ask in writing).
• IAM: people, pipelines and any vendor access have least-privilege roles, with no broad admin roles in production (AWS, Google Cloud, Azure).
• Secrets: all secrets live in a secrets manager, none are in images, code, Terraform or the frontend bundle, and rotation is planned (our check, AWS, Google Cloud, Azure).
• Patching: someone owns OS and dependency updates, on a schedule (AWS).
• Auth: sign-in and access rules are in place and tested with two accounts (our RLS guide).
• Logging: audit logs are on, kept, and reviewed by a named person (AWS, Google Cloud, Azure).
• Network: only the necessary ports are public, and databases are private (AWS, Google Cloud, Azure).
• We've read our cloud's shared responsibility page for the services we use (AWS, Google Cloud, Azure).

Running in your own cloud isn't automatically more or less secure. It moves the work. The checklist is about making sure every item has an owner.

Your turn

If your team has moved an AI-built app into its own cloud, which of these six areas surprised you most? Tell us. We'll use the answers in a follow-up guide.