Modelo de segurança

O agente do Jiraya roda na sua máquina, com o usuário do sistema que iniciou o daemon. Tudo o que esse usuário pode ler, escrever ou executar, o agente também pode. Esta página mostra o que o Jiraya separa entre execuções e onde está o limite real.

O limite é o usuário do daemonCopiar link da seção

As ferramentas de IA rodam sem pedir aprovação a cada comando, porque não há ninguém olhando o terminal. O Claude Code, por exemplo, roda com as permissões liberadas, e o GitHub Copilot CLI e o Qoder, no modo que aprova todas as ferramentas. O Codex segue o modo de sandbox e de aprovação da configuração dele na sua máquina.

Na prática, o agente consegue rodar qualquer comando que o usuário do daemon rodaria: ler arquivos da sua pasta pessoal, usar as suas chaves SSH e as credenciais da nuvem configuradas na máquina, e acessar a rede.

O que o Jiraya isolaCopiar link da seção

• Diretório por execução. Cada tarefa trabalha num diretório próprio em ~/jiraya_workspaces, acessível só pelo seu usuário, com um diretório temporário próprio.
• Token por execução. O agente recebe um token do Jiraya válido só para aquela execução, ligado ao agente e ao workspace. Ele é apagado quando a execução termina. Dentro da execução, a CLI jiraya usa esse token, e não o que você guardou no login.
• Autoria registrada. O que o agente faz pela CLI fica registrado como do agente, e o log da execução mostra em nome de quem ela rodou.
• Repositórios do projeto. Quando o projeto da tarefa define repositórios, jiraya repo checkout só aceita esses. Isso orienta o agente, mas não impede um git clone direto com as credenciais da máquina.
• Segredos do workspace. Valores cadastrados como segredo chegam ao agente como variável de ambiente. Se aparecerem no registro da execução ou nas memórias do agente, são trocados por [REDACTED SECRET:NOME] antes de serem salvos, por correspondência exata do valor.
• Daemon local. O daemon escuta só em 127.0.0.1. As operações sobre execuções e checkout exigem um token: jiraya repo checkout usa o token da execução, e jiraya daemon watch e a inclusão de um workspace no daemon usam um token local do daemon.

O que não é um limiteCopiar link da seção

• Workspaces no mesmo daemon. Execuções de workspaces diferentes usam diretórios diferentes, mas rodam com o mesmo usuário. Um agente com acesso ao shell consegue ler o diretório de outro workspace.
• Segredos para o próprio agente. O agente que recebe o segredo consegue lê-lo do próprio ambiente.
• Segredos fora do registro da execução. A ocultação vale só para o registro da execução e para as memórias do agente. Comentários, tarefas, base de conhecimento e chat guardam o valor como o agente escreveu.
• Ocultação no registro da execução. A remoção de segredos não reconhece o valor transformado, por exemplo codificado em base64, e ignora valores com menos de 6 caracteres.
• Runtime público. Num runtime público, qualquer membro do workspace pode criar agentes que rodam na sua máquina, com o seu usuário e as credenciais das suas ferramentas de IA.
• Estado e parada do daemon. Na API local, a consulta de estado (/health) e o pedido de parada (/shutdown) não exigem token. Qualquer processo da máquina consegue ver o estado do daemon e pará-lo.

Configurações recomendadasCopiar link da seção

Conferir o que uma execução fezCopiar link da seção

• A transcrição de cada execução, com as chamadas de ferramenta, fica no Log de execução da tarefa e em jiraya issue run-messages.
• Na máquina, jiraya daemon watch mostra as chamadas de ferramenta ao vivo, e jiraya daemon logs guarda o histórico do daemon.
• O diretório da execução fica em ~/jiraya_workspaces até a limpeza; jiraya daemon disk-usage lista cada um.