Os telefones estão começando a ser fornecidos com um assistente que faz mais do que responder perguntas. Ele lê seu calendário, redige uma mensagem e pode até iniciar um pagamento em seu nome. Para desenvolvedores de aplicativos, isso altera o contrato. Seu aplicativo não é mais usado apenas por uma pessoa que toca na tela. Às vezes, um agente de software solicita seus recursos para eles.
Isso levanta questões práticas. Quais ações um agente pode desencadear? Quais precisam de um humano para aprovar primeiro? O que acontece quando o agente recebe uma instrução ambígua? Este artigo aborda seis verificações que você pode fazer antes que um agente toque em seu aplicativo, com um exemplo de código curto que você pode executar.
1. Decida o que é executado no dispositivo e o que sai dele
Comece com o fluxo de dados. Um agente que raciocina no dispositivo mantém os dados privados locais e evita atrasos na rede. Um agente que liga para um modelo de nuvem envia alguns desses dados pelo telefone. Ambos podem ser válidos, mas seu aplicativo deve saber com qual deles está lidando.
Guia do SitePoint para IA no dispositivo para a web explica bem as vantagens e desvantagens: a inferência local remove viagens de ida e volta e mantém os dados no dispositivo, mas o tamanho do modelo, a pressão da memória e o hardware irregular limitam em que você pode confiar. Anote quais dados do seu aplicativo um agente pode ler e se esses dados podem sair do dispositivo.
2. Declare permissões por ação, não por aplicativo
Conceder “acesso ao aplicativo” a um agente é muito amplo. Divida seus recursos em ações nomeadas e dê a cada uma permissão explícita, como calendar.read ou payment.create.
Esta é a mesma ideia usada ao avaliar extensões de terceiros. Artigo do SitePoint sobre protegendo extensões de agente de IA mostra um manifesto que declara o que uma extensão pode fazer e bloqueia tudo o que não está declarado. Você pode usar esse padrão para agentes que ligam para seu aplicativo: qualquer coisa que não esteja na lista é negada por padrão.
3. Limitar a autoridade do agente e exigir aprovação para ações de alto impacto
O Projeto de Segurança OWASP Gen AI descreve este risco como agência excessiva: um sistema com muitas funcionalidades, permissões ou autonomia pode tomar ações prejudiciais ao receber resultados inesperados, ambíguos ou manipulados. Suas mitigações incluem limitar o que as extensões podem fazer, exigir aprovação humana para ações de alto impacto e impor autorização em sistemas downstream em vez de confiar no modelo.
Aqui está um pequeno portão que aplica essas ideias. As ações somente leitura são executadas diretamente. Enviar uma mensagem ou criar um pagamento aguarda o usuário. Qualquer coisa desconhecida é rejeitada.
javascript
const POLICY = {
"calendar.read": { risk: "low", confirm: false },
"contacts.read": { risk: "low", confirm: false },
"message.send": { risk: "high", confirm: true },
"payment.create": { risk: "high", confirm: true },
};
const audit = ();
async function runAction(name, args, { confirmWithUser, handlers }) {
const rule = POLICY(name);
if (!rule) throw new Error(`Action not allowed: ${name}`);
if (rule.confirm) {
const approved = await confirmWithUser(name, args);
if (!approved) {
audit.push({ name, args, result: "denied" });
return { ok: false, reason: "user_denied" };
}
}
const result = await handlers(name)(args);
audit.push({ name, args, result: "ok" });
return { ok: true, result };
}
O ponto principal é que a política reside no seu código, não nas instruções do modelo. Um prompt manipulado pode alterar o que o agente solicita, mas não pode alterar o que seu aplicativo permite.
4. Teste em classes de dispositivos reais, incluindo novos aparelhos de agente
Os recursos do agente estão chegando em diferentes tipos de hardware, e alguns aparelhos agora são comercializados diretamente em torno dessa ideia. Para ver um telefone de agente de IA conforme apresentado por um fabricante de hardware, VERTU lista um entre seus dispositivos de luxo. A página inicial da VERTU vinculada é uma página comercial de varejo; as permissões documentadas do sistema operacional devem determinar o que um agente pode realmente acessar.
Para seus testes, crie uma matriz curta: um dispositivo com pouca memória, um carro-chefe recente e pelo menos um dispositivo com um agente integrado. Verifique se seus prompts de permissão aparecem, se as ações negadas falham corretamente e se seu aplicativo não pressupõe que é sempre uma pessoa quem o chama.
5. Registre todas as ações do agente
Quando um agente atua em nome de um usuário, você precisa de um registro do que ele fez. O audit array no exemplo acima é a versão mais simples disso. Na produção, armazene o nome da ação, os argumentos, o resultado e um carimbo de data/hora, e mantenha-os em algum lugar onde o usuário possa revisar. Se algo der errado, esse log é a forma de saber se o usuário, o agente ou um bug causou isso.
6. Planeje o substituto quando o agente estiver indisponível
Os agentes falham, são desativados ou simplesmente não são instalados no telefone do usuário. Cada fluxo que um agente pode acionar ainda deve funcionar quando uma pessoa o faz manualmente. Teste com o acesso do agente desativado e certifique-se de que as mensagens de erro digam o que fazer em seguida, em vez de falharem silenciosamente.
Perguntas frequentes
Meu aplicativo deve confiar nas instruções provenientes de um agente? Não. Trate as chamadas do agente como qualquer outra entrada externa. Valide argumentos, verifique permissões por ação e exija aprovação para qualquer coisa com consequências reais.
Quais ações devem sempre precisar da aprovação do usuário? Qualquer coisa que gaste dinheiro, envie uma mensagem, exclua dados ou compartilhe informações pessoais. Ações somente leitura com baixo risco geralmente podem ser executadas sem aviso prévio.
A IA no dispositivo elimina a necessidade dessas verificações? Não. Manter os dados no dispositivo ajuda na privacidade, mas um agente com muita autoridade ainda pode realizar ações prejudiciais localmente.
Resumo
À medida que os agentes começam a ligar para recursos do aplicativo em nome dos usuários, a abordagem mais segura é tratá-los como chamadores não confiáveis. Decida quais dados permanecem no dispositivo, declare permissões por ação, exija aprovação para ações de alto impacto, teste em classes de dispositivos, registre o que o agente faz e mantenha um substituto manual. A porta de política acima é pequena, mas move a decisão do modelo para o seu código, que é onde ela pertence.
