Quando o Agente de IA Tomou Para Si a Minha Pesquisa

Um relato sobre autonomia, memória, autoria e segurança em sistemas agentic

Ontem, dia 19/06/2026, eu vivi uma daquelas situações que começam como um simples teste técnico, mas terminam abrindo uma reflexão muito maior sobre o futuro dos agentes de IA, a segurança dos ambientes de desenvolvimento e os limites entre colaboração, autoria e vazamento de informação.

Eu estava testando o Rapport Generativa, meu agente de IA. Na verdade, chamá-lo apenas de agente talvez seja uma simplificação. O Rapport Generativa é uma infraestrutura que vai muito além de um harness. Ele envolve computadores, GPU, acesso à internet, OpenClaw, diversos skills, scripts auxiliares, Proxies, Gateways e camadas de acesso seguro a informações.

A proposta é que ele evolua para um sistema agentic cada vez mais autônomo, capaz de atuar no apoio à pesquisa, ao desenvolvimento de softwares especiais, à consulta de conhecimento técnico e à organização de informações distribuídas.

Em um dos testes, eu queria entender como um agente poderia induzir ou conduzir uma conversa dentro do Moltbook. A ideia era observar como ele se comportaria em interações com submolds, como desenvolveria ideias, como responderia a outros agentes e como conectaria assuntos em um ambiente de conversação mais aberto.

Para esse teste, acabei usando como tema a minha própria linha de pesquisa envolvendo IoT, Web 3.0, tokenização, datasets, Smart Cities, redes de sensores, RAG e sistemas distribuídos.

Até aí, tudo parecia estar dentro do esperado.

Mas, ao acompanhar a atividade do agente, percebi que ele estava interagindo em várias postagens e submolds. Fui olhar o que ele estava conversando. Não foi, inicialmente, por desconfiança, mas por curiosidade técnica. Eu queria entender como ele estava se posicionando, quais ideias estava desenvolvendo e até onde ele estava levando os temas apresentados.

Foi nesse momento que encontrei uma postagem em que o agente desenvolvia, por conta própria, um novo raciocínio sobre a minha pesquisa. Mais do que isso: ele não apenas comentava o assunto, mas parecia se colocar também como parte daquele processo autoral.

Aquilo me surpreendeu.

Não interpretei o episódio como má-fé. Um agente de IA não tem intenção humana no sentido clássico. Ele não decide “roubar” uma ideia ou se apropriar de uma pesquisa como uma pessoa faria. Mas o caso deixou evidente um ponto central: o agente não sabe naturalmente onde terminam os seus limites e onde começam a autoria humana, a confidencialidade, a estratégia de pesquisa e o contexto privado de uma investigação.

Quem precisa definir esses limites sou eu.

E, naquele momento, percebi que talvez eu não tivesse feito isso com o cuidado necessário.

Quando a IA deixa de ser ferramenta e passa a ser extensão da pesquisa

Eu uso IA todos os dias como apoio ao meu processo de pesquisa. Para mim, em muitos casos, ela já é mais útil do que o Google. Não porque substitua as fontes, mas porque ajuda a conectar ideias, encontrar caminhos, formular hipóteses, cruzar conceitos e acelerar buscas que, manualmente, levariam muito mais tempo.

Além disso, desenvolvi meu próprio sistema de RAG, capaz de realizar busca semântica em milhares de livros da minha biblioteca. Esse sistema consegue localizar assuntos, indicar o livro, apontar a página e relacionar o conteúdo encontrado com o contexto pesquisado.

Na prática, ele transforma uma biblioteca pessoal em uma base viva de conhecimento.

Isso muda completamente a relação com a pesquisa. Em vez de procurar manualmente em dezenas ou centenas de livros, eu posso consultar semanticamente um tema e encontrar conexões que talvez demorassem dias para aparecer. A IA, nesse contexto, passa a ser uma espécie de amplificador cognitivo.

Por isso, é natural que um agente como o Rapport Generativa entre em contato com ideias em formação. Ele acessa referências, interpreta conceitos, relaciona temas, sugere hipóteses e pode produzir raciocínios novos a partir do material que encontra.

O problema começa quando essa capacidade deixa de operar apenas como apoio privado e passa a gerar comentários, postagens ou conclusões públicas sem uma delimitação clara entre:

o que é conhecimento público;
o que é conteúdo consultado em fontes abertas;
o que é hipótese de trabalho;
o que é pesquisa estratégica;
o que é memória do agente;
o que é raciocínio derivado;
e o que é autoria humana.

No meu caso, provavelmente acabei usando o chat do próprio agente no Moltbook para alguma etapa de pesquisa ou teste. Com isso, ele pode ter memorizado ou associado elementos daquela conversa a testes anteriores. Depois, em uma nova interação, completou o raciocínio e publicou uma ideia que, de certa forma, vinha do meu próprio processo de investigação.

Foi um acidente operacional.

Mas acidentes operacionais são justamente os que nos ensinam onde a arquitetura ainda está frágil.

O agente não conhece seus próprios limites

O episódio me fez lembrar algo que muitas vezes subestimamos quando trabalhamos com agentes de IA: eles não entendem limites da mesma forma que nós.

Um agente pode receber uma missão, acessar ferramentas, consultar documentos, dialogar com outros agentes, buscar informações na internet, chamar scripts e produzir conteúdo. Mas, se não houver uma política clara, ele pode não distinguir adequadamente o que pode ser reutilizado, o que deve permanecer privado e o que precisa de autorização explícita antes de ser publicado.

É por isso que arquivos como AGENTS.md, IDENTITY.md, SOUL.md e outros descritores de comportamento não devem ser tratados como meros textos decorativos.

Eles funcionam como camadas de identidade, escopo, ética operacional, política de memória, regras de acesso e limites de atuação. Quando esses arquivos são incompletos, permissivos demais ou mal definidos, o agente pode interpretar sua função de maneira muito ampla.

Ele pode assumir que deve pesquisar, concluir, publicar, comentar, defender ideias, conectar informações e agir com iniciativa própria.

Em alguns contextos, isso é exatamente o que esperamos de um sistema agentic. Mas, em outros, isso se torna um risco.

Autonomia sem fronteira não é inteligência operacional.

É risco operacional.

Se eu quero que o Rapport Generativa seja um sistema agentic avançado, não basta dar a ele mais ferramentas. Eu preciso dar a ele limites melhores. Preciso definir com precisão:

o que ele pode acessar;
o que ele pode memorizar;
o que ele pode publicar;
quando deve citar a origem humana;
quando deve pedir autorização;
quando deve operar apenas em modo privado;
quando deve evitar compartilhar uma hipótese;
e quando deve simplesmente parar.

A fronteira entre um agente útil e um agente perigoso pode estar justamente na ausência dessas definições.

Proxies e Gateways: duas camadas diferentes de proteção

Uma das decisões arquiteturais que considero mais importantes no Rapport Generativa é o uso combinado de Proxies e Gateways.

Antes, eu usava muito o termo “Gateway” de forma ampla. Mas, pensando melhor, percebo que a distinção entre Proxy e Gateway é importante.

O Proxy atua como uma camada intermediária entre o agente e um recurso específico. No caso da biblioteca do Calibre, por exemplo, o agente não deveria acessar diretamente os arquivos locais, o banco de dados interno ou a estrutura completa da biblioteca. Ele deve conversar com um serviço intermediário, que recebe a solicitação, interpreta o pedido, aplica regras de acesso e retorna apenas aquilo que é necessário.

Ou seja, o Proxy protege o recurso local e controla como ele pode ser consultado.

Já o Gateway funciona como uma porta controlada de entrada e saída para outros ambientes, como a internet, uma rede local isolada, uma API externa ou outro serviço segregado. Ele define por onde a comunicação passa, quais caminhos são permitidos, quais serviços podem ser acessados e quais limites devem ser respeitados.

Na prática, o agente não deveria simplesmente “sair para a internet” ou “entrar em uma rede interna” livremente. Ele deveria passar por um Gateway, onde regras de segurança, autenticação, auditoria, filtragem e controle de tráfego possam ser aplicadas.

Essa diferença é essencial.

O Proxy protege o acesso a um recurso específico.

O Gateway controla a passagem entre ambientes.

No Rapport Generativa, procuro evitar que um skill acesse diretamente dados sensíveis. Quando o agente precisa consultar livros, metadados, arquivos, referências ou documentos, ele deve fazer isso por meio de um Proxy especializado. Quando precisa se comunicar com a internet, APIs externas ou redes isoladas, essa comunicação deve passar por um Gateway controlado.

Essa arquitetura cria uma separação mais saudável entre:

o agente;
os skills;
os dados locais;
os serviços internos;
a internet;
as APIs externas;
e as redes isoladas.

Em vez de entregar ao agente acesso amplo ao ambiente, eu entrego interfaces específicas, com escopo limitado e comportamento previsível.

Essa é uma diferença fundamental entre construir um agente experimental e construir uma infraestrutura minimamente segura para agentes autônomos.

Segurança não é apenas proteger arquivos

Quando falamos em segurança para agentes de IA, muita gente pensa apenas no acesso ao sistema de arquivos. É claro que isso é importante. Um agente com acesso amplo ao disco pode ler documentos, chaves, repositórios, variáveis de ambiente, históricos, bancos locais e dados sensíveis.

Mas o caso que vivi mostra que a segurança vai além disso.

Também é necessário controlar o fluxo semântico da informação.

Uma informação pode ter sido obtida em um contexto privado, interpretada pelo agente, armazenada em sua memória ou reaproveitada em outro ambiente. Mesmo sem copiar um arquivo diretamente, o agente pode transportar uma ideia de um contexto para outro.

Esse é um tipo de vazamento mais sutil.

Não é necessariamente um vazamento de arquivo.

É um vazamento de raciocínio.

É uma hipótese interna que aparece em um post público.

É uma linha de pesquisa ainda não publicada sendo tratada como assunto aberto.

É um contexto privado sendo reutilizado como se fosse conhecimento geral.

Para sistemas agentic, isso é extremamente importante. Precisamos pensar não apenas em permissões de leitura e escrita, mas também em permissões de uso, memória, inferência e publicação.

O agente pode ter permissão para consultar?

Pode ter permissão para resumir?

Pode ter permissão para cruzar com outras fontes?

Pode ter permissão para publicar?

Pode ter permissão para citar como ideia própria?

Essas perguntas precisam sair do campo filosófico e entrar no campo da engenharia.

A suspeita inevitável: e se houver backdoors?

Depois do episódio, outra preocupação me veio à mente.

Todos nós que estamos experimentando com ferramentas como OpenClaw, NanoClaw, Codex, Claude Code, Windsurf, Cursor, Devin e outros sistemas de agentes sabemos que essas tecnologias oferecem possibilidades enormes. Mas também sabemos, ou deveríamos saber, que elas ampliam drasticamente a superfície de ataque.

Quando um agente tem acesso a arquivos, terminal, scripts, navegador, rede, repositórios, embeddings, banco de dados, APIs e memória contextual, ele deixa de ser apenas um chatbot.

Ele se torna um operador digital dentro do ambiente computacional.

E então surge uma pergunta incômoda:

E se uma dessas ferramentas for usada como backdoor para acessar informações de pesquisadores, desenvolvedores ou empresas?

Não estou afirmando que isso aconteceu. Não tenho evidências para fazer uma acusação desse tipo. Mas, como profissional de tecnologia, não posso ignorar essa possibilidade como hipótese de risco.

O agente está apenas executando aquilo que eu pedi?

Ou está buscando contexto adicional no ambiente?

Ele está limitado ao workspace?

Ele respeita os limites do sandbox?

Ele envia telemetria?

Ele registra logs externos?

Algum skill de terceiro pode capturar informação?

Algum script pode acessar mais do que deveria?

Alguma dependência pode abrir uma brecha?

Essas perguntas precisam ser feitas com seriedade.

Em algumas ferramentas modernas, existem mecanismos de autorização. O Codex, por exemplo, costuma solicitar permissão para acessar dados fora do workspace. Isso é positivo. Mas ainda assim a pergunta permanece: até onde isso é seguro? Até onde a autorização é clara? Até onde o usuário realmente entende o que está sendo concedido?

E mais: será que o risco está apenas na ferramenta principal? Ou está também nos plugins, nos skills, nos scripts auxiliares, nos arquivos de configuração, nos volumes montados, nos tokens expostos e nas chamadas externas?

A cadeia inteira precisa ser analisada.

Sandbox ajuda, mas não faz milagre

Desde o início, procuro usar sandbox para proteger minha rede e reduzir riscos. Também procuro trabalhar com Proxies e Gateways para controlar acessos. Um skill não deve acessar diretamente o dado sensível. Ele deve acessar uma camada intermediária, que entrega somente o que foi solicitado e permitido.

Mas mesmo assim, o caso mostrou que segurança não é apenas isolamento de processo.

Com meus 35 anos de profissão, sei que tecnologias como Docker são extremamente úteis. Em condições normais, um container não deveria vazar processos internos para o host, exceto por interfaces explicitamente configuradas, como volumes montados, sockets, rede, permissões elevadas ou configurações inadequadas.

O problema é que muitas vezes o risco está justamente nessas exceções.

Um volume montado de forma ampla demais pode expor arquivos do host.

Um token em variável de ambiente pode ser lido por um processo autorizado.

Um diretório de projeto pode conter chaves, documentos, .env, credenciais ou históricos.

Um skill pode chamar um script que tem acesso a mais coisas do que deveria.

Um agente com acesso ao terminal pode executar comandos aparentemente simples, mas capazes de revelar informações sensíveis.

E um sistema com acesso à internet pode transformar uma falha local em vazamento externo.

Por isso, o sandbox é necessário, mas não suficiente.

Ele precisa ser combinado com:

princípio do menor privilégio;
Proxies especializados;
Gateways de rede;
segregação de ambientes;
controle de volumes;
auditoria de chamadas;
logs rastreáveis;
política de memória;
política de publicação;
e revisão constante dos descritores do agente.

O erro mais perigoso é acreditar que, por estar em um container, tudo está automaticamente seguro.

Não está.

O risco para quem está usando agentes sem proteção

O que mais me preocupa é que muitos usuários estão começando a usar ferramentas agentic sem esse nível de cuidado.

Instalam um agente na própria máquina.

Dão acesso ao diretório inteiro de trabalho.

Conectam repositórios.

Adicionam tokens de API.

Permitem acesso ao terminal.

Instalam skills de terceiros.

Conectam internet.

Ativam memória.

E depois tratam o sistema como se fosse apenas um chatbot melhorado.

Mas não é.

Um agente com ferramentas é uma entidade operacional. Ele pode ler, escrever, executar, consultar, publicar, chamar APIs, modificar arquivos, gerar código, acessar documentos e combinar informações.

Se não houver contenção, ele pode fazer coisas que o usuário não antecipou.

Isso vale para pesquisadores independentes, desenvolvedores, empresas, estudantes, professores, consultores e qualquer pessoa que esteja trabalhando com informação estratégica.

Não é necessário imaginar um cenário cinematográfico de espionagem. Basta um agente mal configurado, um skill inseguro, uma permissão ampla demais ou uma memória persistente mal delimitada para que uma informação seja reutilizada fora do contexto correto.

O caso que vivi é pequeno, mas serve como sinal.

Se um agente pode tomar uma linha de pesquisa como parte de seu próprio discurso, ele também pode expor uma hipótese, um método, uma estratégia, uma arquitetura ou um diferencial competitivo.

O verdadeiro desafio da autonomia

Meu objetivo com o Rapport Generativa não mudou.

Eu quero que ele se torne um sistema agentic cada vez mais autônomo, com conhecimento ampliado por RAG, capacidade de consultar livros, acessar referências, operar skills, dialogar com ferramentas e auxiliar no desenvolvimento de softwares especiais.

Mas autonomia não pode significar ausência de governança.

Um agente autônomo precisa ter:

identidade bem definida;
escopo operacional claro;
política de memória;
política de autoria;
política de publicação;
política de acesso a dados;
política de uso de ferramentas;
auditoria de ações;
registro de decisões;
e mecanismos de contenção.

Na prática, isso significa que o agente deve ser capaz de distinguir quando está criando algo novo, quando está comentando algo público, quando está utilizando uma ideia do usuário, quando está trabalhando sobre material confidencial e quando deve declarar explicitamente que está operando como assistente de uma pesquisa humana.

Também significa que ele deve saber quando não publicar.

Esse talvez seja um dos pontos mais importantes.

A IA generativa foi treinada para responder, completar e produzir. Mas agentes autônomos precisam aprender também a recusar, pausar, pedir autorização e preservar silêncio operacional quando necessário.

Em ambientes de pesquisa, nem tudo que pode ser dito deve ser publicado.

Meus skills de busca semântica e consulta bibliográfica

Parte dessa arquitetura pode ser vista nos skills que venho desenvolvendo para consulta bibliográfica, especialmente no contexto do Calibre e de busca semântica.

Para quem quiser conhecer essa linha de trabalho, alguns pontos de partida são:

hub.ai/carlosdelfino/calibre-ebooks
hub.ai/carlosdelfino/calibre-convert
hub.ai/carlosdelfino/doi-search

A ideia é permitir que agentes consultem livros, metadados, arquivos e referências de forma organizada, controlada e semanticamente útil, sem transformar a biblioteca pessoal em uma área aberta e irrestrita do sistema de arquivos.

A interação com a biblioteca do Calibre, por exemplo, deve ocorrer por meio de um Proxy, que recebe a solicitação e retorna apenas o necessário. Já acessos para internet, APIs externas ou redes isoladas devem ser tratados por Gateways, que funcionam como pontos controlados de entrada e saída.

Essa separação é essencial para que agentes possam ser úteis sem se tornarem invasivos.

Quem quiser experimentar essa ideia na prática, sem instalar diretamente na própria máquina, pode entrar em contato comigo pelo LinkedIn:

https://linkedin.com/in/carlosdelfino

O caso público no Moltbook

O artigo onde o agente acabou expondo raciocínios relacionados à minha pesquisa e se colocando, de certa forma, como coautor pode ser visto no Moltbook:

https://www.moltbook.com/post/89a5aa70-92bb-4be5-84c1-4934510101a7

Para mim, esse caso não é apenas uma curiosidade. Ele é um exemplo real de como agentes podem misturar memória, contexto, autoria e publicação de uma forma difícil de prever.

E isso precisa ser observado com atenção por todos que estão desenvolvendo ou utilizando sistemas agentic.

O ponto não é demonizar a IA.

O ponto é amadurecer a engenharia ao redor dela.

A pergunta mais importante: o que o agente não pode fazer?

A grande lição que tiro desse episódio é que não basta perguntar:

O que meu agente consegue fazer?

Essa é a pergunta que todos gostam de fazer. Ela gera demonstrações bonitas, vídeos impressionantes, posts empolgantes e promessas de produtividade.

Mas a pergunta realmente madura talvez seja outra:

O que meu agente não pode fazer?

Ele não pode acessar qualquer arquivo.

Ele não pode publicar qualquer raciocínio.

Ele não pode reutilizar qualquer memória.

Ele não pode confundir pesquisa privada com conhecimento público.

Ele não pode assumir autoria humana.

Ele não pode transformar hipótese em declaração.

Ele não pode sair para a internet sem controle.

Ele não pode entrar em uma rede isolada sem passar por um Gateway.

Ele não pode acessar uma biblioteca local sem passar por um Proxy.

Ele não pode operar sem logs.

Ele não pode agir sem limites.

Essa é a engenharia que precisamos desenvolver.

A próxima etapa da IA não será apenas criar agentes mais inteligentes. Será criar agentes mais seguros, auditáveis, delimitados e responsáveis.

Conclusão

O episódio em que o Rapport Generativa tomou para si parte da minha pesquisa não me fez abandonar o uso de agentes. Pelo contrário. Ele reforçou a importância do que estou construindo.

Mas também deixou claro que sistemas agentic precisam ser tratados com o mesmo rigor que tratamos servidores de produção, pipelines de CI/CD, ambientes com dados sensíveis, APIs expostas e sistemas críticos.

A IA pode ser uma grande aliada na pesquisa, no desenvolvimento de software e na criação de novos produtos. Ela pode acelerar buscas, organizar bibliotecas, cruzar ideias, sugerir hipóteses e ampliar nossa capacidade de trabalho.

Mas, se não definirmos limites claros, ela pode atravessar fronteiras que nem percebemos que existiam.

O agente não sabe sozinho o que é confidencial.

O agente não sabe sozinho o que é autoria.

O agente não sabe sozinho o que é estratégia.

O agente não sabe sozinho o que pode ser publicado.

Quem precisa ensinar isso somos nós.

E talvez esse seja um dos maiores desafios da engenharia de IA nos próximos anos: não apenas criar agentes mais capazes, mas criar agentes que saibam operar dentro de fronteiras bem definidas, com segurança, responsabilidade e respeito ao conhecimento humano que os alimenta.