Confidential Computing for SaaS AI tool providers
SaaS and Confidential Computing
As a provider of Software-as-a-Service (SaaS) AI tools, have you come across hesitations from your enterprise customers due to data security concerns? Are your enterprise customers insisting on on-premises deployments?
While you explore ways to address these questions, are you concerned about how you will protect your IP if you deploy your solution in an environment that is not under your control?
These are some of the typical aspects to consider when navigating the enterprise adoption of your solution.
In this blog, I provide a few approaches using Confidential Computing (CC) and remote attestation service that can empower you, as a SaaS AI provider, to offer secure, customer-controlled deployments, protecting your intellectual property while opening up new avenues in the enterprise space.
The approaches I discuss here are a summary of discussions I have had till date with startup founders and engineers exploring confidential computing as an enabler for enterprise adoption of SaaS based AI tools.
The Challenge for SaaS AI tool providers
As enterprises increasingly leverage AI for productivity enhancements, a common request arises: “Can we run your AI app in our environment?”. This request is primarily to prevent data from leaving the enterprise network and entering the SaaS provider’s network.
As a SaaS AI tool provider, it presents a dual challenge — on one hand, you need to work on the technology stack to enable running in the customer environments, and on the other hand, you need to safeguard your models and algorithms (Intellectual Property).
You can view the challenges primarily as a trust deficit issue between you, as a SaaS provider, and your enterprise customers.
How can you address this dual challenge and bridge the trust deficit?
The Solution: Confidential Computing as the foundation
Confidential Computing (CC) and the CNCF Confidential Containers (CoCo) project provide the building block to solve this dual challenge and bridge the trust deficit. CC uses Trusted Execution Environments (TEEs) as a secure compute environment that can be remotely verified using a remote attestation service, protecting the code and data inside from any unauthorised access.
By using TEEs and a remote attestation service (think of it as a security and verification gateway), you can extend the trust to a different (untrusted) environment. Consequently, it enables you to deploy your application in a secure and verifiable manner, in any environment.
It’s important to remember that a fundamental requirement is to ship your code or model in an encrypted format. The encrypted workloads and data are only decrypted within TEEs, after verification against your defined policies by the remote attestation service.
Trustee — the remote attestation service
Trustee is a remote attestation service that helps unlock your code and data in verified, secure environments, giving both you and your customers peace of mind. It provides remote attestation and resource release, ensuring:
- Code only executes within TEEs.
- Secrets to decrypt models, app container images, etc, are only released after successful attestation.
In the following sections, we will examine two CC deployment scenarios designed to address diverse enterprise needs.
Confidential Computing Deployment Scenarios to address enterprise needs
In the first scenario, CC is used to protect the code and data of the SaaS AI tool provider. In the second scenario, the CC is used to protect the data of the enterprise customer.
Let’s understand these two scenarios in more detail.
Scenario 1: AI tool runs on TEEs in customer-managed hardware
As a SaaS AI tool provider, let’s consider two different delivery vehicles: Confidential VMs and Confidential Containers.
When using Confidential VM as a delivery vehicle, you provide an encrypted VM image that has your tool and models. This VM runs in a TEE within your customer’s datacenter. You own the Trustee (for remote attestation), and the decryption keys are released only after successful verification of the TEE environment.
The prerequisite here is that your customer environment has the TEE hardware and allows egress to your Trustee server for remote attestation and key release.
Let’s consider the case where you use Confidential Containers as the delivery vehicle. You provide an encrypted container image (and the required Helm charts, installation manifests, etc.) that runs on the customer’s Kubernetes environment.
The prerequisite here is that your customer environment has the TEE hardware, confidential containers set up and allows egress to your Trustee server for remote attestation and key release.
In this scenario, when running your AI tool (and models) in a customer’s environment, the data used for the AI tool remains within their environment. And because the AI tool (and models) runs in TEE, no customer admin will be able to exfiltrate the model and related code.
Disclaimer: Always remember that when it comes to security, there is no single solution that guarantees complete protection. CC is an additional protection mechanism that must be used in conjunction with other security best practices.
Scenario 2: AI tool runs on TEEs in provider-managed hardware, and the customer controls data access
The AI model runs in the provider’s hardware (e.g. public cloud), but the customer controls access to their encrypted data via their own Trustee deployment.
In this scenario, the customer is willing to move data outside of their environment but into a TEE environment that they can verify and trust.
The customer sends encrypted data to the tool, which is decrypted only within the TEE environment for processing.
The prerequisite here is allowing egress from your environment to the customer’s Trustee environment for remote attestation and key release. So you will need to factor this into the customer onboarding process.
Additionally, the customer implicitly trusts your code not to copy plaintext data from the TEE environment maliciously.
This “implicit trust” requirement is minimised when the code used is open source and is attested by the customer before any data sharing happens. But designing this workflow is non-trivial.
Summary
In this blog, we briefly discussed the challenges faced by SaaS AI tool providers when working with enterprise customers. We examined how confidential computing (CC) can address some of these challenges.
CC provides a way to extend trust to different environments. For example, extending trust from your on-prem to cloud environment or between two different on-prem environments. We looked at two CC deployment scenarios and how these deployment models facilitate a balanced trust relationship where:
- SaaS providers protect model confidentiality.
- Enterprises securely process sensitive data, locally or in the cloud, under their control.
- Trustee acts as a cryptographic gatekeeper, enforcing policies and releasing secrets only in verifiably secure environments.
I hope this gives you some pointers as you work towards enterprise adoption of your AI tools.
