IntentCap propõe limitar privilégios de agentes de IA à intenção real da tarefa em execução, não à sessão inteira
O IntentCap é um framework que argumenta que a permissão de um agente de LLM deveria ser calculada dinamicamente a partir da intenção específica da tarefa em curso, e não fixada para toda a duração de uma sandbox ou sessão. O sistema compõe capacidades a partir de quatro fontes distintas — intenção do usuário, instruções de workflow, esquemas de ferramentas e ambiente de execução —, cada uma contribuindo apenas com campos que só ela pode preencher, e aplicando uma regra de estreitamento monotônico que nunca amplia a autoridade original concedida pelo usuário.
Agentes de LLM hoje tomam ações reais — executam código, modificam arquivos, chamam serviços externos, delegam tarefas a outros agentes — a partir de contexto que chega de fontes muito diferentes em nível de confiança: o pedido explícito do usuário, o resultado de uma chamada de ferramenta, o texto extraído de um documento, a saída de um comando de shell, instruções de uma skill ou servidor MCP, e a própria memória do agente. O problema de segurança que o IntentCap nomeia é que, em arquiteturas atuais, todo esse contexto heterogêneo entra no mesmo canal de planejamento do modelo com peso equivalente, então tanto uma injeção adversarial quanto um simples aumento acidental de escopo de tarefa podem, na prática, redefinir o que o agente decide fazer — mesmo que o pedido original do usuário e o texto extraído de um documento devessem, por natureza, ter níveis de confiança e autoridade completamente diferentes.
A proposta central é que o privilégio de um agente não deveria ser um valor fixo atrelado ao tempo de vida de uma sandbox ou sessão, mas sim recalculado dinamicamente a partir da intenção real da tarefa que está sendo executada naquele momento. O IntentCap implementa isso compondo a capacidade do agente a partir de quatro fontes — intenção do usuário, instruções de fluxo de trabalho, esquemas de ferramentas disponíveis e o ambiente de execução em tempo real —, com uma regra de "field-level ownership": cada fonte contribui apenas com os campos de permissão que só ela tem autoridade para definir, nenhuma fonte pode preencher o campo de outra, e o resultado da composição só pode estreitar a autoridade que o usuário originalmente concedeu, nunca ampliá-la.
Operacionalmente, o sistema usa um LLM para gerar "leases" (concessões de permissão de curta duração) a partir dessas quatro fontes, mas — de forma importante — essas leases são validadas por um checker determinístico antes que qualquer efeito colateral no mundo real seja de fato executado, e a imposição final acontece em nível de ferramenta e de sistema operacional via políticas de controle de fluxo de informação, não apenas dentro do raciocínio do próprio modelo. Isso significa que mesmo que o LLM seja manipulado a gerar uma lease excessivamente permissiva, a camada determinística de checagem atua como uma segunda barreira independente do julgamento do modelo.
É um artigo curto, de workshop (AgenticOS 2026, três páginas), e portanto uma proposta de arquitetura ainda inicial em vez de um sistema validado em produção, mas o princípio — escopo de capacidade amarrado à intenção da tarefa corrente, com composição multi-fonte e estreitamento monotônico — é diretamente relevante para quem projeta política de permissão em frameworks de agente hoje, especialmente à luz de ataques como prompt injection via documento ou ferramenta, onde o problema raiz é justamente a ausência dessa separação de autoridade por fonte de contexto.