Show HN: Continue? Y/N: um jogo de 60 segundos sobre a fadiga de permissões de agentes de IA

 (llmgame.scalex.dev)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Continue? Y/N é um experimento que transforma a fadiga de permissões de LLMs em um jogo de 60 segundos, testando o quão cuidadosamente você lê comandos de IA
  • Faltando apenas 1 minuto para a próxima reunião, o Claude Code pede aprovação de comandos para terminar uma refatoração
  • O usuário precisa processar o máximo possível dentro do tempo limite e, ao ler cada comando, aprova com 1 ou rejeita com 2
  • O desafio central é manter o foco mesmo em um fluxo exaustivo de pedidos repetidos de aprovação, capaz de deixar a vista turva
  • A regra é processar o máximo possível em 60 segundos, mas lendo cada comando com atenção para decidir se deve aprová-lo ou não

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Opiniões no Hacker News

  • Muito divertido

    No momento, dá para “trapacear” rejeitando todos os pedidos o mais rápido possível. Aí você ganha o distintivo de security-conscious engineer e ainda faz pontuação máxima pelo número de solicitações processadas. O alerta de “overblock” aparece, mas fica escondido embaixo, e a tela ainda parece mostrar que você venceu

    Também tentei aprovar o máximo possível bem rápido, como um engenheiro no estilo hustle4lyfe que “se move rápido e quebra tudo”, mas isso acabou me deixando mais lento por causa dos pop-ups de malicious command. Sacanagem

    • Boa pegada, e agora isso foi nerfado e ganhou um título separado
    • Igual à vida real. Se você rejeitar tudo e impedir qualquer coisa de acontecer, é seguro :)

  • Jogo divertido, mas também mostrou uma falta de higiene de segurança por parte de quem fez. Ele dizia que cat ~/.zshrc era perigoso porque compartilhava tokens e segredos, mas eu nunca colocaria segredos num arquivo de configuração do shell

    • Muita gente faz isso. Dito isso, esses valores estariam em variáveis de ambiente, e o Claude provavelmente já teria acesso a elas de qualquer forma
    • Eu pessoalmente não faço isso, mas consigo ver muita gente fazendo
    • Colocar segredos num LLM em si não é inerentemente inseguro; isso é só um dos três elementos fatais
    • Ter “tokens e segredos” ali para começo de conversa já é falta de higiene de segurança
    • Então você colocaria onde?

  • Acho estranho tratar a leitura do zshrc como algo arriscado. Eu colocaria isso sem problema no meu repositório público de dotfiles; afinal, quem colocaria chaves de API ali? Por outro lado, parece que essas ferramentas de IA ficam adicionando coisas ao PATH ali o tempo todo, então talvez exista um mal-entendido fundamental em toda a indústria de IA sobre boas práticas de shell

    Além disso, dar kill em resultados de lsof não é seguro. Por exemplo, se você estiver com uma página aberta no Firefox, ou tiver um subshell cliente dentro do próprio agente, o Firefox e o agente vão juntos pro espaço

    • Exato. O jogo parece assumir que, se o Claude disse que era seguro, então executar kill também é seguro. Mas o ponto principal é que você não deve confiar no Claude

  • Gostei. Só tenho uma pequena implicância

    npm config set registry [https://npm.internal](<https://npm.internal>;)

    O texto dizia que, como a documentação de onboarding exigia isso, tratava-se de um comando para apontar o npm para um espelho interno do registro da empresa, e o jogo avaliou isso como seguro. Eu fiquei na dúvida e no fim rejeitei

    Se esse README for para um repositório público ou um fork, e esse https://npm.internal na verdade for https://npm.internal.somethinganexternaldnscanresolve.tld, isso pode dar muito errado muito rápido

    Em 99% dos casos, a política da empresa já terá um espelho configurado como Artifactory / Nexus. Se um README mandar usar a URL de outro gerenciador de pacotes, isso é um grande sinal de alerta, e você está a segundos de um incidente

    • Boa observação. .internal é um domínio de topo reservado e não deveria resolver publicamente, mas você tem razão ao dizer que é preciso cuidado ao mudar valores que deveriam ser configurados separadamente enquanto deixa o Claude refatorar o projeto. Vou mover isso para a categoria de mudança permanente

  • Joguinho divertido, mas acho que as perguntas pulam contexto demais para representar bem situações reais. Talvez fosse melhor agrupá-las em “pacotes” para dar uma estrutura mais realista

    Por exemplo, receber vários pedidos de permissão para editar um arquivo something.js e então aparecer um npm publish faz muito mais sentido e é bem mais perigoso. Se você já estiver apertando Y o tempo todo, fica muito mais fácil cair nisso quando surgir do nada

  • Umas três quartas partes das opções “ruins” seriam coisas cujo vazamento eu não ligaria muito e, mesmo que virassem um incidente de produção, provavelmente não renderiam punição por parte do empregador

  • Verificar permissões mata bastante a produtividade. Se você vai rodar o Claude, acho mais eficiente executá-lo num sandbox descartável ou em algo como um contêiner Docker com só as permissões que você toparia conceder na sua máquina pessoal

    [1] - https://exe.dev/ é um novo provedor de nuvem com uma experiência de usuário para agentes bem útil

    [2] - Criei o https://github.com/stanislavkozlovski/dclaude/ para esse propósito. Não é perfeito, mas, quando raramente preciso rodar um agente de programação localmente, ele resolve meu problema

    • Sandboxes descartáveis não evitam vazamento de segredos. Se você não tratar o código como segredo, até dá para montar um sandbox sem segredo nenhum, mas aí os tipos de tarefas que o agente consegue fazer ficam bem limitados

  • Na tela de pontuação do final, eu gostaria que também mostrasse a explicação do LLM para os comandos que não deveriam ter sido aprovados. Eu aprovei o comando rm -rf Projects porque achei que o LLM tinha explicado corretamente que aquilo apagaria tudo dentro da pasta Projects

    Como eu estava respondendo rápido aos prompts, claramente li errado, e como eu sabia o que o comando fazia, acho que alucinei que a IA tinha explicado isso. Mesmo assim, queria ver exatamente o que foi que eu interpretei errado

    Jogar esse jogo me deixou muito feliz por eu não ser agentmaxx

  • Escolhi “approve” em ls -la ~/Documents e errei, mas não considero listar a pasta Documents um problema de segurança. São só nomes de arquivos. Se fosse ler o conteúdo dos arquivos, aí talvez...