O problema do âmbito: porque um agente de IA não pode definir os seus próprios limites de autorização

A ideia é tentadora. Ao implantar um agente de IA, queremos que ele seja suficientemente poderoso. Quanto mais ferramentas puder chamar e mais sistemas puder aceder, mais útil parece. O que ele está autorizado a fazer poderia, aparentemente, ser definido no prompt ou deixado ao seu próprio julgamento. Afinal, o agente sabe do que precisa. Porque não deixá-lo decidir?

Esse raciocínio é a raiz do problema do âmbito. Um agente que participa na definição da sua própria autorização não merece confiança para autorização nenhuma.

No contexto de agentes de IA, âmbito é o conjunto de ações que o agente pode executar: que APIs pode chamar, que armazéns de dados pode ler ou escrever, que sistemas físicos pode operar e que credenciais pode apresentar. Numa implantação bem desenhada, o âmbito é fixado na configuração, codificado num token assinado apresentado pelo agente em cada pedido e verificado pelo sistema chamado. O agente não decide o seu âmbito; recebe-o, não o pode expandir unilateralmente, e os limites são aplicados por sistemas externos.

O padrão de falha mais comum é a expansão incremental de âmbito. O agente começa com um conjunto claro de capacidades. Com o tempo, quando encontra tarefas que não cabem no âmbito inicial, operadores acrescentam permissões uma a uma. Cada decisão isolada parece razoável. O âmbito real cresce. Ninguém revê a combinação acumulada, e o agente acaba com acesso a um conjunto de sistemas que nenhum decisor aprovou explicitamente como conjunto.

Outra falha é a inferência de âmbito. Algumas arquiteturas permitem que o agente consulte APIs de descoberta de capacidades e pergunte o que pode fazer. Em ambientes adversariais, contexto comprometido a montante pode convencê-lo de que possui permissões nunca concedidas. Sem uma referência assinada, o agente não consegue verificar a afirmação.

A terceira falha é a lavagem de âmbito por composição de ferramentas. Um agente com permissão para ler documentos e enviar mensagens pode combinar essas permissões e exfiltrar conteúdo para uma parte externa, embora nenhuma permissão isolada tenha autorizado esse resultado.

Fechar estas lacunas exige tratar o âmbito como compromisso criptográfico. Cada dimensão, permissões de leitura e escrita, endpoints chamáveis e identificadores de credenciais, deve estar num token assinado por uma autoridade de configuração e vinculado à identidade do agente. Extensão de âmbito requer novo evento de configuração, novo token assinado e uma decisão humana rastreável. Raízes de confiança em hardware ajudam a impedir adulteração do âmbito no runtime; assinaturas pós-quânticas reduzem o risco de falsificação de tokens ao longo de ciclos de vida longos.