Confidential memory for AI agents:
Polign on Phala Cloud

Polign is now available as a deployment template on Phala Cloud. It brings together two protections that belong next to each other: Polign encrypts database content before writing it to storage, and Phala runs the database inside a confidential virtual machine that protects its memory during execution.

This matters for agent memory. A useful agent can accumulate preferences, internal documents, working notes, and decisions across many conversations. Each piece of context makes the agent more useful. Together, those records can describe a person or a business in considerable detail. Where that memory lives, and who can read it while it is being searched, are part of the product's privacy model.

Most cloud security discussions start with encryption in transit and at rest. TLS protects a request as it crosses a network. Storage encryption protects the persisted bytes. But a database still needs readable data in memory to process a query. In a conventional virtual machine, the host operating system and hypervisor sit below that process with privileged access to its memory.

Confidential computing protects data while it is in use. A trusted execution environment, or TEE, uses hardware to isolate a workload from software outside its protected boundary. Phala's confidential VMs use Intel Trust Domain Extensions (TDX), which combine memory encryption and hardware isolation to protect the guest from the host OS, hypervisor, and other VMs. The database can still work with plaintext inside the VM; the infrastructure hosting that VM is excluded from direct access to its private memory. Intel's TDX overview explains this change in the trust model.

For a database backed by object storage, that protection needs to extend to every write. With storage-service encryption alone, the storage service still receives plaintext and handles its encryption and decryption. Polign's application-level storage encryption happens inside the database process. With encryption enabled, database objects and local disk-cache entries are written as AES-256-GCM ciphertext, including the write log, indexes, and manifests. A bucket receives encrypted content even when it lives outside Phala.

The Phala template requires this encryption. You supply the keyring through Phala's encrypted environment variables, which are encrypted on the client and decrypted inside the confidential VM before being passed to the containers. Polign reads those keys from its environment. The database process and the keys it uses therefore sit within the same protected runtime. See dstack's secret-delivery documentation for how the environment reaches the application.

The gateway belongs in that picture because it handles the incoming connection. Phala documents a gateway running in its own TEE, with mutual attestation and an encrypted tunnel between the gateway and the application VM. That makes the gateway part of the protected request path and part of what a deployment's verification should cover. Phala's network security documentation describes the architecture and its trust assumptions.

Remote attestation makes the runtime inspectable. Phala exposes cryptographic evidence about the TDX environment, operating system measurements, and application configuration. A verifier can check that evidence against the environment they expect before trusting a deployment. This provides a concrete way to evaluate the runtime behind an endpoint. The attestation overview explains what the evidence covers.

There is a practical distinction in the current template: it downloads a Polign release at startup and checks the archive against the release's published SHA-256 checksums. That check still relies on the release publisher. Attesting the VM and its startup configuration does not, by itself, independently identify every executable downloaded later. Deployments that require a fixed application identity should package the chosen binary into an image, pin the image by digest, and verify the expected configuration. Phala's application verification guide explains digest pinning and the checks involved.

Polign's architecture fits this deployment well. The serving engine runs as a single binary, and the template puts a Caddy proxy in front of its HTTP API. You can keep the database on the CVM volume or use your own S3 or GCS bucket. With a bucket store, a replacement VM can reopen the same database using the same storage location, keyring, and authorized bucket credentials. Durable memory can outlive the machine serving it. The template README covers both storage options.

The boundary is specific. Your application still receives readable query results, and anyone holding the template's shared bearer token has access to every collection. Sending retrieved context to an external model or embedding provider introduces that service into the data path. Application code, credentials, and logging still need to respect the privacy model. Confidential computing gives the memory service protection from the underlying host; the rest of the agent's data flow needs equally deliberate choices.

To try it with your own workload:

1. Open the Polign template on Phala Cloud.
2. Generate a storage keyring and a bearer token using the template's instructions. Add them as encrypted environment variables, and keep a secure copy of the keyring so you can recover the data later.
3. Choose the CVM volume or configure your S3 or GCS bucket, expose port 23000, and deploy.
4. Check the health endpoint, review the deployment's attestation, and connect through the HTTPS endpoint with your bearer token.

Agent memory should be useful, durable, and private while it is being used. Polign on Phala brings encrypted persistence and a protected execution environment together in a deployment you can run for your own application.