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 realizam 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 próximos à 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 com credenciais e modificações de código.
Esse mesmo padrão agora está se expandindo para além dos desenvolvedores, alcançando trabalhadores do conhecimento. Agentes conectados ao desktop 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 a área de impacto 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 vetores de ataque.
Essa é a lacuna de visibilidade do endpoint que o Beacon foi construído para fechar.
O Beacon é a camada de telemetria de endpoint de código aberto do @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 sendo importantes, mas cada um vê apenas uma 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:
- 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 da ferramenta, ao caminho de aprovação ou ao diff final.
- A telemetria do agente 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 no nível do endpoint entre eles.
- A visibilidade vem antes do controle. As equipes não podem aplicar configurações, bloquear ações sensíveis, governar o acesso 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 realizando.
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 foram alterados, processos foram gerados ou conexões foram abertas. O que geralmente não pode mostrar é o fluxo de trabalho por trás do evento: o que foi solicitado ao agente, o que ele 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 encarregado de 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 encarregado de fazer uma alteração restrita em um teste: A solicitação do usuário pode ser algo como: "Atualize o teste unitário para a lógica de repetição de cobrança."
A telemetria tradicional pode mostrar:
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 de segredos 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 com reconhecimento de agente conecta esses mesmos eventos de volta ao fluxo de trabalho:
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 lhe foi solicitado.
Beacon: Uma Camada de Telemetria de Endpoint para Agentes de IA
A maioria das equipes de segurança e TI consegue 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, atividades semelhantes 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 foi solicitado ao agente, qual contexto ele tinha, quais ferramentas invocou, quais aprovações foram necessárias e o que mudou no endpoint.
O Beacon preenche essa lacuna configurando OpenTelemetry onde há suporte, coletando sinais locais onde disponíveis e mapeando a atividade fragmentada do agente em um formato de evento de endpoint comum.
Conforme mostrado na Figura 1, o Beacon conecta quatro camadas:
- Runtimes de agente: Claude Code, Codex, Cursor, Claude Cowork, OpenClaw e modelos locais geram prompts, planos, chamadas de ferramentas, aprovações, diffs e estado de execução.
- Atividade de 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.
- Normalização do Beacon: O Beacon transforma OpenTelemetry fragmentado, sinais 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 à ação local.
- Destinos de segurança: O Beacon escreve JSONL compatível com Wazuh hoje. O mesmo fluxo de eventos normalizado pode se estender para os 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 runtime tornam-se parte de um registro de 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 a partir do 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 foi solicitado aos agentes, o que eles tocaram, o que mudaram e se as ações sensíveis foram aprovadas.
Esta camada precisa ser confiável. O Beacon é de código aberto e licenciado sob MIT porque opera próximo ao fluxo de trabalho do desenvolvedor, código-fonte, credenciais e sistemas próximos à 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.
O Beacon é o nosso primeiro passo para tornar isso realidade.
