Quick bio

Tell us a bit about yourself: your background, current role, and how you got started in machine learning. 

I’m Gavin Uhma, co-founder and CTO of Cape Privacy. I started Cape Privacy in 2018 based on the belief that data privacy would be one of the biggest barriers to the adoption of AI. Since then, we’ve worked with a number of privacy and security technologies and various forms of ML.

🛠 ML Work  

You have recently been working on privacy guardrails for LLMs. Could you tell us more about the vision and inspiration behind Cape Privacy?

Cape keeps your sensitive data private while using LLMs. We redact sensitive personal, financial, and health data from your prompts.

The explosion of interest in ChatGPT has brought privacy to the forefront. There have been many stories like employees entering financial data or proprietary code, and there have been credential breaches that have exposed ChatGPT history. It’s unfortunate when companies ban ChatGPT because it’s such a great productivity tool. For this, we’ve built CapeChat which is a privacy-focused app on top of the ChatGPT API.

Developers meanwhile have struggled with how to protect their end-user’s data while building LLM based features. CapeChat is based on our Cape API which makes it easy for developers to protect the sensitive data in their prompts before sending them to an LLM provider like OpenAI or Anthropic.

Cape Privacy relies on enclave technology to enforce privacy constraints. What is the value of enclaves and how do they relate to ML privacy?

A secure enclave enables “confidential compute” which means it keeps data confidential while it is being computed, even from system admins and cloud providers. The Cape API runs entirely within a secure enclave, so no human can see what’s being processed (including the humans at Cape and AWS).

We use secure enclaves for inference, embeddings, vector search, de-identification and even custom user-defined models and python functions.

Foundation models are fundamentally bigger and more complex than previous ML architectures. What is the impact of this complexity on privacy models?

The best thing you can do for privacy is to bring the model local to the data. Since GPT-4 is proprietary and behind an API that hasn’t been an option. In addition, many developers appreciate the ease-of-use and pay-per-use of an API. At Cape Privacy we thread the needle by giving you a way to protect sensitive data while using the best LLMs at companies like OpenAI or Anthropic.

Cape Privacy implements privacy methods such as de-identification and re-identification for interactions with LLMs. Could you share some details about those and elaborate on some of the main techniques that can enable privacy in LLMs and similar foundation models?

When we de-identify data and send it to GPT-4, the LLM has no ability to see the sensitive entities like PHI, PCI, and PHI. For example, imagine a prompt “Hi, my name is [FIRST_NAME] [LAST_NAME] and I live in [CITY]. Where do I live?” The LLM can not rely on trained knowledge about “[CITY]” but it can answer “You live in [CITY]”. When you re-identify you convert the placeholder back to the original sensitive value: “You live in Halifax”. So interestingly an LLM still works even when the data is redacted.

But what are some of the less obvious implications of redacting data for an LLM?

• The LLM can’t hallucinate facts about “Halifax” because it only sees “[CITY]”. This encourages the LLM to rely more on the provided facts, for example: “[CITY] has a population of [NUMBER]”.

• You can reduce the LLM’s bias, for example it doesn’t know the gender, age, income, or nationality of “[FIRST_NAME]”.

• You can reduce cost by minimizing tokens, for example a long string for a URL becomes “[URL]”.

If you ask the LLM something like “Who is [NAME]” it will say it doesn’t know, which for many people is a feature rather than a limitation. I believe many people have gotten away from using LLMs for facts, and would rather rely on an LLM to repurpose the facts that they provide.

The majority of the use cases we see at Cape are developers using their own databases or documents to provide the LLM with context.

Vector databases are rapidly becoming an important element of LLM applications in areas such as memory and have consequently become another area of privacy concerns. How does Cape Privacy address security and privacy in Vector stores?

We run the entire vector store and embeddings model in a secure enclave so developers can create embeddings and perform similarity searches, entirely confidentially. This enables you to construct prompts from large datasets while keeping the data private. We can’t see your data, and we prevent third-party providers from seeing it.

💥 Miscellaneous – a set of rapid-fire questions 

What is your favorite area of AI research outside of private ML?

Tough question! I find quantization interesting, or in general, ways of making models more efficient.

Is security and privacy in LLMs significant enough to create standalone companies, or would it become a feature of most LLM platforms?

Security and privacy should be a feature of every LLM platform, however, it is complex enough to justify standalone companies. As a simple example, companies want a single platform to manage data privacy if they are working with multiple LLM providers.

What role can techniques such as secure multiparty computations(SMPC) play in enabling privacy in LLMs?

SMPC enables incredible opportunities such as co-training an LLM across companies. The resulting model can have a cryptographically shared ownership, while keeping the underlying datasets and model weights private. The downside of SMPC is the massive operational complexity and performance overhead, which most use-cases do not justify. But SMPC is legitimate, and it is deployed in the real-world today.

Can you provide a few examples/stories of "cool" hacks or attacks on LLM models?

I generally find jailbreaking really interesting.