Quem define a intenção de um agente de IA deve separar tarefa e permissões

Separar tarefa de permissões

O argumento central do artigo, publicado pela WorkOS, é que quem pede trabalho a um agente de IA deve definir o propósito da tarefa, mas a organização deve decidir quais ações são permitidas durante a execução. O agente pode escolher como pesquisar, o que ler e qual ferramenta chamar, mas uma descrição de tarefa mais ampla não deveria dar a ele autoridade para ignorar políticas da empresa.

O demo do Airlock

O texto ilustra a proposta com o Airlock, produto de Intent-Based Access Control da WorkOS. Na demonstração de Aaron Tainter no Agent Night, em 12 de agosto, um agente solicitou um token associado à sua intenção e o usou ao trabalhar entre Linear e Gmail. O Airlock verificava cada chamada proposta contra a intenção declarada e as políticas configuradas: a tarefa explicava o objetivo, mas as políticas determinavam se uma ação específica poderia prosseguir.

Como escrever a tarefa

Um exemplo de cobrança na página do produto começa com o pedido de encontrar cobranças duplicadas do mês anterior e reembolsá-las - o que dá ao agente um propósito, um período e uma mudança pretendida, deixando liberdade para definir buscas e comparações. Já um pedido vago como "ajudar com cobrança" pode significar relatório, reembolso, mudança de assinatura ou contato com clientes; a ambiguidade deve ser resolvida antes de o agente começar a fazer alterações. Um pedido apenas de listar cobranças deixa a operação de escrita implícita, e o agente não deveria ter que inferir se encontrar uma duplicata também significa mover dinheiro.

Mesmo um pedido claro de reembolso não resolve todas as decisões: no exemplo do produto, buscar cobranças é permitido, reembolso exige aprovação e excluir o registro de um cliente é negado por estar fora da tarefa - decisões separadas dentro do mesmo fluxo.

Identidade e política fora do texto da tarefa

Uma frase como "estou agindo em nome do administrador de cobrança" não comprova identidade. Quem solicitou o trabalho deve ser estabelecido pelos controles de identidade da aplicação, e então aplicadas as permissões de recursos e as regras da empresa. A descrição da tarefa ajuda a contextualizar uma ação, mas não pode estabelecer autoridade por si só.

A política também precisa expressar restrições que permanecem válidas entre atribuições: uma regra que proíbe informações financeiras em e-mails enviados deve continuar valendo mesmo quando o agente for solicitado a escrever um resumo detalhado.

Testar a clareza com ações reais

No demo, uma atualização rotineira de planejamento para um gestor passou. Em outro pedido, o agente encontrou uma issue no Linear sobre uso de tokens e compôs um e-mail resumindo-a; o envio foi negado porque o corpo continha informações de gasto com tokens, tratadas pela política como dados financeiros. Ambos os fluxos envolviam ler o Linear e enviar e-mail - saber quais ferramentas estavam conectadas não explicaria os resultados diferentes; o conteúdo do e-mail proposto, o trabalho pedido e a política aplicável foram decisivos.

O artigo sugere aplicar esse raciocínio a fluxos existentes: registrar quem pediu, quais recursos estão envolvidos e quais mudanças são esperadas, e então pedir a outra pessoa para classificar ações propostas como dentro ou fora da tarefa. Se houver divergência - por exemplo, se um considera que emitir reembolso está incluído e outro que a tarefa termina no relatório -, a tarefa deve ser esclarecida antes de servir como contexto de autorização.

Mudança de tarefa e reformulação de pedidos negados

Um funcionário pode legitimamente expandir o trabalho, como pedir para examinar outro mês de cobranças; a mudança deve ser registrada e as novas ações avaliadas contra as mesmas permissões e políticas. Já quando um agente reformula com palavras mais suaves um pedido negado, mantendo destinatário, conteúdo e efeito pretendido, o novo texto não deveria bastar para liberar o envio. O artigo recomenda testar esse caso: submeter uma ação proibida, reescrever a descrição e verificar tanto a nova decisão quanto se algo aconteceu no provedor.

Como verificações semânticas podem variar conforme a redação, isso é comportamento a ser testado, não garantia a assumir. A intenção clara dá às verificações contexto útil, enquanto permissões e políticas aplicáveis fornecem as restrições que o fluxo ainda precisa satisfazer.