Pinky dá ao Claude controle de um celular real via MCP: pagamentos só com o seu "ok"

Se você já escreveu um aplicativo móvel, conhece a principal dor: é preciso testá-lo à mão. Tocar, deslizar, ver o bug, voltar ao editor. Agentes de programação como Claude Code e Cursor há tempos dominam o terminal e o navegador, mas não alcançavam o celular. O projeto Pinky tenta corrigir isso: ele entrega ao agente um smartphone de verdade por meio do protocolo MCP.

O que exatamente é declarado

Segundo um post no X de @xiaoanlab, o esquema é o seguinte. O Pinky atua como servidor MCP ao qual se conectam o Claude Code ou o Cursor. Por meio dele, o agente recebe a imagem da tela do dispositivo real e pode tocar nela. Declara-se suporte tanto a iPhone quanto a Android. Não se trata de um emulador, mas de um telefone físico, e essa é uma diferença importante: no hardware real aparecem bugs que não existem no simulador, de peculiaridades da câmera e das notificações push ao comportamento dos diálogos do sistema.

Um exemplo simples. Você pede ao agente: "Abra o aplicativo, faça o cadastro e verifique se, após o login, o onboarding é exibido". Antes, um cenário assim precisava ser descrito em testes de interface com Appium ou XCUITest e depois corrigido a cada mudança de layout. Aqui, o agente olha para a tela como uma pessoa e toma decisões ao longo do caminho.

A pergunta principal: quem mantém a mão no botão

Dar a um modelo de linguagem acesso a um celular significa dar acesso a aplicativos bancários, mensageiros e e-mail. Por isso, o mais interessante do anúncio não é o toque na tela em si, mas o modelo de segurança. Segundo o autor, pagamentos, transferências, além de exclusão e instalação de aplicativos, exigem um "permitir" explícito de uma pessoa. Bancos, carteiras e gerenciadores de senhas, pelo visto, ficam bloqueados por padrão, mas no post essa frase é interrompida, e não é possível verificar a formulação exata.

Destaca-se separadamente que as regras são aplicadas de forma rígida no gateway do Pinky. Isso é fundamental. Se a proibição vive apenas no prompt do sistema, ela pode ser contornada com uma injeção: um texto malicioso na tela convence o modelo de que pagar é permitido. Se a verificação fica no nível de um proxy entre o agente e o dispositivo, o modelo fisicamente não consegue enviar um comando perigoso sem confirmação, por mais que o tentem persuadir. É o mesmo princípio pelo qual, em produção, não se dá ao agente acesso direto ao banco de dados, mas se coloca entre eles uma camada de permissões.

Limitações e o que fazer a respeito

Primeiro, o que não sabemos. A fonte é uma só: um post curto com 88 visualizações, com o texto cortado no meio da frase. Não há documentação, preço, dados de latência nem informações sobre como o acesso ao iPhone é implementado. No iOS isso não é trivial por causa do caráter fechado do sistema, e o autor não dá detalhes. Não se sabe se tudo funciona localmente ou se a tela vai para servidores de terceiros. Para testar aplicativos com dados de usuários, isso é crítico.

Há também limitações gerais. Um agente que controla a interface por capturas de tela é mais lento e menos determinístico que testes com scripts. Confirmar manualmente cada ação perigosa evita catástrofes, mas mata a autonomia. E qualquer política "rígida" é tão boa quanto a completude com que lista as ações perigosas.

A conclusão prática é curta. Desenvolvedores de aplicativos móveis devem acompanhar essa direção e, se o projeto publicar o código, testá-lo em um celular de testes separado, sem contas pessoais, e não no principal. Gerentes de produto devem ter em mente que a interface móvel logo estará acessível aos agentes como a web, e o seu aplicativo precisará ser compreensível não apenas para pessoas. Fundadores devem olhar para o próprio padrão: um gateway com políticas entre o modelo e o dispositivo vira uma camada de produto independente, e em torno dele pode muito bem crescer um negócio.