Um assistente de IA local pode diagnosticar a rede sem herdar acesso a ela?
Com o Transit em código aberto, a equipe pode escolher um modelo local ou hospedado. Os comandos, as credenciais e os dados que cruzam essa fronteira ainda definem o que ele pode investigar com segurança.
Uma filial relata que os telefones conseguem fazer ligações, mas nem sempre as recebem. A equipe de rede vê uma mudança de interface, um evento de roteamento e vários tempos limite. Um assistente poderia organizar as observações e sugerir o próximo comando de leitura. A escolha do modelo é só parte do trabalho. Quem opera também precisa saber quais credenciais a ferramenta pode usar, que texto sai da máquina e se o modelo pode provocar mudanças.
O Transit é uma ferramenta de investigação de redes que incorporou o cliente ao projeto de código aberto sob licença Apache 2.0 em 21 de outubro de 2026. A página da transição indica 5 de novembro como data limite para o acesso anual e 17 de novembro como data prevista para a mudança na IA hospedada. São datas da transição comercial. A disponibilidade do software e o estado de uma conta hospedada específica são questões distintas. As versões publicadas, o README e a documentação de recursos são as melhores referências para a build que a equipe pretende testar.
O que significa “local” em uma investigação?
Escolha de endpoint do modelo. Ilustração original da Telli.sh.
O cliente pode usar Ollama ou outro endpoint compatível com a API da OpenAI. A documentação também descreve o uso de uma chave própria da OpenAI ou da Anthropic e uma prévia de login para contas elegíveis do ChatGPT Plus ou Pro. Apontar o Transit para o Ollama na mesma máquina pode manter a inferência nela. Apontá-lo para um endpoint da empresa envia dados a esse endereço. Escolher um fornecedor de nuvem envia a solicitação ao fornecedor, com a ocultação de dados documentada pelo projeto.
Para reunir evidências, o cliente ainda precisa alcançar os equipamentos de rede. Uma investigação pode envolver um servidor de salto, uma conta de operador com acesso de leitura e vários dispositivos. Um endpoint local do modelo, por si só, não restringe os equipamentos que o cliente consegue contatar. Esse limite vem da conectividade e do escopo das credenciais.
O repositório documenta um conjunto limitado de ferramentas e uma lista de comandos permitidos para fornecedores compatíveis. Descreve uma política de aprovação e a possibilidade de aprovação automática, configurada pelo operador, quando uma regra corresponde em um sistema compatível. A equipe pode testar a ocultação de dados e a filtragem de comandos. Trate mensagens de apresentação dos dispositivos e logs como texto não confiável, principalmente quando trazem frases imperativas. O assistente pode resumi-los sem tomar seu conteúdo como instrução autorizada.
| Fronteira | Pergunta para o operador | Teste útil |
|---|---|---|
| Endpoint do modelo | Para onde vai o prompt montado? | Inspecionar os destinos das conexões com um caso fictício |
| Acesso aos equipamentos | A quais dispositivos e contas a ferramenta tem acesso? | Testar em laboratório um host sabidamente fora do escopo |
| Aprovação de comandos | Quem pode aprovar uma ação proposta? | Recusar um comando e confirmar que o equipamento não o executou |
| Evidências e logs | Que dados ficam guardados ou saem da máquina? | Usar marcadores inofensivos e examinar as exportações |
Switches e painéis de conexão do tipo que as equipes investigam. Foto de contexto de Dsimic, recortada e redimensionada, CC BY-SA 4.0. Fonte da imagem · Licença.
Monte o piloto em torno de uma falha conhecida
Investigação de rede. Ilustração original da Telli.sh.
Monte um laboratório pequeno com um problema conhecido de rota ou interface. Dê à ferramenta uma conta com permissões mínimas no dispositivo pretendido e inclua um host alheio que precisa continuar inacessível. Peça uma hipótese e uma lista breve de observações que poderiam refutá-la. Execute um comando show proposto depois de revisá-lo. Compare a saída com a observação coletada manualmente.
Na segunda rodada, apresente um sintoma ambíguo. Um serviço lento pode ser compatível com vários caminhos de rede, e um comando pode expor identificadores de clientes em um ambiente real. Marcadores fictícios permitem conferir onde a saída é transmitida, registrada ou retida. Mantenha o laboratório separado do servidor de salto de produção até saber o que cada modo expõe.
Ao exportar o resultado, associe comando, horário, identificação do equipamento e trecho relevante à hipótese que sustentam. Outra pessoa poderá examinar a cadeia de evidências sem depender da memória para distinguir uma frase do roteador de uma frase do modelo.
A integridade da versão e os limites do modelo local importam
O Transit informa que suas builds publicadas não têm assinatura. O arquivo SHA256SUMS de cada versão ajuda a conferir se o download corresponde ao hash publicado. Isso, por si só, não autentica quem produziu o arquivo. Equipes que precisam de artefatos assinados podem avaliar a compilação a partir de uma tag revisada com seu processo de distribuição. A documentação do instalador para Windows também exige PowerShell 7.
A inferência local reduz a dependência de um provedor de nuvem e pode se adequar a um ambiente que restringe o compartilhamento de dados. Um modelo local menor pode deixar contexto de fora, interpretar mal saídas de fornecedores diferentes ou demorar mais no equipamento disponível. Se as regras permitirem, repita o mesmo caso conhecido em uma configuração local e outra hospedada e aprovada. Meça hipóteses corretas, comandos desnecessários, associações erradas de dispositivos e tempo total do operador.
Para o primeiro uso, faz sentido esperar um coletor de evidências com alcance delimitado, aprovações automáticas desativadas e revisão humana de cada proposta. Se os testes produzirem evidências consistentes e um relato defensável, a próxima pergunta é quais investigações de leitura podem adotar esse fluxo em produção. É uma decisão mais específica e útil que conceder ao modelo acesso geral à rede.
Instale uma versão conhecida e registre seus limites
A versão v6.5.11 corrige uma divergência de nomes no manifesto de checksums, alinhando as entradas aos nomes normalizados pelo GitHub. Escolha deliberadamente a versão e a plataforma e confira o checksum publicado antes de executar o instalador. Leia as notas da versão e obtenha os arquivos no repositório oficial. Se sua organização distribui software aprovado por um catálogo gerenciado, siga esse processo. Um hash correspondente não equivale a uma autorização para instalar.
O README descreve seis ferramentas de investigação. O conjunto pequeno ajuda se a pessoa sabe onde cada ferramenta pode chegar. Liste o endpoint do modelo, o servidor de salto e o único switch de teste antes de liberar credenciais. Registre qual conta abriu cada conexão. Se alguém configurar outro servidor Ollama, confira o endereço que o cliente acessa de fato. Um serviço na rede do escritório ainda é um destino externo do ponto de vista do notebook.
- Crie um caso de laboratório com um sintoma conhecido e uma conta limitada ao equipamento pretendido.
- Verifique a build escolhida e revise o endpoint, as credenciais e as opções de retenção.
- Peça ao assistente a próxima observação e uma hipótese que ela possa refutar.
- Com a aprovação automática desativada, recuse uma proposta e confira o log do dispositivo antes de aprovar outro comando seguro.
- Insira marcadores inofensivos nos logs de exemplo. Confira se o cliente os oculta e onde aparecem nos registros locais ou no endpoint configurado.
- Exporte os resultados e peça a outro operador que reproduza o diagnóstico a partir das evidências registradas.
Quem alterna entre fornecedores deve repetir o exercício depois de mudar a configuração. O mesmo botão pode ativar um caminho de dados novo quando o endpoint muda. Um observador de rede em um laboratório autorizado pode verificar os destinos. Uma captura das configurações não estabelece, sozinha, qual destino recebeu a solicitação.
Separe o switch compatível de um shell genérico
O modelo de ameaças da versão do Transit descreve uma política de comandos para fabricantes compatíveis, incluindo aprovação automática opcional quando uma regra correspondente foi ativada antes. Um piloto pode manter essa opção desligada e exigir que um operador examine cada proposta. A ferramenta ainda precisa de uma conta com acesso restrito ao equipamento. Uma caixa de diálogo de aprovação não reduz os privilégios de uma conta de serviço.
O mesmo modelo descreve outra política para Linux e Unix genéricos. Esse caminho avisa o operador, exige aprovação comando por comando e não oferece regra de permitir sempre. A política subjacente não restringe comandos de sistemas genéricos. Deixe esse fluxo fora do primeiro piloto de leitura, a menos que a organização consiga impor o escopo de forma independente. O tipo de dispositivo e a conta fazem parte da segurança.
Outro cenário de laboratório pode testar quando aparece uma saída desconhecida. Um comando pode mostrar um contador que o modelo não reconhece, ou dois fornecedores podem usar nomes diferentes para a interface esperada. Uma resposta útil cita a observação original e pede uma checagem que distinga as hipóteses. Uma resposta mais fraca trata uma interpretação provável como fato. É possível avaliar as duas sem expor equipamento de produção.
Faça a exportação servir ao turno seguinte
Um diagnóstico de uma linha é prático para quem fez a investigação. A troca de turno precisa da última observação confirmada, do que já foi descartado, do que segue incerto e de uma forma de conferir sem reabrir todas as sessões. Ponha a referência da evidência ao lado de cada afirmação importante. Se o modelo mudar o diagnóstico após uma entrada nova no log, registre o motivo.
A melhor comparação inclui o processo manual já usado pela equipe. Anote o tempo até a primeira observação útil, o número de propostas irrelevantes e o tempo para escrever o repasse. Um modelo local pode dar uma vantagem de privacidade se fizer o trabalho em ritmo aceitável. Um modelo hospedado e aprovado pode ser mais prático para um caso difícil quando a política de dados permitir. Nos dois modos, deixe claros os caminhos de conexão e as evidências obtidas.
Acompanhe cada destino separadamente
Um registro de configuração útil lista o que sai da interface, o que segue para inferência e o que é coletado dos equipamentos. Isso facilita revisar uma troca de fornecedor. Trate as regras de retenção de cada destino separadamente. Limpar o histórico local de sessão não comprova que o endpoint descartou uma solicitação anterior.
| Modo | Destino da inferência | Uma verificação útil |
|---|---|---|
| Ollama na mesma estação | Endpoint de loopback | Confirmar que o processo acessa o serviço local pretendido |
| Servidor de inferência da empresa | Endereço interno | Verificar autenticação e retenção de prompts |
| Provedor hospedado | Endpoint do provedor aprovado | Conferir ocultação e regras com evidências fictícias |
| Prévia de login em conta | Conta elegível do provedor | Verificar a conta correta e os controles administrativos disponíveis |
A tabela descreve implantações comuns. A equipe deve observar os endpoints e a configuração do serviço que realmente escolheu. A mesma marca pode aparecer nas configurações de um serviço hospedado e de um gateway privado. Identificar o host e quem o opera permite auditar o caminho dos dados.
Use evidência sintética para testar a ocultação
Monte um log de laboratório com um endereço IP fictício, um nome inventado de dispositivo e um marcador semelhante a um identificador de cliente. Anote o que a política deve manter, mascarar ou remover. Use o mesmo exemplo em duas operações, como resumo no chat e exportação. O sistema pode montar as saídas de jeitos diferentes. Confira cada canal antes de liberar dados reais.
Outro teste deve pôr um marcador dentro de uma descrição longa ou saída formatada. Uma regra pode tratar um campo conhecido e deixar escapar o mesmo valor no texto. Se o marcador aparecer em um destino não autorizado, feche esse caminho antes de conectar equipamentos de produção. Reduza o conjunto original e repita o teste para saber qual proteção funciona.
Reavalie após atualizar
Depois de atualizar o cliente, registre o provedor escolhido e repita os mesmos casos de laboratório. Mudanças na lista de comandos ou nos critérios de aprovação automática podem alterar o que a ferramenta propõe. Mudanças nos endpoints padrão podem alterar o destino das evidências. Verifique um comando recusado, um caso de ocultação e um diagnóstico conhecido bem-sucedido. Esse conjunto pequeno de regressão facilita operar a ferramenta de código aberto conforme o ambiente muda.
Verifique as ferramentas e a conta do dispositivo em separado
Uma ferramenta de leitura pode retornar metadados ou evidências já disponíveis. Uma ferramenta de execução pode pedir dados novos ao equipamento usando a conta conectada. Deve ser possível pedir um resumo mesmo quando a execução está indisponível. Teste esse limite removendo a conexão com o equipamento e deixando o endpoint do modelo ativo. A resposta deve distinguir informações de uma observação anterior das que ela não conseguiu coletar agora.
Depois conecte uma conta capaz de inspecionar um switch, mas sem permissão para entrar no modo de configuração ou alcançar outro segmento. A equipe pode testar a recusa no seu laboratório sem pedir ao assistente que tente uma mudança real. Compare o registro de ações propostas pelo aplicativo com a auditoria de logins e comandos do equipamento. Assim, você distingue a decisão da política da ferramenta do acesso que a conta tem de fato.
Fontes
Para guardar e encontrar as conversas e decisões que fazem parte do seu trabalho, crie uma conta na Telli.sh.