Protegendo agentes nos terminais da Perplexity com o Numbat

Agentes de IA devem ser seguros para serem úteis. À medida que as capacidades de modelos e sistemas avançam, também aumenta a vigilância necessária para proteger os usuários.

Pesquisas iniciais de segurança de agentes focavam em injeções de prompt e outras formas de entradas adversárias. No entanto, avanços recentes na autonomia dos agentes dão origem a incidentes de segurança que não precisam pressupor a existência de entradas adversárias — ou de qualquer adversário humano.

Pelo contrário, agentes orientados a buscar metas de alto nível, sem orientação prescritiva sobre como atingir tais objetivos, podem se tornar o adversário. Isso ocorre quando um agente, em resposta a uma meta especificada pelo usuário, seleciona um curso de ação que o usuário não pretendia e não teria aprovado. Embora tais incidentes fossem teorizados há apenas alguns meses, rapidamente se tornaram questões de preocupação prática.

Como esses comportamentos não podem ser totalmente corrigidos na camada do modelo, uma defesa robusta deve, portanto, habitar o sistema circundante, incluindo o harness de agente que serve como interface do modelo com o mundo exterior. Estamos disponibilizando como open-source o Numbat, nossa suíte de segurança de agentes que ajuda defensores a prevenir, detectar e mitigar incidentes relacionados a agentes. O Numbat identifica e integra-se diretamente com harnesses de agentes comumente encontrados em terminais de clientes corporativos, aplicando regras de segurança e permitindo detecção e resposta rápidas.

A adoção de agentes impõe novos desafios de segurança para desenvolvedores, adotantes e defensores. Isso é especialmente verdadeiro quando empresas implantam agentes diretamente em terminais de clientes com acesso privilegiado a sistemas e dados corporativos.

Implantações de agentes em terminais de clientes, como agentes de codificação baseados em CLI ou aplicativos de desktop, vêm com níveis variados de sandboxing e isolamento. Os usuários utilizam esses agentes para inúmeros casos de uso, cada um com seu próprio espaço de ação associado que pode afetar o próprio terminal ou outros sistemas acessíveis a partir dele. Cada vez mais, espera-se que os agentes operem autonomamente por horas ou até dias. Para esses fluxos de trabalho, muitos usuários optam por delegar aprovações de ações do agente a classificadores, ou contornar as aprovações inteiramente com sinalizadores de configuração com nomes preocupantes como --dangerously-skip-permissions e --yolo. A multiplicidade de casos de uso e configurações de agentes, combinada com a amplitude de ações que os agentes de codificação podem realizar em terminais privilegiados, cria um perfil de risco que exige gestão proativa pelas equipes de segurança.

Hoje, estamos lançando o Numbat, uma suíte de segurança de agentes open-source que criamos para detectar, investigar e prevenir atividades perigosas de agentes de IA. À medida que mais empresas adotam produtos de agentes de ponta, o Numbat capacita as equipes de segurança a acompanharem os desafios de segurança resultantes. Ele se integra a cada um dos harnesses de agentes do lado do cliente mais utilizados, expondo uma interface consistente entre todos eles. O Numbat, portanto, libera as equipes de segurança do ônus de construir salvaguardas personalizadas e ferramentas de monitoramento para cada agente individual do qual seus usuários dependem. O Numbat está disponível para o ecossistema de defesa como parte da participação da Perplexity na Open Secure AI Alliance com a NVIDIA e outras organizações.

Arquitetura de sistema de agentes protegidos pelo Numbat. O Numbat enfatiza a detecção local-first e a perícia independente de agente.

Este artigo começa com uma discussão sobre os desafios de segurança que motivam o Numbat. Em seguida, apresentamos o design e a arquitetura do Numbat, juntamente com nossas lições aprendidas ao implantar o Numbat em milhares de terminais da Perplexity.

O cenário de incidentes de segurança de agentes de IA está evoluindo rapidamente. Grande parte da literatura existente sobre segurança de agentes foca em ataques de injeção, nos quais um payload malicioso é introduzido em prompts de modelo ou contexto para confundir os agentes em comportamentos impróprios. Ataques de injeção e salvaguardas foram extensivamente estudados, e desenvolvedores de agentes, incluindo a Perplexity, desenvolveram defesas cada vez mais robustas contra ataques de injeção.

Mas um agente de IA não precisa de um payload malicioso para criar um incidente de segurança. Na verdade, não é necessário pressupor a existência de um adversário. Um agente confiável, operando dentro de um ambiente confiável com ferramentas aprovadas pelo administrador, pode realizar ações prejudiciais simplesmente porque está tentando se esforçar demais para concluir sua tarefa.

Pesquisadores descrevem esse modo de falha como um “colapso acidental”: comportamento prejudicial do agente acionado não por entrada adversária, mas por um erro ambiental comum. Um arquivo ausente, uma solicitação de API que falhou, credencial expirada ou negação de permissão pode levar um agente a buscar uma solução alternativa. Ao perseguir sua meta original especificada pelo usuário, o agente pode cruzar limites de segurança por meio de reconhecimento não autorizado, alterações de controle de acesso, descoberta de segredos ou exfiltração de dados. Em vez de o agente ser cooptado por um atacante, o próprio agente é o atacante. Além disso, o ataque pode ter como alvo sistemas internos, externos ou ambos, sem forma de saber até que o ataque já esteja em curso.

O primeiro colapso acidental amplamente relatado ocorreu este mês, com a divulgação pela OpenAI de um ataque iniciado por agente que comprometeu a infraestrutura de produção da Hugging Face. Durante as avaliações de um modelo GPT de pré-lançamento, o modelo se viu incapaz de progredir na avaliação com o contexto fornecido. Para quebrar esse impasse, o modelo encontrou uma maneira de escapar de seu ambiente de teste de sandbox e exfiltrar as respostas da avaliação da Hugging Face. O modelo aproveitou seu harness para escapar de restrições de rede pretendidas, escalar privilégios além dos limites da sandbox, obter segredos e acessar sistemas seguros da Hugging Face, tudo para buscar o objetivo restrito de resolver a avaliação.

Colapsos também incluem mutações e exclusões não intencionais de sistemas. Embora talvez mais comuns do que violar um sistema externo, essas ocorrências são mais frequentes e relevantes para qualquer usuário avançado de agentes de codificação. Excluir bancos de dados de produção ou diretórios home é o pior pesadelo de qualquer desenvolvedor, e os agentes devem ser capazes de evitar tais comportamentos durante sua execução.

Pesquisadores de IA estão trabalhando para mitigar esses comportamentos nos próprios modelos. Embora esses esforços sejam certamente valiosos, muitos na comunidade de pesquisa percebem uma tensão fundamental entre treinar modelos para propriedades de segurança fortes e treinar esses mesmos modelos para realizar tarefas cada vez mais complexas. Acreditamos ser improvável que defesas que focam apenas na camada do modelo reduzam o risco de colapso a níveis aceitáveis.

O resultado é que a segurança do agente não pode depender apenas de salvaguardas de nível de modelo, usuário ou tarefa. Em vez disso, as equipes de segurança precisam de visibilidade do que os agentes realmente fazem nos terminais dos clientes, além de controles que possam impedir ações perigosas antes que sejam executadas. Esses são controles de nível de sistema que devem ser integrados firmemente ao harness do agente.

O Numbat fornece esses controles na forma de um binário Go estático leve que se conecta perfeitamente aos principais harnesses de agentes do lado do cliente. Ele oferece monitoramento em tempo real, aplicação de políticas e reconstrução forense em todos os harnesses de agentes e ambientes de execução.

Os principais pontos de integração entre o Numbat e um harness de agente são hooks, artefatos de Sessão e telemetria OTLP. Discutimos cada um sucessivamente.

Praticamente todos os agentes de codificação possuem um subsistema de hook. Os hooks permitem que os agentes executem sub-rotinas de forma determinística em pontos pré-especificados dentro do ciclo de vida de execução do agente. Os usuários de agentes geralmente configuram hooks para fornecer aos modelos contexto adicional de maneiras previsíveis, implementar loops de teste e verificação e fazer outras melhorias nas capacidades do agente.

As mesmas propriedades determinísticas que tornam os hooks atraentes para esses fins também os tornam atraentes para detecção e resposta. Normalmente, é insuficiente capturar a maioria das ocorrências de um evento potencialmente preocupante. Em vez disso, deve-se cobrir todas essas ocorrências para detecção e resposta. O Numbat configura vários tipos de hooks, permitindo que equipes de segurança e administradores de TI implementem lógica de detecção rica.

Na maioria dos agentes de codificação, certos tipos de hooks (comumente chamados de hooks de “pré-ação”) também são capazes de bloquear a execução da próxima ação do agente. Usando esses hooks de pré-ação, o Numbat é capaz de implementar não apenas lógica de detecção, mas também regras de segurança preventivas para impedir que um colapso ocorra em primeiro lugar.

Hooks são meios poderosos de implementar lógica de detecção e prevenção em tempo real. No entanto, essa lógica deve ser especificável em código. Muitas vezes, um incidente de segurança de agente assume uma forma que não poderia ter sido prevista com antecedência, muito menos reduzida a código-fonte. Portanto, o Numbat também tem a capacidade de acessar e analisar artefatos de Sessão retroativamente.

Artefatos de Sessão incluem muitos tipos de logs e diagnósticos. Talvez o tipo mais importante de log seja a transcrição da Sessão, que registra as conversas de LLM que ditam a sequência de ações do agente. Usuários avançados de agentes de codificação já estão acostumados a exportar transcrições de Sessão para análise adicional por meio de comandos fornecidos pelo harness. Mas essas exportações geralmente estão em formato de texto simples, que é inadequado para equipes de segurança que exigem logs legíveis por máquina com um esquema consistente e previsível.

O Numbat, portanto, recupera artefatos de Sessão diretamente do próprio sistema de arquivos. Como a maioria dos harnesses de agentes do lado do cliente armazena artefatos originais no sistema de arquivos (geralmente dentro de um diretório dot específico do agente em $HOME), acessar o sistema de arquivos fornece a rota mais direta para esses dados em sua forma mais utilizável e pura. Equipes de segurança que usam o Numbat podem coletar esses artefatos em formato de linha do tempo NDJSON normalizado por meio do numbat scan, seja para processamento local no terminal do cliente ou análise remota assíncrona. Como os artefatos de Sessão são registros estáticos e autônomos, o Numbat é capaz de reconstruir essas linhas do tempo mesmo para sessões ocorridas muito antes de o Numbat ser instalado.

A maioria dos harnesses de agentes do lado do cliente oferece telemetria extensa por meio do protocolo OpenTelemetry (OTLP). Essa telemetria geralmente fornece muitos sinais além daqueles disponíveis por meio de hooks ou artefatos de Sessão.

O Numbat pode funcionar como um receptor OTLP por meio do comando numbat collect. Este comando inicia um servidor para o qual os agentes de codificação enviam telemetria OTLP para análise downstream. Importante: este servidor é local e ouve por padrão apenas no localhost, o que significa que toda a telemetria permanece no dispositivo por padrão. Os administradores de segurança podem então determinar o que fazer com a telemetria registrada, seja isso envolvendo a implementação de processamento leve no dispositivo, processamento remoto via numbat ship ou análises mais complexas em plataformas de analytics como ClickHouse.

Dentro da Perplexity, usamos o Numbat para proteger o uso pelos nossos engenheiros de agentes de codificação do lado do cliente, incluindo Claude Code, Codex, OpenCode e Pi.

Tanto nossos esforços de prevenção quanto de detecção fazem uso extensivo das regras do Numbat, que são implementadas por meio do subsistema de hook de cada agente. Formulamos várias regras essenciais para nossas próprias necessidades, muitas das quais disponibilizamos como parte das 52 regras integradas do Numbat. Essas regras são organizadas em 11 categorias de comportamento e um conjunto de detecções de sequência de várias etapas, como acesso a segredos, exfiltração, escalonamento de privilégios e movimento lateral. As regras usam expressões CEL sobre eventos normalizados, e os operadores podem adicionar suas próprias regras e testes sem alterar o código do Numbat.

Por exemplo, a regra integrada privilege.sudoers_tamper detecta gravações na política sudoers, uso de visudo e tentativas de instalar concessões NOPASSWD. Essas são ações de alto sinal que podem transformar um processo de agente limitado em acesso root persistente.

yaml

# privilege.sudoers_tamper (simplified for readability)
id: privilege.sudoers_tamper
severity: high
expr: |
  (
    event.event_type == "file.write" &&
    event.file_path.matches("(^|/)etc/sudoers$|(^|/)etc/sudoers\\.d/[^/]+$")
  ) || (
    event.event_type == "command.exec" &&
    event.command.matches("\\bvisudo\\b|\\bNOPASSWD\\s*:")
  )

Comandos individuais nem sempre parecem maliciosos por si sós, então o Numbat também correlaciona sequências dentro de uma Sessão de agente. A regra integrada chain.secret_manager_read_then_egress detecta quando um agente lê um valor de uma ferramenta comum de gerenciamento de segredos e, posteriormente, tenta uma solicitação curl ou wget contendo dados. Uma leitura de segredo pode ser legítima. Uma solicitação de saída pode ser legítima. Sequenciadas juntas, elas exigem investigação.

yaml

# chain.secret_manager_read_then_egress (simplified for readability)
id: chain.secret_manager_read_then_egress
severity: high
sequence:
  within_events: 64
  steps:
    - expr: |
        event.event_type == "command.exec" &&
        event.command.matches("secretsmanager|get-secret|vault read")
    - expr: |
        event.event_type == "command.exec" &&
        event.command.matches("curl.*(--data|--upload-file)|wget.*--post")

Como o Bumblebee, nosso scanner open-source para exposição da cadeia de suprimentos em terminais de desenvolvedores, o Numbat é implantado em toda a nossa frota por meio de MDM. Cada Numbat registra a atividade do agente localmente e envia telemetria estruturada para nossos sistemas de segurança centralizados.

A partir daí, a Perplexity Computer revisa as descobertas recentes e os logs de auditoria do Numbat em um cronograma recorrente em busca de comportamento suspeito ou malicioso. Ela investiga detecções, reconstrói sessões de agentes relevantes e analisa minuciosamente as ações que o Numbat bloqueou.

Pipeline interno da Perplexity para monitorar a telemetria do Numbat. Uma tarefa agendada da Perplexity Computer revisa assincronamente novos sinais e alerta a equipe de segurança sobre atividades de risco.

A Computer também procura lacunas em nossa cobertura. Ela analisa novos comportamentos, propõe melhorias nas detecções do Numbat, testa essas mudanças e abre pull requests para revisão humana. Uma vez aprovadas e implantadas, essas regras melhoram o monitoramento em toda a frota e produzem melhores evidências para a próxima investigação.

Isso cria um volante de segurança que se autoaperfeiçoa: agentes geram atividade, o Numbat transforma essa atividade em linhas do tempo normalizadas e telemetria, a Computer investiga e melhora as regras, e atualizações revisadas por humanos fortalecem os controles que protegem futuras sessões de agentes.

Na Perplexity, acreditamos que agentes de IA serão executados em todos os tipos de ambientes: locais, nuvem e híbridos. Cada combinação de harness de agente e ambiente de execução impõe desafios de segurança únicos, com a complexidade combinatória ameaçando sobrecarregar equipes de segurança com recursos limitados. Colapsos de agentes e outras vulnerabilidades novas complicam ainda mais o quadro de segurança.

Defesas que habitam o próprio sistema do agente podem melhorar a postura de segurança de um usuário, não importa onde o agente seja executado. É precisamente isso que o Numbat oferece: salvaguardas de agente integradas que permitem aos defensores prevenir, detectar e responder a comportamentos preocupantes em tempo real. Combinar o Numbat com a Perplexity Computer cria uma plataforma de segurança de agentes poderosa que capacita os defensores a ficarem à frente da curva.

O Numbat está disponível hoje como um projeto open-source para macOS, Linux e Windows. Nossos próprios terminais de clientes são protegidos pelo Numbat, permitindo que os membros da equipe da Perplexity usem agentes com confiança em tarefas de escopo amplo e longo prazo. Convidamos as equipes de segurança de todos os lugares a aproveitar a abordagem de nível de sistema do Numbat para garantir e proteger suas implantações de agentes.

BibTeX

@online{perplexity2026SecuringAgentsAcrossPerplexitySClientEndpointsWithNumbat,
  author = {{Perplexity} and Adel Karimishiraz and Bex Brooker and Phi Hoang and Jerry Ma},
  title = {{Securing agents across Perplexity's client endpoints with Numbat}},
  date = {2026-07-29},
  url = {https://perplexity.coolkeypoint.com/hub/blog/securing-agents-across-perplexity-s-client-endpoints-with-numbat}
}

Introdução

Situando o cenário de vulnerabilidade

Protegendo agentes de codificação por meio de integrações nativas de harness

Hooks

Artefatos de Sessão

Telemetria OTLP

Implantando o Numbat dentro da Perplexity

Gerenciando e monitorando Numbats em toda a frota

Conclusão

Citação