Sandbox de agentes de IA e permissões Android: 3 camadas de confiança
Entenda a diferença entre sandbox de agente, permissões Android e aprovação de ações ao transformar uma análise em rascunho revisado no telefone.
- Sandbox de agente, permissões Android e aprovação de ação protegem perguntas diferentes: onde o agente roda, que recurso do telefone ele pode acessar e qual resultado o usuário aceita.
- O Android já isola apps por padrão; permissões de instalação, permissões em tempo de uso e permissões especiais não autorizam automaticamente destinatário, conteúdo ou envio.
- Um sandbox como o gVisor ilustra contenção do ambiente de execução, mas arquivos mapeados e rede permitida ainda precisam de política própria; isolamento não decide quais dados devem ser compartilhados.
- Na FoneClaw, ações Android suportadas usam o estado visível atual, revisão do usuário e políticas globais e por ferramenta; inserir texto em um campo não envia a mensagem.
Três proteções respondem perguntas diferentes
Ao avaliar sandbox de agentes de IA e permissões Android, a pergunta útil não é “isso é seguro?” em bloco único. Existem três camadas. A primeira é o ambiente de execução do agente: onde código, arquivos temporários e chamadas de rede podem acontecer. A segunda é o Android: quais dados e ações o sistema permite que um app acesse. A terceira é a aprovação da tarefa: se o usuário aceita aquele destinatário, aquele texto e aquele resultado.
O Android já tem isolamento de apps. A documentação do Android sobre sandbox de aplicativos descreve separação por IDs de usuário e processos, com aplicação no nível do kernel. Isso reduz acesso direto entre apps e dados privados, mas não elimina a necessidade de permissões nem decide se uma ação específica faz sentido.
| Camada | O que controla | O que não aprova | Checagem do usuário |
|---|---|---|---|
| Sandbox do agente | Ambiente de execução, arquivos expostos, rede e isolamento do host | Permissão no telefone ou envio de mensagem | Quais arquivos, credenciais e conexões ficam acessíveis? |
| Permissões Android | Acesso a dados ou ações restritas no aparelho | Destinatário correto, texto correto ou intenção final | A permissão é necessária para esta tarefa? |
| Aprovação de ação | Política e revisão antes de um resultado sensível | Isolamento técnico do ambiente de execução | O resultado visível é o que você quer concluir? |
Na FoneClaw, essa separação orienta o produto: executamos ações Android suportadas com base no estado visível atual, nas permissões aplicáveis e nas políticas globais e por ferramenta, sem tratar uma camada como substituta da outra. Para checagens por habilidade e acesso, veja Segurança de habilidades de agentes de IA no celular.
Um sandbox ainda precisa de limites de arquivo e rede
Um sandbox de ambiente de execução é valioso porque cria uma fronteira entre o trabalho do agente e o host. A documentação de segurança do gVisor, por exemplo, descreve uma camada que fica entre aplicações em sandbox e o kernel do host. Esse é um exemplo útil de contenção, não uma descrição da infraestrutura da FoneClaw.
O ponto prático é que isolamento não significa ausência de acesso. Uma carga de trabalho em sandbox ainda pode usar arquivos mapeados, diretórios montados e rede permitida pela configuração. Se a política libera saída para a internet, credenciais ou documentos, o sandbox não decide sozinho se aquilo deveria ser compartilhado. Ele limita a superfície técnica; a política de dados e rede continua separada.
Por isso, ao avaliar um agente remoto, pergunte quais arquivos entram no ambiente, quais destinos de rede são permitidos, como credenciais são expostas e o que acontece após uma falha. Para a escolha entre processamento local, modelo online e confiança de dados, o guia Confiança em agentes de IA: controle local no Android ou IA em nuvem aprofunda essa decisão sem misturar ambiente de execução com permissões do telefone.
Acesso Android e aprovação de ação são separados
No Android, permissões protegem dados restritos e ações restritas. A visão geral oficial de permissões Android diferencia permissões concedidas na instalação, permissões solicitadas durante o uso e permissões especiais. Também recomenda pedir apenas o acesso necessário no momento adequado.
Isso ainda não aprova a tarefa final. Uma permissão pode permitir ler um estado, abrir um app ou acessar um recurso; ela não confirma que a mensagem deve ir para Ana, que o texto está correto ou que o usuário quer enviar agora. A aprovação de ação é outra camada: destinatário, conteúdo, campo atual, consequência e resultado visível.
Na FoneClaw, a leitura do estado visível precisa ser atualizada quando a tela muda. Um campo que estava disponível antes pode deixar de existir, e um botão pode mudar de contexto. Inserir texto em um campo editável identificado serve para preparar ou substituir texto; isso não envia, não publica e não pressiona Enter. Para a visão geral das ações suportadas no telefone, consulte Controlar telefone Android com agente de IA: da intenção à ação.
Transforme uma análise em rascunho revisado no telefone
Veja um fluxo ilustrativo e verificável. Primeiro, o usuário faz uma análise em um ambiente remoto ou em outro app e decide levar apenas um resumo não sensível para o telefone. Em vez de entregar documentos inteiros, ele fornece uma frase operacional: “o cliente aprovou a versão simples, quer receber o prazo atualizado, pediu confirmação por mensagem e eu já verifiquei que posso prometer retorno ainda hoje”.
Depois, a FoneClaw pode ajudar na parte Android suportada. O usuário escolhe o app e o destinatário, a FoneClaw lê o estado visível atual, identifica um campo editável suportado e prepara um rascunho como: “Oi, Ana. Confirmo a versão simples. Vou atualizar o prazo e retorno com a previsão ainda hoje.” O usuário confere conversa, nome, texto e intenção antes de qualquer envio.
Esse fluxo tem três limites importantes. Primeiro, não existe passagem automática de sandbox remoto para ação Android: o usuário decide o que levar para o telefone. Segundo, se um modelo online configurado for usado, o contexto fornecido pode ser processado pelo provedor escolhido; execução no telefone não prova que todo processamento ficou local. Terceiro, a entrada de texto é apenas entrada de texto. O envio, quando aplicável e suportado por uma rota própria, continua sendo uma decisão separada e precisa ser verificado no app real.
O valor da FoneClaw aqui é operacional: transformar uma intenção revisada em um rascunho no lugar certo do Android, com o conteúdo visível antes de uma ação sensível. Esse papel é diferente de fornecer um sandbox de ambiente de execução para análise remota.
Recupere sem repetir uma ação incerta
Falhas precisam de recuperação específica. Se uma permissão foi negada, o caminho correto é parar, explicar o acesso necessário e permitir que o usuário decida. Se a tela mudou, releia o estado atual antes de agir. Se o resultado de uma ação externa ficou incerto, inspecione o app real antes de repetir.
| Situação | Risco | Recuperação segura |
|---|---|---|
| Permissão negada | Tentar contornar o limite do Android | Parar e pedir acesso apenas se ele for necessário para a tarefa |
| Tela mudou | Agir em campo ou controle errado | Ler novamente a tela visível e confirmar o alvo atual |
| Envio incerto | Enviar duas vezes ou para a conversa errada | Abrir a conversa e verificar o estado antes de tentar de novo |
| Ponto de restauração do sandbox | Confundir estado interno com efeito externo | Restaurar o ambiente de execução quando aplicável, mas conferir mensagens, apps e serviços separadamente |
Um checkpoint, ou ponto de restauração, de sandbox pode restaurar um ambiente de execução. Ele não desfaz automaticamente uma mensagem já enviada, uma alteração feita em app externo ou um dado entregue a um serviço. Para investigação detalhada de falhas no telefone, veja Como depurar e recuperar falhas de agentes de IA no celular Android.
Peça evidência em cada camada
Antes de confiar em um agente que mistura sandbox e ações no telefone, peça evidência por camada. No ambiente de execução: quais arquivos, rede, credenciais e estado ficam acessíveis? No Android: quais permissões são necessárias e quando aparecem? Na ação: qual destinatário, campo, texto e resultado serão verificados?
Na FoneClaw, mantemos essas camadas separadas: ações Android suportadas usam o estado visível atual, políticas de aprovação globais e por ferramenta, e revisão quando a consequência exige cuidado. Os recursos disponíveis ficam reunidos em recursos da FoneClaw. A conclusão prática é simples: sandbox ajuda a conter onde o agente trabalha; permissões Android limitam o que o telefone permite; aprovação de ação decide o que realmente deve acontecer.