Protecting data privacy and security while building with generative AI

When we set out to build New Relic AI, our mission was to unlock observability for all. By combining large language models (LLMs) and our unified telemetry data platform, New Relic AI helps make observability ubiquitous at any organization by offering deep insights, automated alerting, and system optimization without the learning curve.

Data security and privacy concerns are priority number one when building with tools that leverage generative AI technology. It’s imperative to consider how customer information is handled—both internally and by third parties, from initial prompt to end response—to protect user data. In this blog, you'll learn about how we protected data and privacy at each stage of development, and gain a better understanding of how New Relic AI handles customer information as it answers questions and offers insights throughout the New Relic platform.

Maintaining high standards

From its inception, the engineering team behind New Relic AI worked closely with our security, legal, and compliance teams to keep customer data secure. In addition to traditional security concerns like access controls, encryption, and vulnerability management, generative AI introduces additional risks, such as training data security and prompt injections. These require a new layer of protections and make the task of securing customer data more complex. New Relic’s approach to data privacy sets a high bar for protecting the confidentiality, integrity, and availability of customer data. While we were eager to work with such an exciting technology, it was crucial that we maintained our “privacy by design” principles throughout the entire process.

It was important to us that any vendor used in the design of New Relic AI was not only fully compliant with our standard data security protocols, but aligned with our security-first approach to development. Azure OpenAI is committed to not storing customer information or using customer information to improve their models, and we continue to work closely with Azure to ensure their service data protection guarantees align with our security policy. By leveraging their APIs, we’re not only able to power New Relic AI with a state-of-the art LLM, but also keep our customer data safe. Further information on the data, privacy, and security for the Azure OpenAI Service can be found on the Azure website.

While the LLM is at the core of New Relic AI, there are additional data security considerations for other areas of its architecture as well. The following sections discuss how we keep customer data secure at each step.

Balancing context and privacy

Let’s start with the New Relic database (NRDB). First, it’s important to note that the LLM doesn’t have direct access to NRDB. When a user asks New Relic AI, “How many transactions were there in the last 10 minutes?”, it will call the LLM to generate the appropriate New Relic Query Language (NRQL) query: SELECT count(*) FROM Transaction SINCE 10 minutes ago, then execute that query against NRDB. The New Relic AI service queries NRDB through the NerdGraph API using the user’s session token provided in the request, and is only granted access rights within the scope of the user’s permissions. The New Relic AI service has the control to inspect and fix queries before execution, and is able to redact responses before providing them to the LLM for summarization. This gives us the necessary levers to interrupt the flow when needed.

When accessing the NerdGraph API, New Relic AI acts on behalf of the user submitting the request. However, it doesn’t inherit full access to NerdGraph from the user; it only has access to a limited set of NerdGraph endpoints, such as executing a NRQL query. We plan to extend New Relic AI access to NerdGraph when it’s required to enable a new functionality, but are committed to only providing New Relic AI with the access rights that are absolutely necessary to performing that specific function.

In order to provide an intuitive user experience, New Relic AI has the ability to capture information from the UI based on the specific page the user is viewing when the question is asked. It doesn’t have full access to everything the user sees on the page, but rather a limited set of data, such as account id, entity id, and nerdlet id. This allows New Relic AI to answer questions like, “What’s the average latency for this service?” because the LLM has been provided with context that allows it to determine what “this service” is referring to.

During a conversation with New Relic AI, it “knows” about the previous messages of the ongoing conversation, and is able to build upon these previous messages. It doesn’t have access to any other conversations. This means it’s unable to build upon a previous conversation without reopening that specific conversation from the Ask AI History, and it doesn’t know about conversations with other users on the same account. These limitations help ensure that a user’s conversations with New Relic AI remain private.

Leveraging public documentation

In addition to answering questions about a user’s data, New Relic AI is also able to answer more general questions about how to use New Relic based on our public documentation using a method known as retrieval-augmented generation (RAG) to provide the model with context from our docs. (Learn more about how RAG improves our performance evaluation of New Relic AI in this blog post by New Relic Senior Data Scientist Tal Reisfeld.)

Our documentation is indexed in a Pinecone vector database. Each page of documentation is split into chunks, and then embedding is created for each chunk and stored in the vector database. When a user asks New Relic AI a question, its backend services will embed the question, search for relevant documentation chunks in the vector database, then retrieve the chunks that are closest to the embedding.

Embedding is a technique where a chunk of text is reduced to a vector of floating point values that capture the semantic meaning of the piece of text. An embedding doesn’t contain the original text, and the original text cannot be generated based on the embedding. This vector of floating point values allows us to find other vectors that are semantically similar to the provided vector representing the original request.

The vector database contains both the embedding and the original text from the New Relic public documentation. This allows us to retrieve the original text for vectors that are close to the vector for the question. We only store public information in the vector database and are not indexing any customer data. This ensures we’re not leaking any information between users, accounts, or customers through the vector database.

Thus, the retrieval of relevant documentation chunks from the vector database is based completely on the embedding of the question, and the actual text of the user’s question is never sent to the vector database.

Proactively protecting our customers

Our team is committed to maintaining a proactive approach to protecting the integrity of our customers’ data—from how we evaluate vendors, to how we select the necessary context and access rights of each backend service of New Relic AI. Generative AI technology is growing and developing at an incredible pace; in order to deliver a product that is both industry-leading and secure, it is critical to stay vigilant both in terms of adopting the latest improvements and evaluating potential security and privacy risks of each new release. We will continue to invest in our talent, technology, and partnerships to ensure that data security is always the first consideration as we enhance the power and aptitude of our generative AI observability assistant.