Permissões para agentes de IA: como limitar ferramentas, dados e ações ao mínimo necessário

A autoridade do agente não é a autoridade do sistema

Um agente pode interpretar um pedido, escolher ferramentas e encadear operações. Isso não significa que deva decidir a que recursos pode aceder ou que recursos pode modificar. A autorização efetiva cabe aos sistemas que contêm os dados ou executam as ações: o repositório, o serviço de correio eletrónico, a API ou a plataforma empresarial. O modelo pode propor uma operação; o sistema de destino deve verificar se a identidade que a solicita pode executá-la naquele recurso específico.

Esta distinção é importante porque o agente pode cometer erros, receber instruções enganosas ou escolher uma ferramenta inadequada. As instruções do prompt e as regras que filtram as ferramentas apresentadas ajudam a orientar o comportamento, mas não devem ser o único controlo. Se existir uma via alternativa para executar a mesma operação com uma credencial abrangente, o filtro de ferramentas não impede o acesso. Convém combinar limites na interface do agente com controlos de identidade e autorização aplicados pelas ferramentas e pelos serviços ligados.

O objetivo prático não é tornar o agente incapaz de cometer qualquer erro. É reduzir o que pode acontecer se interpretar mal a tarefa: limitar os recursos acessíveis, distinguir leitura de alteração, minimizar a duração do acesso e evitar que uma única credencial transforme um equívoco numa ação de grande alcance. As recomendações deste guia são critérios de conceção; a aplicação concreta depende das capacidades e do modelo de permissões de cada plataforma.

Inventariar tarefas, recursos e efeitos antes de conceder acesso

Comece por descrever as tarefas que o agente deve executar, em vez de enumerar todos os conectores que seria possível ativar. Para cada tarefa, identifique quem a solicita, de que dados precisa, que ferramenta os fornece e qual é o resultado esperado. Em seguida, registe o efeito potencial de cada operação. Consultar um documento, editá-lo, enviar uma mensagem e apagar um registo são capacidades diferentes, mesmo quando estão disponíveis através do mesmo serviço.

Separe os dados próprios do utilizador dos dados partilhados por uma equipa ou organização. A separação também deve considerar o recurso específico: um agente que precisa de ler uma pasta de projeto não precisa, por esse motivo, de acesso de leitura a todo o repositório. Identifique ainda se a tarefa é executada em nome de uma pessoa ou como uma aplicação autónoma. Nas plataformas que distinguem permissões delegadas de permissões de aplicação, essa diferença afeta a identidade representada e os limites aplicáveis.

Não classifique uma operação apenas pelo nome da ferramenta. Uma chamada de «atualização» pode alterar um campo inofensivo ou modificar um estado que desencadeia processos posteriores. Descreva o efeito observável e quem poderá ser afetado. Se o impacto não for claro, não presuma que a operação é de baixo risco: delimite o âmbito e teste o comportamento num ambiente controlado antes de a ativar em produção.

Conceber perfis de privilégio mínimo por tarefa e utilizador

Com o inventário preparado, defina um perfil para cada tarefa. Especifique que identidade a executa, que ferramentas pode invocar, sobre que recursos, com que ações e durante quanto tempo. Um perfil como «acesso ao correio eletrónico» é demasiado impreciso. Um perfil útil indica, por exemplo, que uma tarefa pode consultar as mensagens de uma pessoa para preparar um resumo, mas não pode enviar, apagar ou alterar mensagens.

Quando o utilizador deve manter os seus próprios limites, uma autorização delegada pode ser mais adequada do que uma credencial de aplicação com acesso independente e abrangente. A documentação do Microsoft Graph distingue permissões delegadas, limitadas pelo que o utilizador pode fazer, de permissões de aplicação, concedidas à aplicação. Esta distinção não elimina a necessidade de configurar permissões de privilégio mínimo nem garante, por si só, que cada operação esteja devidamente delimitada: é preciso verificar que permissões a integração solicita e o que o sistema faz com elas.

Em alguns ambientes, a troca de tokens permite obter credenciais destinadas a um recurso específico ou representar uma delegação. A norma de troca de tokens OAuth descreve este mecanismo, mas a sua disponibilidade e as restrições concretas dependem da implementação. Não apresente um token temporário como automaticamente seguro: verifique o público-alvo, o sujeito, as ações autorizadas, a duração e as condições de renovação. Se o ambiente não suportar credenciais com âmbito limitado, documente essa limitação e compense-a com controlos no destino, separação de funções e supervisão.

Autorizar cada operação no sistema de destino

Uma política que limite as ferramentas disponíveis pode reduzir erros de seleção: por exemplo, fazendo com que o agente veja apenas um conjunto de ferramentas aprovado. No entanto, isso não demonstra que a chamada específica esteja autorizada. A documentação do Amazon Bedrock AgentCore descreve listas de ferramentas permitidas e alerta que esse filtro não substitui as permissões IAM aplicáveis a outras vias de execução. Em termos de conceção, o filtro do agente e a política do recurso são camadas distintas e devem ser revistas separadamente.

O sistema de destino deve verificar, no mínimo, a identidade efetiva, a ação solicitada e o recurso afetado. Se a autorização depender do utilizador, não basta verificá-la uma vez, quando a sessão é criada, e depois confiar sem mais no contexto. Defina como a identidade é validada em cada operação e o que acontece se as permissões mudarem enquanto a tarefa ainda estiver ativa. A forma de implementar esta verificação depende da plataforma, pelo que não se deve presumir que todos os conectores reavaliam as permissões da mesma maneira.

As políticas baseadas em recursos e as baseadas em identidades podem ser combinadas com regras contextuais. A AWS documenta políticas de recursos do AgentCore que permitem especificar principais, ações e condições, e recomenda conceder apenas as permissões necessárias. Utilize documentação deste tipo para compreender o modelo de avaliação do serviço escolhido; não copie uma política de exemplo sem verificar o recurso, o principal e a ação abrangidos na sua implementação.

Separar a preparação, a aprovação e a execução de ações sensíveis

A aprovação humana é útil quando uma operação pode enviar informações a terceiros, alterar dados partilhados, apagar conteúdo ou modificar permissões. Não deve consistir num botão genérico de «continuar». Antes de decidir, a pessoa precisa de compreender que operação será realizada, sobre que recurso, com que dados e qual será o efeito esperado. Se a pré-visualização omitir o destinatário, o conteúdo a enviar ou o âmbito da alteração, a aprovação não permite avaliar devidamente o risco.

A aprovação também deve estar associada à operação que foi analisada. Se, depois da aprovação, mudarem o destino, os argumentos, o recurso ou a ação, solicite uma nova decisão. Evite transformar uma aprovação pontual numa autorização geral que o agente possa reutilizar noutras tarefas. A interface deve deixar claro quem aprova e em nome de quem a operação será executada.

A documentação do SDK de agentes da OpenAI descreve um fluxo em que uma chamada sensível a uma ferramenta pode ser colocada em pausa para revisão, permitindo inspecionar a ferramenta e os respetivos argumentos antes de retomar ou rejeitar a execução. É um exemplo de mecanismo de revisão, não uma garantia de que qualquer operação seja segura: a equipa ainda tem de decidir que ferramentas exigem uma pausa e se os dados apresentados à pessoa que aprova são suficientes para avaliar o efeito.

Limitar a duração e revogar o acesso de forma verificável

Conceder acesso durante uma sessão ou tarefa específica reduz o período em que uma credencial pode ser reutilizada, desde que o ambiente suporte essa modalidade. Defina quando começa e termina a autorização, se pode ser renovada e quem o pode fazer. Não confunda uma sessão curta com um âmbito limitado: uma credencial de curta duração que permite apagar todos os dados continua a poder ter um impacto abrangente enquanto estiver ativa.

Conceba a revogação como uma operação que tem de poder ser testada. Retire a permissão ou invalide a credencial e, em seguida, execute novos pedidos com a mesma identidade. Verifique também as sessões já abertas, os tokens em cache, as tarefas em segundo plano e as novas tentativas. A resposta depende do fornecedor: algumas alterações podem produzir efeito imediato, enquanto outras podem estar sujeitas a propagação ou à duração de credenciais emitidas anteriormente. Se a documentação não esclarecer o comportamento, registe essa incerteza e teste o caso no ambiente correspondente.

Para reduzir o risco de acesso persistente, atribua credenciais distintas a agentes, ambientes e tarefas quando for viável, e evite copiar segredos do utilizador para prompts, históricos ou registos. Se utilizar delegação ou troca de tokens, conserve apenas os dados necessários para operar e auditar. A revogação não substitui a conceção inicial das permissões: é uma defesa adicional para responder a mudanças de pessoal, incidentes ou tarefas concluídas.

Registar decisões e resultados sem transformar os registos noutro risco

Um registo útil permite reconstruir quem pediu uma tarefa, que identidade foi utilizada, que ferramenta foi chamada, que recurso se tentou aceder, que decisão o sistema tomou e qual foi o resultado. Guarde identificadores de pedido e marcas temporais suficientes para correlacionar eventos entre o agente e o serviço de destino. Distinga uma chamada tentada, uma autorização concedida e uma operação concluída: não são o mesmo facto.

Não guarde tokens, chaves, palavras-passe ou outros segredos nos registos ou rastos. Também não armazene automaticamente todo o conteúdo consultado ou enviado. Defina que dados são necessários para investigar falhas, como são protegidos, quem lhes pode aceder e durante quanto tempo são conservados. Em alguns casos, o identificador do recurso e um resumo do tipo de operação serão suficientes; noutros, poderá ser necessário guardar uma pré-visualização com controlos de privacidade.

Utilize a telemetria para detetar padrões que mereçam ser revistos: negações repetidas, tentativas de aceder a recursos alheios à tarefa, chamadas de escrita inesperadas ou utilização de uma credencial depois da revogação. Um padrão observado não prova, por si só, que tenha ocorrido abuso; é um sinal para investigar com base no contexto do pedido e nas políticas em vigor.

Testar os limites, incluindo tentativas fora do âmbito autorizado

Antes da implementação, transforme cada permissão concedida num teste positivo e em vários testes negativos. O teste positivo demonstra que a tarefa legítima funciona dentro do âmbito previsto. Os testes negativos verificam que o mesmo agente não consegue mudar de utilizador, aceder a um recurso partilhado não autorizado, usar uma operação de escrita quando só tem acesso de leitura, apagar registos ou invocar uma ferramenta para uma finalidade não prevista. Repita os testes quando houver alterações em conectores, funções, políticas ou fluxos de aprovação.

Teste tanto a interface do agente como o sistema de destino. Se o agente não disponibilizar uma ferramenta proibida, verifique também se uma chamada direta ou uma via alternativa consegue executar a ação com as credenciais disponíveis. Confirme que uma aprovação não autoriza argumentos diferentes dos analisados e que uma permissão revogada bloqueia os pedidos posteriores. Para operações de elevado impacto, utilize dados e recursos de teste que permitam observar o efeito sem afetar pessoas ou serviços reais.

Um teste aprovado não demonstra que o sistema é seguro em todas as circunstâncias. Demonstra que determinados casos se comportaram como esperado numa configuração específica. Guarde a identidade de teste, a política aplicada, os passos e o resultado; assim, poderá repetir a verificação após uma atualização. Se uma plataforma ocultar parte da avaliação de permissões ou não disponibilizar registos suficientes, anote essa limitação em vez de presumir que o controlo funcionou.

Limites dos controlos e erros a evitar

As permissões reduzem o conjunto de ações possíveis, mas não garantem que o agente interprete corretamente uma tarefa nem que a resposta seja exata. Uma permissão de leitura pode revelar informações sensíveis se o conjunto de documentos autorizado for demasiado abrangente. Uma permissão de escrita limitada pode causar uma alteração errada dentro desse âmbito. Por isso, a conceção combina autorização, validação de entradas, revisão proporcional ao risco e testes de comportamento.

Evite conceder uma credencial administrativa para simplificar a integração, confiar que o prompt impedirá operações indesejadas ou presumir que uma lista de ferramentas permitidas equivale a uma política completa. Também não transforme o consentimento do utilizador para uma tarefa numa autorização persistente para outras. As instruções e aprovações orientam o processo; a permissão efetiva deve continuar limitada na identidade e no sistema ligado.

Este guia aborda a autoridade técnica e a forma de a limitar. É diferente de um guia sobre injeção indireta de instruções, que se centra em conteúdos não fiáveis que tentam orientar o agente, e de um guia de recuperação após falhas, que aborda a resposta a erros e efeitos parciais. Os temas estão relacionados: uma instrução hostil pode tentar provocar uma ação indesejada, enquanto as permissões e os controlos no destino determinam que ações podem realmente ser executadas.

Lista de verificação antes da implementação e após uma alteração

Reveja o modelo de permissões antes de ativar um agente e repita a revisão quando for adicionada uma ferramenta, um conector for alterado, o conjunto de dados for alargado ou uma política for modificada. A pessoa responsável deve conseguir explicar que tarefa justifica cada permissão e que efeito teria uma chamada errada. Se não for possível identificar uma utilização legítima de uma capacidade, desative-a até esclarecer a situação.

Como referência operacional, confirme que a configuração separa leitura, escrita, envio, eliminação e alterações de acesso; que delimita o utilizador e o recurso; e que não depende exclusivamente das instruções do modelo. Verifique o processo de aprovação para operações sensíveis, as informações apresentadas a quem aprova, o registo de decisões e resultados e o procedimento para revogar o acesso. Teste os casos negativos descritos acima com as identidades e os sistemas que serão utilizados em produção.

Esta lista não substitui a revisão de segurança do produto nem a documentação específica do fornecedor. É um método para tornar visíveis os pressupostos que muitas vezes ficam ocultos quando se ligam ferramentas. Quando uma capacidade do ambiente não permitir aplicar um limite necessário, registe a lacuna, avalie o risco e altere a conceção da tarefa ou do fluxo antes de conceder um acesso abrangente.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.