I'm building software that may need to run inside a customer's VPC for on-premises or BYOC deployments. I'm concerned that if the services run directly in their environment—such as in Docker on EC2 or in Kubernetes—the customer could use root or administrator access to inspect containers, binaries, images, or runtime memory and recover the underlying code.
If I don't split the system into separate control and data planes, what practical options are available for protecting the intellectual property? Would this require building a hardened operating system image with signed artifacts, attestations, and key verification throughout the deployment process? Are technologies such as Nitro Enclaves, confidential computing, or GPU confidential-computing features appropriate, or is there a more realistic approach?
4 Answers
Confidential-computing technologies, signed images, measured boot, attestation, and hardware-backed key release can improve trust in the execution environment, but they have important limits. They only help when the hardware and management boundary are genuinely outside the customer’s control and the platform supports the needed guarantees. If the customer owns or administers the host and can control the surrounding infrastructure, assume a determined administrator may still find ways to observe or replace components.
Treat this as a business and product-design problem as much as a technical one. Contracts, licensing, audits, access controls, tamper evidence, support agreements, and regular updates can discourage misuse, but they are not a cryptographic barrier. The defensible value is often the service, operational expertise, integrations, ongoing maintenance, and rapid improvements rather than assuming the deployed software can be kept completely unreadable.
The strongest architectural option is to keep the proprietary control plane or sensitive logic in infrastructure you operate, while placing only the minimum data-processing components inside the customer’s environment. Private connectivity, peering, or similar networking can work when the customer allows data to leave their environment, but that doesn’t help if their requirement is that the data never leaves their VPC.
If the customer controls the machines, operating system, cloud account, and administrators, you can’t guarantee that your code will remain secret. They may be able to inspect binaries, attach debuggers, read memory, or reverse-engineer the behavior eventually. Compiling the application or packaging it in a container only raises the effort slightly; it doesn’t provide strong protection.
The customers specifically require their data to stay inside their own VPC, so a service-to-service connection to infrastructure we operate isn’t acceptable for this deployment model.