Conheça o Beacon: Telemetria de Endpoint para Agentes de IA

A primeira geração de segurança de IA se concentrou no gateway do modelo. A próxima se moverá para o endpoint, onde os agentes realmente fazem o trabalho.

Os gateways faziam sentido quando os sistemas de IA respondiam principalmente a perguntas. Uma equipe de segurança podia colocar um ponto de controle entre o usuário e o modelo, inspecionar prompts e saídas, aplicar DLP, mediar o acesso ao modelo e registrar a troca.

Os agentes forçam essa arquitetura a evoluir. O problema de segurança não é mais apenas o que um modelo diz ou vê. É o que um agente pode fazer: usar as ferramentas do usuário, herdar suas permissões e alterar o estado dentro de ambientes sensíveis.

O exemplo mais claro é a máquina do desenvolvedor. Agentes de codificação como Claude Code, Codex e Cursor são executados junto com código-fonte, terminais, gerenciadores de pacotes, CLIs de nuvem, credenciais locais e sistemas adjacentes à produção. Uma única solicitação em linguagem natural pode se transformar em leituras de arquivos, comandos de shell, alterações de dependências, ações autenticadas e modificações de código.

Esse mesmo padrão agora está se expandindo além dos desenvolvedores para trabalhadores do conhecimento. Agentes conectados à área de trabalho estão começando a operar em aplicativos SaaS, ferramentas locais e sistemas internos. Espaços de trabalho de agentes como Claude Cowork e OpenClaw apontam para a próxima fase da IA empresarial: o laptop do usuário se torna o ambiente de execução para trabalho delegado em aplicativos empresariais.

A dura realidade hoje é que as equipes de segurança podem ver o raio de explosão somente depois que um agente executou comandos, modificou arquivos, instalou dependências ou exfiltrou dados. Os modos de falha já são graves: execução remota de código através da configuração de projeto do Claude Code, exposição de código privado através de injeção de prompt no Copilot Chat e roubo de credenciais através de pacotes npm maliciosos que transformam agentes de codificação locais em caminhos de ataque.

Essa é a lacuna de visibilidade do endpoint que o Beacon foi construído para fechar.

Beacon é a camada de telemetria de endpoint de código aberto da @asymptotelabs para agentes de IA. É o nosso primeiro passo para tornar a atividade do agente local observável, compreensível e, eventualmente, governável em toda a empresa.

O Que Isso Significa para as Equipes de Segurança

Para as equipes de segurança, isso é importante porque a pilha existente não foi projetada para explicar o trabalho delegado. Gateways, EDR e telemetria nativa de agentes continuam importantes, mas cada um vê apenas parte do que um agente está fazendo. Para governar agentes com segurança, as equipes precisam ver como um agente passa da intenção à ação no endpoint.

Três lacunas se destacam:

1. Os logs de endpoint mostram efeitos, não fluxos de trabalho. Eles podem capturar comandos, alterações de arquivos e atividade de processos, mas raramente conectam esses eventos de volta à solicitação do agente, decisão de ferramenta, caminho de aprovação ou diff final.
2. A telemetria de agentes precisa de uma camada comum. Agentes de codificação de IA como Claude Code, Cursor, Codex e Claude Cowork expõem diferentes sinais de telemetria. As equipes de segurança precisam de um registro unificado em nível de endpoint entre eles.
3. A visibilidade vem antes do controle. As equipes não podem aplicar configurações, bloquear ações sensíveis, governar o acesso ao MCP ou proteger segredos até saberem quais agentes estão em execução, quais permissões eles têm e quais ações estão tomando.

Logs de Endpoint Não Capturam Fluxos de Trabalho de Agentes

A telemetria tradicional de endpoint é necessária, mas insuficiente para entender o comportamento do agente.

Ela pode mostrar que comandos foram executados, arquivos alterados, processos iniciados ou conexões abertas. O que geralmente não pode mostrar é o fluxo de trabalho por trás do evento: o que o agente foi solicitado a fazer, o que decidiu fazer e se a ação fez sentido para a tarefa.

A mesma ação do agente pode ser segura ou arriscada dependendo da tarefa ao redor. Por exemplo:

• Um comando kubectl pode ser apropriado durante um incidente de infraestrutura, mas inadequado para um agente de codificação solicitado a atualizar um teste unitário.
• Uma leitura de .env pode ser esperada durante a depuração local, mas suspeita durante uma edição de documentação.
• Uma alteração no Terraform pode ser normal em um repositório de infraestrutura, mas perigosa quando introduzida como efeito colateral de uma atualização de dependência.

Em cada caso, o evento bruto não é suficiente. O significado de segurança depende do fluxo de trabalho ao redor: o prompt, o plano, o contexto acessado, as ferramentas invocadas, os arquivos tocados, as credenciais usadas e as aprovações concedidas.

Considere um agente de codificação solicitado a fazer uma alteração de teste restrita: A solicitação do usuário pode ser algo como: “Atualize o teste unitário para a lógica de repetição de faturamento.”

A telemetria tradicional pode mostrar:

1- test/billing_retry_test.py modificado
2- .env lido
3- terraform/production/main.tf modificado
4- kubectl rollout restart deployment/billing

Esses eventos são úteis, mas estão desconectados do fluxo de trabalho do agente. O log mostra que um teste foi alterado, um arquivo secreto foi lido, o Terraform foi modificado e um comando de implantação foi executado. Ele não mostra se essas ações faziam parte da solicitação do usuário, qual decisão de ferramenta as produziu ou se o usuário aprovou as etapas sensíveis.

Um registro ciente do agente conecta esses mesmos eventos de volta ao fluxo de trabalho:

1- Solicitação do usuário: "Atualize o teste unitário para a lógica de repetição de faturamento."
2- Plano do agente: editar apenas o arquivo de teste
3- Chamada de ferramenta: ler .env (coleta de contexto)
4- Chamada de ferramenta: editar test/billing_retry_test.py
5- Chamada de ferramenta: editar terraform/production/main.tf (não relacionado à solicitação)
6- Aprovação necessária: sim (para edição do terraform)
7- Aprovação concedida: sim
8- Chamada de ferramenta: kubectl rollout restart deployment/billing (não relacionado à solicitação)
9- Diff final: arquivo de teste alterado + terraform alterado + implantação reiniciada

Sem esse rastreamento, as equipes de segurança ficam reconstruindo a intenção a partir de artefatos de baixo nível após o fato. Elas podem ver os efeitos da atividade do agente, mas não se o comportamento do agente foi apropriado para o trabalho que foi solicitado a fazer.

Beacon: Uma Camada de Telemetria de Endpoint para Agentes de IA

A maioria das equipes de segurança e TI pode responder quais modelos são aprovados ou quais gateways estão implantados. Quando os agentes são executados localmente, as questões de segurança se aproximam do endpoint:

• Inventário de agentes: Quais ferramentas de agente estão instaladas? Quais usuários e dispositivos as estão executando?
• Contexto de execução: Em quais repositórios e espaços de trabalho os agentes estão operando? Quais ferramentas, credenciais e permissões locais eles podem herdar?
• Atividade do agente: Quais arquivos os agentes estão lendo ou modificando? Quais comandos, aprovações e diffs estão gerando?
• Telemetria e auditoria: Qual telemetria está sendo coletada e para onde está sendo enviada? As equipes de segurança podem conectar a solicitação original do usuário às ações tomadas?

A telemetria nativa do agente ajuda, mas é fragmentada. Claude Code e Codex podem exportar OpenTelemetry. O Cursor expõe hooks para sessões, prompts, uso de ferramentas, execução de comandos, aprovações, atividade semelhante a MCP e edições de arquivos. O Claude Cowork pode exportar telemetria através de um endpoint OTLP configurado pelo administrador.

O que as equipes de segurança precisam é de um registro de fluxo de trabalho que as abranja: o que o agente foi solicitado a fazer, qual contexto ele tinha, quais ferramentas invocou, quais aprovações foram necessárias e o que mudou no endpoint.

Beacon preenche essa lacuna configurando OpenTelemetry onde suportado, coletando sinais locais onde disponíveis e mapeando a atividade fragmentada do agente em um formato de evento de endpoint comum.

Como mostrado na Figura 1, o Beacon conecta quatro camadas:

1. Tempos de execução de agentes: Claude Code, Codex, Cursor, Claude Cowork, OpenClaw e modelos locais geram prompts, planos, chamadas de ferramentas, aprovações, diffs e estado de execução.
2. Atividade do endpoint: Esses agentes interagem com a máquina: arquivos, terminais, gerenciadores de pacotes, servidores MCP, CLIs de nuvem, repositórios, credenciais e configuração local.
3. Normalização do Beacon: O Beacon transforma sinais fragmentados de OpenTelemetry, baseados em hooks e de endpoint em um fluxo de eventos JSON comum, para que as equipes de segurança possam seguir a cadeia da solicitação do agente até a ação local.
4. Destinos de segurança: O Beacon escreve JSONL compatível com Wazuh atualmente. O mesmo fluxo de eventos normalizado pode se estender para SIEMs, data lakes, plataformas de observabilidade, pipelines de detecção e fluxos de trabalho de endpoint que as empresas já usam.

Com o Beacon, prompts, chamadas de ferramentas, comandos, edições de arquivos, aprovações, interações MCP e alterações de tempo de execução se tornam parte de um registro em nível de endpoint: uma cadeia mais clara da solicitação do usuário à ação local, entre agentes e ferramentas.

Visibilidade Primeiro, Controle Depois

Os agentes estão se tornando uma nova camada de execução dentro da empresa.

Eles leem arquivos, chamam ferramentas, usam credenciais, modificam sistemas e agem com a autoridade das pessoas que delegam trabalho a eles. Essa atividade não pode ser compreendida ou governada apenas pelo gateway do modelo.

O endpoint é onde o contexto, a autoridade e a ação do agente se unem. É onde prompts se tornam comandos, ferramentas herdam permissões, credenciais são usadas e alterações são feitas.

Isso torna a telemetria de endpoint a base para a segurança do agente.

O Beacon torna a atividade do agente local observável nas ferramentas que as empresas já estão adotando. Ele dá às equipes de segurança um registro comum do que os agentes foram solicitados a fazer, o que tocaram, o que mudaram e se as ações sensíveis foram aprovadas.

Essa camada precisa ser confiável. O Beacon é open source e licenciado sob MIT porque é executado próximo ao fluxo de trabalho do desenvolvedor, código-fonte, credenciais e sistemas adjacentes à produção. Os desenvolvedores devem poder inspecionar o que é coletado. As equipes de segurança devem poder verificar a telemetria. As equipes de TI devem entender exatamente o que estão implantando.

A atividade do agente deve ser observável antes de ser governável.

Beacon é o nosso primeiro passo para tornar isso realidade.