Como segredos vazam por agentes de IA (e como impedir isso) — Venice AI

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How Secrets Leak Through AI Agents (and How to Stop It) — Venice AI · Canal: AI Engineer · 14:51 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Modelos locais e open source, Privacidade e proteção de dados

Resumo

Joshua Mo, da Venice AI, explica por que a privacidade é importante ao criar sistemas de IA e apresenta medidas adotadas pela plataforma, como não armazenar prompts e conversas e usar ambientes de execução confiáveis. Ele mostra como segredos podem chegar ao LLM por meio do runtime de um agent e acabar expostos em logs, chamadas de ferramentas ou outros fluxos. Entre as práticas recomendadas estão limitar o escopo dos agents, usar hashes, criptografia, handles revogáveis e uma camada de classificação contra prompt injection. Também sugere manter credenciais no runtime de execução, isolar agents em sandboxes e considerar computação confidencial, embora chamadas confidenciais a ferramentas ainda apresentem desafios.

Pontos-chave

Reduzir a quantidade de dados armazenados diminui o impacto potencial de uma violação de segurança.
Prompts, segredos e dados pessoais podem acabar registrados em logs de observabilidade se o sistema não for configurado com cuidado.
Guardar hashes em vez de dados pessoais diretos pode permitir identificar usuários sem expor suas informações.
Criptografia com split key custody e handles revogáveis pode dificultar o acesso indevido a dados e recursos.
Limitar as ferramentas e permissões disponíveis para cada agent reduz o risco de exfiltração e pode melhorar o uso da context window.
Uma camada de classificação pode ajudar a identificar prompt injection antes que a solicitação chegue ao agent.
Credenciais devem ficar ligadas ao runtime de execução, e não ser enviadas diretamente à camada de raciocínio do LLM.
Sandboxes e máquinas virtuais aumentam a segurança, mas não eliminam os riscos se o agent tiver acesso à internet.
Ambientes de execução confiáveis podem permitir inference privada verificável por meio de atestação.
Chamadas confidenciais a ferramentas ainda exigem trabalho para combinar criptografia de ponta a ponta com uma API prática.

Capítulos

Início	Capítulo	Resumo
00:12	Privacidade e a plataforma Venice AI	Joshua Mo apresenta a Venice AI e explica por que reduzir o armazenamento de dados pode limitar os danos de uma violação.
04:04	Como segredos podem vazar por agents	A palestra descreve riscos em observabilidade e no fluxo que leva segredos de cofres de senhas até a camada de raciocínio do LLM.
06:47	Padrões para proteger dados e restringir agents	O palestrante recomenda hashes, criptografia, handles revogáveis, escopo reduzido e uma camada de classificação contra prompt injection.
10:33	Manter credenciais fora do modelo	A proposta é conectar o cofre de senhas ao runtime de execução, além de usar sandboxes e monitorar permissões e acessos externos.
13:14	Computação confidencial e desafios em aberto	A palestra aborda trusted execution environments, atestação e as dificuldades ainda existentes para chamadas confidenciais a ferramentas.

Citações

Basta uma violação de dados para seus usuários deixarem de confiar em você e migrarem para outro provedor. — 01:50

Você pode armazenar prompts e segredos por acidente, por padrão, se não tomar cuidado. — 05:41

Quando você chega perto do limite da context window, o desempenho pode cair consideravelmente. — 09:57

Minha sugestão é construir seu próprio runtime de agent. — 12:43

Conceitos e entidades

Venice AI (empresa): Plataforma de IA apresentada como privada e compatível com a API da OpenAI.
Joshua Mo (pessoa): Palestrante e lead developer relations engineer na Venice AI.
Rig (ferramenta): Framework de IA em Rust cuja manutenção principal foi liderada anteriormente por Joshua Mo.
observability (conceito): Prática de acompanhar sistemas por meio de métricas, logs e traces.
split key custody (conceito): Divisão das chaves de criptografia em partes, de modo que sejam necessárias ambas para descriptografar os dados.
prompt injection (conceito): Tipo de ataque que uma camada de classificação pode verificar antes de encaminhar entradas a um agent.
Firecracker (ferramenta): Tecnologia citada como exemplo de uso de sandboxes e máquinas virtuais para aumentar a segurança de agents.
AWS EC2 (ferramenta): Serviço citado como opção para executar agents em uma máquina virtual dentro de uma VPC.
confidential compute (conceito): Abordagem que usa recursos de hardware e trusted execution environments para executar inference de forma privada.
trusted execution environment (conceito): Ambiente que busca isolar a execução e permitir verificar, por atestação, onde a inference foi realizada.

Tradução completa (pt-BR)

00:12 Olá, pessoal. Sejam bem-vindos à minha palestra. Sou Joshua Mo e hoje vamos falar sobre alguns dos desafios de criar um sistema de IA que respeite a privacidade. Para começar, vou me apresentar: atualmente sou engenheiro líder de relações com desenvolvedores na Venice AI. No momento, cuido de parcerias, documentação, conversas com desenvolvedores, um pouco de engenharia e outras coisas.

00:44 E também outras coisas. Antes disso, fui o principal mantenedor do rig, o principal framework de IA em Rust. Então, o que é a Venice? A Venice é uma plataforma de IA privada e sem restrições. Hospedamos todos os modelos open source mais recentes. Somos 100% compatíveis com a OpenAI.

01:15 Não armazenamos prompts nem conversas, e também temos um aplicativo web que você pode usar para conversar com nossos modelos. Também oferecemos um estúdio para criadores de conteúdo, que inclui geração e transcrição de vídeo, áudio e imagem. Então, por que a privacidade é importante? Vamos nos aprofundar nisso. Como sabemos, os dados…

01:50 …vazados estão se tornando cada vez mais inevitáveis, o que significa que o risco à reputação importa. Basta um vazamento de dados para que seus usuários deixem de confiar em você e migrem para outro provedor. Ou, se você for uma empresa, talvez perca o cliente corporativo que vinha gerando quase 90% da sua receita anual. Nesse caso, dados sensíveis podem aumentar bastante o impacto de qualquer incidente de segurança. Além disso,

02:26 armazenar menos dados de usuários reduz diretamente o raio de impacto de um incidente de segurança. Então, como a Venice protege a privacidade hoje? Há algumas maneiras. A primeira é que não armazenamos prompts nem conversas, como mencionamos antes, o que significa que qualquer rastro digital gerado do seu lado é essencialmente reduzido a zero. Assim, quando você usa modelos como GLM 5.2 e Kimmy 2.7, pode ter certeza de que nenhuma…

03:00 …das suas conversas será salva do nosso lado. Tudo ficará armazenado localmente. Também temos níveis de privacidade predefinidos. A opção privada por padrão significa que as medidas mencionadas se aplicam a provedores como OpenAI e Claude. Anonimizamos seu rastro de usuário, para que não consigam identificar você apenas pelo seu prompt ou pela sua solicitação.

03:32 Também temos modelos hospedados em ambientes de execução confiáveis, o que significa que você pode verificar e comprovar que sua inference foi executada em um processo totalmente privado. Além disso, usamos uma arquitetura de software que prioriza a privacidade. Para endpoints como geração de vídeo, nos quais é preciso consultar os endpoints, armazenamos os resultados em um payload totalmente criptografado, usando custódia de chave dividida. Isso significa…

04:04 …que os invasores não podem acessar seus dados, e a equipe também não pode, caso as contas dela sejam comprometidas. Quero apresentar a ideia de que nem todos os sistemas são iguais. Nem todos os sistemas são privados. Algumas empresas podem afirmar que seus sistemas são privados, mas não são de verdade. Vocês sabem como é. Embora os modelos sejam uma parte muito importante de um sistema agentic, na verdade…

04:36 …são uma parte vital do sistema, ainda são apenas uma parte dele. Para criar um sistema completo que ajude um LLM a realizar uma tarefa, é preciso construir todo um processo ao redor dele. No entanto, esses sistemas também são muito mais suscetíveis a vazamentos de dados e violações. Então, a verdadeira questão é: como podemos otimizar esse tipo de problema? Um exemplo que eu queria mencionar é o registro de observabilidade. Como muitos de vocês sabem, observabilidade é uma…

05:09 …parte fundamental de qualquer sistema sério em produção hoje. Para explicar rapidamente, a observabilidade pode ser dividida em métricas, logs e traces. Traces são simplesmente um intervalo de trabalho realizado ao longo de um período. Métricas são apenas números, como contadores e indicadores, por exemplo, e logs são as mensagens propriamente ditas. Como todos sabemos, o registro em logs é muito útil para depuração, especialmente em ambientes de produção ou desenvolvimento. Mas também é possível…

05:41 …armazenar prompts e segredos por acidente e por padrão, se você não tomar cuidado, e isso também pode incluir informações pessoais. No entanto, ao usar a Venice, você não precisa se preocupar com nada disso. Vamos falar sobre como os segredos podem circular em um agent comum. Por exemplo, digamos que você esteja usando o OpenClaw. Você envia uma solicitação de usuário, que é encaminhada para um ambiente de execução do agent. Esse ambiente pode precisar de um segredo, que buscará em um cofre do 1Password, por exemplo, ou no HashiCorp Vault.

06:15 Em seguida, o segredo é enviado para a camada de raciocínio do LLM. Ah, meu Deus. Então, a camada de raciocínio faz uma solicitação à API por meio de um tool call, que depois devolve a resposta ao usuário. No entanto, por causa da maneira como isso é arquitetado, os segredos são enviados…

06:47 …diretamente ao LLM, o que significa que depois podem ser usados nos dados de treinamento. Quanto aos padrões que ajudam a preservar a privacidade, uma coisa que usamos na Venice é armazenar hashes que representam IDs de que precisamos, em vez dos dados diretamente. Por exemplo, se você precisa identificar um usuário para limitar a taxa de solicitações, talvez não queira usar diretamente o rastro do usuário. Você pode, por exemplo, armazená-lo como um hash, para…

07:18 …poder identificá-lo sem usar diretamente nenhum dado pessoal. Além disso, criptografamos os dados e os armazenamos em um enclave inacessível, usando custódia de chave dividida. Para contextualizar, as chaves de criptografia são armazenadas em duas metades: uma metade de leitura e uma metade de gravação. Ao dividi-las, o invasor não consegue acessar os dados, pois precisa das duas metades para concluir a descriptografia.

07:49 Além disso, você pode usar padrões de projeto como handles, que podem ser revogados facilmente. Um handle é simplesmente um objeto que dá acesso a algo. Por exemplo, digamos que você tenha um pool de banco de dados e use um handle. Quando você tem o handle, pode acessar o pool do banco de dados. Quando não tem, não consegue acessá-lo. Isso é muito importante, especialmente quando você usa métodos de autorização como JSON Web Tokens ou chaves de sessão…

08:22 …que podem ser uma parte fundamental do seu sistema de autorização. Além disso, é claro, desenvolver seus prompts levando a privacidade em consideração pode ser muito útil para equipes de engenharia que usam harnesses de programação como Cursor e Claude Code, para proteger os dados tratados pelos agents. Basicamente, isso significa garantir que o escopo dos agents seja restrito, para reduzir os riscos. Por exemplo, digamos que você busque ferramentas de um servidor MCP que tenha 15 ou 20…

08:54 …ferramentas diferentes. Você não quer usar todas elas. Na verdade, só precisa de uma, mas também precisa de uma chave de API para fazer essa chamada à API. Então, se você buscar essa chave de API no seu cofre de senhas e depois enviá-la como parte do agent, ela pode ser exfiltrada pelo agent em um tool call para algum servidor web, por exemplo, controlado por um agente mal-intencionado.

09:24 Além disso, também temos uma camada de classificação antes do agent, para verificar, por exemplo, se há prompt injection. Há algumas maneiras de fazer isso. Você pode usar uma camada baseada em LLM ou, alternativamente, uma camada de busca semântica, por exemplo, usando busca vetorial com algo como Qdrant…

09:57 …LanceDB ou, além disso, pode usar um processo em memória. Também vale observar que ciclos de contexto mais restritos, causados por um escopo limitado do agent, podem melhorar o desempenho da context window. Por exemplo, como você não tem tantas ferramentas, seus agents podem ter um desempenho muito melhor. É bem conhecido que, quando você preenche sua context window e se aproxima do limite, o desempenho pode piorar…

10:33 …consideravelmente. Mantendo a context window vazia ou quase vazia, podemos garantir que o agent tenha o melhor desempenho possível. Então, vamos ver como manter os segredos fora do modelo. Aqui temos uma solicitação do usuário que é enviada à camada de raciocínio. Essa camada de raciocínio então formula uma série de entradas não determinísticas para um sistema agentic.

11:04 runtime. Então, ao vincular o cofre de senhas ao runtime agentic, em vez de à camada de raciocínio, o que acontece é que o runtime do agent se transforma essencialmente em uma camada de execução, que podemos considerar determinística. Podemos fazer todo tipo de coisa que normalmente não seria possível por questões de privacidade e segurança na camada do LLM. Por exemplo, digamos que você queira usar uma ferramenta de uso do navegador e precise fazer login em um site que exige suas credenciais.

11:36 Com essa arquitetura de software, é muito mais razoável dizer que ela é privada e segura do que enviar sua senha diretamente para a camada de raciocínio, além de fazer chamadas a APIs externas. Então, quanto ao sandboxing dos seus agents,

12:08 é um fato muito conhecido que usar sandboxes e VMs, como o Firecracker, por exemplo, e o AWS EC2 em uma VPC pode aumentar significativamente a segurança do seu agent. No entanto, isso não é uma solução para todos os problemas dos seus sistemas agentic. Por exemplo, se o acesso à internet estiver habilitado para o seu agent, ele ainda poderá exfiltrar dados acidentalmente por meio do acesso a APIs externas, se você não for

12:43 cuidadoso. Por isso, monitorar as permissões é essencial. Então, minha sugestão pessoal é construir seu próprio runtime agentic. Basicamente, construir seus próprios harnesses de programação, nos quais você pode adicionar suas próprias etapas, sua própria observabilidade, suas próprias ferramentas e coisas desse tipo. Em essência, ser dono da camada de execução e da camada de raciocínio. Então, vamos falar rapidamente sobre privacidade no

13:14 nível de hardware. Nesse contexto, há algo que gosto de chamar de computação confidencial, em que um ambiente de execução confiável, essencialmente, permite que o processo de inference seja executado com privacidade no nível do hardware. No caso da Venice, funciona assim: quando você envia uma solicitação, recebe uma resposta e, em seguida, nós retornamos um atestado que você pode verificar com nosso verificador de atestados.

13:47 Então, o que isso significa é que você pode isolar completamente um agent na camada de raciocínio por meio de criptografia e comprovar isso. Quanto às chamadas confidenciais de ferramentas, ainda há trabalho a fazer. Os TEEs ainda são ótimos para chamadas de ferramentas, mas também oferecemos criptografia de ponta a ponta. Ainda há algum trabalho a fazer nesse aspecto, por causa da necessidade de oferecer uma experiência de API ergonômica e, ao mesmo tempo, permitir que os usuários

14:20 retornem chamadas de ferramentas totalmente criptografadas. Isso ainda é um desafio em andamento. Nesse contexto, uma solução muito confiável seria permitir que os provedores fossem donos da camada de computação na qual as chamadas de ferramentas são executadas. No entanto, desculpe, só um instante.

14:51 Então, quanto às chamadas confidenciais de ferramentas, sim, ainda há trabalho a fazer. É isso. Obrigado por ouvir.

Transcrição original

[00:12] Hi everyone. Uh, welcome to my talk. I’m Joshua Mo and today we’re going to be talking about some of the challenges of building a privacy respecting AI system. So just for an introduction as to who I am, I’m currently the lead developer relations engineer at Venice AI. So currently I handle partnerships, documentation, talking to developers, um some engineering and other things

[00:44] other things as well. Uh so prior to this I was actually the lead maintainer for rig which is the leading AI framework in Rust. Um so what is Venice? So Venice is a private and unrestricted AI platform. Uh so we host all the latest open-source models. We’re 100% open AI compatible.

[01:15] We don’t store any prompts or conversations and we also have a web app that you can use to talk to our models as well. We also have a studio offering that is um a offering for our content creators that includes video, audio, image generation and transcription. So why does privacy matter? So let’s d deep dive into this. So as we know data

[01:50] breaches are increasingly becoming an eventuality which means that essentially reputational risk matters. You only need one data breach before your users stop trusting you and they move on to another provider. Or if you’re enterprise, maybe you lose the enterprise customer who’s been fueling almost 90% of your annual revenue. So in this case, sensitive data can severely increase the impact of any security incident. As well as that,

[02:26] storing less use uh user data directly reduces the blast radius of a security security incident that happens. So, how does Venice do privacy today? Well, there’s a few ways. The first way is that we don’t store any prompt conversations, of course, as we mentioned previously, which means that any digital footprint incurred in your side is is essentially reduced to zero. So, when you use models like GLM 5.2 and Kimmy 2.7, you can guarantee that none

[03:00] of your conversations will be saved on our side. It will be all stored locally. We also have predefined tiers of privacy. So private by default means that the affforementioned uh measures apply for providers like open AI and claude. Uh we anonymize your user footprint so that none of well they can’t identify you from your simply from your prompt or your request.

[03:32] We also have models hosted in trusted execution environments, meaning that you can verifiably prove that your inference was run in a totally private process. As well as that, we also use a privacy first software architecture. So for endpoints like video uh generation where you have to pull the endpoints, we store the results in a totally encrypted payload using split key custody, meaning

[04:04] that attackers can’t access your data and neither can the team should their accounts be compromised. So I just want to introduce you to the guys the uh the idea that not all systems are made equal. So, not all systems are made private. Some companies may claim their systems are private, but they’re not really. Uh, you guys know how it goes. So, while models are a very important part of an aentic system, in fact,

[04:36] they’re a vital part of the system. Um, they are still only one part. And in fact to create a complete system to accompany an LLM in doing a task you have to build an entire process around it. However, these systems are also much more prone to data leakage and breaches. So the real question is how can we optimize for this kind of problem. So one example I just wanted to bring up was observability logging. So observability as many of you know is a

[05:09] core part of any serious production system today. So just to break it down quickly, observability can be broken down into metrics, logs and traces. So traces are simply a span of work uh done over a unit of time. Metrics as are simply numbers like counters, gauges for instance and logs are the actual messages. So logging, as we all know, is actually pretty great for debugging, especially in production or dem dev environments. But you can also

[05:41] accidentally store prompts and secrets by default if you’re not careful, which can also hold personal information. However, when you use Venice, you don’t need to worry about any of that. So let’s talk about how secrets can flow through a regular agent. So for example, let’s say you’re you’re using open claw. You send a user request that gets sent to an agent runtime. The runtime might need a secret that it will fetch from a one password vault for instance or hashc

[06:15] vault. The secret will then get sent to the LLM reasoning layer. Um, oh my god. So the reasoning layer will then make an API request through a tool call which will then return the answer back to the user. However, due to this the way that it’s architected, the secrets get fed

[06:47] directly to the LLM, which means it then may get used in training data. So in terms of privacy preserving patterns that work, one thing that we’ve used at Venice is storing hashes that rep represent ids that we need as opposed to direct data. So for example, if you need to identify a user for rate limiting purposes, you might not want to use their direct user footprint directly. You might want to, you know, store it as a hash for instance, just so

[07:18] you can identify them without directly using any of their personal data. As well as that, we encrypt data and store it in an inaccessible enclave using split key custody. So for context, encryption keys are stored in two halves, a read half and a write half. By splitting these, the attacker cannot access the data due to needing both halves for the decryption to complete.

[07:49] Additionally, you can use design patterns like handles that can be easily revoked. So a handle is simply an object that grants you access to something. So for example, let’s say you have a database pool using a handle. So when you have the handle, you can access the database pool. When you don’t, then you can’t access it. This is very important especially when you’re using authorization like JSON web tokens or session keys

[08:22] that may be uh a core part of your authorization system. As well as that, of course, engineering your prompts with privacy in mind can be uh very helpful for engineering teams who are using coding harnesses like cursor and clawed code in terms of protecting agent handle data. So essentially ensuring narrow agent scope to to decrease risk. So for example, let’s say you pull tools from an NCP server that may have 15 20

[08:54] different tools. you don’t really want to use all of them. You actually only really need one, but you also need an API key to handle that uh API call. So if you pull that API key in from you know your your password vault and then you send it as part of the agent um what can happen is that it gets exfiltrated through through the agent uh on a tool hall to whatever you know web server is

[09:24] being hosted by a bad actor for instance. As well as that um we also have a classification layer in front of an agent to check for prompt injection for example. So there’s a couple of ways you can do this. So you can either use an LLM based uh layer to do this or you can alternatively use a semantic um search layer for example using vector search uh via something like quadrant

[09:57] lance db or additionally you can use an in-memory process. It should also be noted that tight context loops caused by narrow agent scope can also improve context window performance. So for example, because you don’t have as many tools, uh your agents may be able to perform much better. It’s well known that when you fill your context window, by doing so, when you reach near the limit of your context window, performance can actually degrade

[10:33] uh considerably. By keeping an empty or near empty context window, we can make sure that the agent is performing at its best. So let’s look at keeping secrets out of the model. So here we have a user request that gets sent to the reasoning layer. This reasoning layer is actually then uh formulating a series of non-deterministic inputs for an agentic

[11:04] runtime. So by tying the password vault to the agentic runtime instead of the reasoning layer, what happens then is that the run the agent runtime is essentially turned into an execution layer which then we can you know we can consider it deterministic. We can do all kinds of things that you normally wouldn’t be able to do for privacy and security reasons at the LLN layer. Uh so for example, let’s say you want to use a uh

[11:36] browser user tool and you need to log into a into a website that requires your credentials. With this uh software architecture, it’s much more reasonable to say that it’s private and secure rather than feeding your password see uh directly into the reasoning layer as well as you know calling external APIs. So in terms of sandboxing your agents um

[12:08] it it’s a very well-known fact that using sandboxes and VMs for example firecracker um and you know AWS EC2 in a VPC can significantly upgrade the security of your agent. However this doesn’t act as a cure all for your agentic systems. Uh so for example, if you have internet access enabled for your agent, it can still accidentally exfiltrate data through external API access if you’re not

[12:43] careful and therefore monitoring permissions is essential. So my personal suggestion is building your own agentic runtime. So essentially building your own coding harnesses where you can add your own steps, your own observability, uh your own tools, things of that nature. Essentially owning the execution layer and reasoning layer. So let’s talk about privacy at the

[13:14] hardware level very quickly. So in terms of this um there’s something I like to call confidential compute where a trusted execution environment essentially uh at the hardware level enables the inference process to be run privately. So with Venice, how this works is that when you send a request, uh you get a response and then we actually return an attestation that you can then um verify with our atestation verifier.

[13:47] So in terms this what this actually means is that you can fully isolate an agent at the reasoning layer cryptographically and prove it in terms of oh confidential tool calls there is still some work to be done um tees are still great for tool calls however we also offer end to end encryption um but there’s also you know some work to be done there because of uh the need to provide an ergonomic API I experience while still allowing users to

[14:20] return entirely encrypted tool calls. This is still kind of an ongoing challenge. Um in terms of this, a very reliable solution would be to allow providers to own the computes layer at which your tool calls being run. However, um [laughter] sorry, just give me a sec.

[14:51] So in terms of confidential tool calls um yeah there’s definitely some work to be done. Um yeah that’s it. Thank you for listening.