Privilégio mínimo para agentes de IA em um SaaS multilocatário

Um atalho de protótipo comum consiste em dar a um agente um token, expor todas as ferramentas e limitar o comportamento com um prompt. Isso facilita a demonstração. Em produção, cria‑se um problema: a intenção escrita nos prompts torna‑se a principal barreira entre um erro do modelo e a plena capacidade da conta.

O menor privilégio para um agente não termina com uma função somente‑leitura. No mínimo, devemos limitar cinco coisas: ferramentas, tipo de operação, recursos-alvo, dados e a duração/identidade do acesso.

1. Limitar o conjunto de ferramentas

Um agente que analisa o desempenho de publicidade não precisa de funções de gestão de utilizadores. Um agente que prepara um relatório de conformidade não precisa de acesso irrestrito ao shell. Um agente que organiza ficheiros num diretório não precisa de todo o sistema de ficheiros.

Quanto maior for o catálogo de ferramentas, maior será a superfície de risco para:

• selecionar a ferramenta errada;
• injeção de prompt que conduza a uma ação indesejada;
• combinações inesperadas de ferramentas;
• exposição acidental de dados;
• erros de configuração na camada do modelo.

A primeira pergunta, portanto, não deve ser “o que esta API pode fazer?” mas:

quais três ou cinco operações este agente necessita para este trabalho específico?

Todo o resto pode permanecer invisível.

2. Separar leitura, escrita, efeito operacional e destruição

“Tem acesso a campanhas” é demasiado amplo.

Para as nossas ferramentas, um modelo de operação é mais útil:

Escopo	Significado	Exemplo
read	recuperar estado e relatórios	obter gasto, estado ou lista de recursos
write	preparar ou modificar configuração	criar rascunho, renomear, mudar um parâmetro
operate	ativar uma consequência de negócio	habilitar uma campanha, publicar, iniciar sincronização
destructive	eliminar, desvincular ou revogar	apagar um recurso, remover acesso, efetuar mudança difícil de reverter

Um agente pode preparar uma configuração sem permissão para a ativar. Pode ler a faturação sem mudar as definições de pagamento. Pode redigir uma mensagem sem permissão para a enviar.

Essa fronteira costuma ser onde a autonomia útil reside.

3. O escopo da ferramenta não basta — limitar também o recurso

Uma permissão como:

campaign.write

continua ampla se um operador tem dez contas, mas o agente deve trabalhar apenas numa.

Quando for prático, a autorização deve considerar:

A decisão de autorização inclui o utilizador, agente, função, tipo de operação, inquilino/conta/projeto, recurso e contexto da tarefa.

quem
+ qual agente
+ qual função
+ qual tipo de operação
+ qual inquilino/conta/projeto
+ qual recurso
+ qual contexto da tarefa

O nosso MCP interno Brillnet Ads requer identificadores explícitos de conta/cliente dentro de um limite permitido. Uma consulta geral não deve simplesmente adivinhar em que conta operar.

Isto é particularmente importante em SaaS multi‑inquilino. Selecionar o inquilino errado pode ser mais grave do que um erro de raciocínio dentro do próprio modelo.

4. Limitar dados de entrada e saída

O menor privilégio também se aplica aos dados.

Um agente pode precisar de:

• gasto agregado, não da lista completa de dados de utilizadores;
• estado da tarefa, não de todos os anexos;
• confirmação de que uma credencial existe, não do seu valor;
• um identificador de pessoa, não do seu perfil completo;
• campos selecionados de documento, não de todo o repositório.

Se uma ferramenta pode devolver um objeto mínimo, devolva o objeto mínimo. Não exponha um payload completo do fornecedor ao modelo apenas porque a API o disponibiliza.

O mesmo princípio aplica‑se ao registo: um trilho de auditoria deve conter evidência suficiente, não uma duplicação de todos os dados de origem.

Leia: trilhos de auditoria de agentes de IA

5. Uma credencial não deve viver mais ou mais amplamente do que o necessário

Um token de administrador de longa duração colocado no ambiente de cada componente é fácil de configurar. Também é difícil de limitar com segurança.

Preferimos um padrão mais próximo de:

1. O agente não recebe o segredo.
2. O gateway verifica identidade, escopo e recurso.
3. Obtém uma credencial de curta duração.
4. Executa uma chamada ao fornecedor permitida.
5. O segredo nunca entra na resposta do modelo nem no registo de auditoria.

De acordo com a sua documentação, o nosso MCP interno Ads obtém tokens de fornecedor de curta duração no momento da chamada. O material de credencial é tratado fora do contexto do modelo e não é escrito nos registos de aplicação.

Verificar permissão no momento da execução

Um agente pode ter iniciado uma tarefa enquanto o operador tinha determinado papel. Dez minutos depois, esse papel pode ter sido revogado. Um fluxo de trabalho longo não deve assumir que a permissão do início da sessão ainda se aplica.

Para operações materiais, a autorização é verificada quando a ferramenta é executada.

O mesmo se aplica à aprovação. O consentimento para uma ação não é permissão para ações arbitrárias subsequentes.

Um prompt não é uma ACL

Uma instrução como:

você só pode ler dados e nunca deve apagar nada

pode ser uma regra comportamental útil. Não substitui um controlo que bloqueia tecnicamente DELETE.

Se o modelo pode aceder a uma ferramenta destrutiva e a uma credencial que permite eliminação, essa capacidade existe. O prompt apenas pede ao modelo que não a use.

Uma separação prática é:

• prompt: o que o agente deve fazer;
• autorização/política: o que o agente tem permissão para fazer;
• função do fornecedor/API: o que a identidade técnica pode fazer no fornecedor.

O arranjo mais seguro é quando as três camadas estão alinhadas, mas nenhuma delas é o único controlo.

Perfis em vez de um super‑agente

Na nossa ferramenta interna de publicidade, separamos capacidades de leitura/planeamento, de gestão de campanhas e uma superfície de nível de proprietário para operações administrativas raras.

Os nomes não são importantes. O ponto é que a análise ordinária não deve correr continuamente com o nível de privilégio mais alto.

Um design semelhante noutro contexto poderia ser:

Perfil	Trabalho permitido	Limite adicional
research-agent	pesquisar, ler, resumir	sem alterações de estado
operations-agent	ler, criar rascunho, atualizar campos aprovados	escopo operacional
admin workflow	operação administrativa	invocação separada, identidade/escopo, aprovação obrigatória, janela de tempo estreita

Um comprometimento ou erro num agente não concede automaticamente acesso a todas as classes de operação.

Restringir o sistema de ficheiros e ferramentas “universais”

Duas categorias merecem atenção especial.

Shell / execução de comandos

Um shell irrestrito pode contornar a maior parte de um modelo de ferramentas cuidadosamente desenhado. Se um agente pode executar qualquer comando como utilizador do SO com privilégios amplos, os escopos finos noutros lugares oferecem proteção limitada.

Ferramentas construídas para um propósito ou comandos em lista branca dentro de um ambiente restrito são normalmente mais fáceis de raciocinar.

Sistema de ficheiros

Um agente que precisa escrever um relatório em /workspace/reports não precisa de acesso a /etc, ao diretório pessoal de um operador ou a segredos de CI.

No nosso MCP interno Ads, as operações de ficheiro são limitadas a localizações aprovadas no lado do servidor ou a payloads delimitados. Caminhos de sistema arbitrários são rejeitados.

Um gateway de baixo nível ainda precisa de escopos

Por vezes, um gateway geral é útil para novos pontos finais do fornecedor antes de existir uma ferramenta dedicada. Não deve tornar‑se uma porta de escape.

Deve classificar:

• método HTTP;
• ponto final;
• recurso;
• características do payload;
• se a operação grava ou destrói estado.

Só então deve mapear a solicitação para as permissões necessárias.

Se raw_request pode usar um token de acesso total sem verificações de política, efetivamente tem acesso de administrador, independentemente de quão cuidadosamente as outras ferramentas foram delimitadas.

Elevação temporária para ações de alto risco

Em vez de atribuir um escopo amplo permanentemente, o sistema pode usar elevação controlada:

1. o agente prepara a operação;
2. o gateway detecta que é necessário privilégio mais elevado;
3. uma pessoa aprova os parâmetros exatos;
4. o sistema concede permissão apenas para aquela operação ou por um curto período;
5. a permissão expira após a execução;
6. o trilho de auditoria regista a aprovação e o resultado.

Não é obrigatório em todos os contextos. Para operações críticas, reduz o tempo em que existe permissão ampla.

Leia: Quando um agente de IA deve requerer aprovação humana?

Modelo de inventário de capacidades

Antes de colocar em produção, escreva a fronteira:

Agente / fluxo de trabalho	Ferramenta	Operação	Recurso	Dados	Aprovação	Credencial	Auditoria
relatório de campanha	Ads report	read	conta A	métricas sem PII	não	curta‑duração	sim
preparação de campanha	campaign tool	write	conta A	configuração	não/condicional	curta‑duração	sim
ativação de campanha	campaign operate	operate	campanha X	orçamento + estado	sim	curta‑duração	sim
eliminação de recurso	admin tool	destructive	recurso específico	mínimo	sim	elevada	sim

Isso é muito mais útil do que escrever “o agente tem acesso ao Google Ads”.

Anti‑padrões

Uma única chave API para todo o sistema

As funções não podem ser separadas de forma limpa e o acesso para um fluxo de trabalho torna‑se difícil de revogar.

O mesmo conjunto de ferramentas para todos os agentes

A função mais abrangente do catálogo torna‑se parte da superfície de risco de cada agente.

“Somente‑leitura” apenas no prompt

Se o backend ainda aceita gravações, “somente‑leitura” é um pedido, não um controlo.

Expansão automática de escopo após um 403

Permissão ausente é motivo para parar e tomar uma decisão, não para “tentar novamente como admin”.

Credenciais no contexto do modelo

Um modelo não precisa do valor de um segredo para solicitar a um gateway confiável que execute uma chamada permitida.

Lista de verificação de menor privilégio para um agente

• O agente vê apenas as ferramentas necessárias ao seu papel.
• Leitura e escrita são separadas.
• Ativar um efeito operacional tem escopo diferente de preparar a configuração.
• Operações destrutivas têm barreira adicional.
• A permissão está limitada ao inquilino/conta/projeto/recurso.
• Recursos‑alvo ambíguos não são adivinhados automaticamente.
• As ferramentas devolvem apenas os dados mínimos necessários.
• Credenciais permanecem fora do contexto do modelo.
• Tokens são de curta duração sempre que possível.
• A autorização é verificada na execução, não apenas no início da sessão.
• Acesso ao sistema de ficheiros e ao shell é limitado ou substituído por ferramentas específicas.
• Um gateway bruto não contorna a política.
• Elevação de privilégio é explícita e auditável.
• O acesso pode ser revogado centralmente.

Exemplo trabalhado: relatório de qualidade para uma linha de produção

Considere um fluxo de trabalho proposto, não uma implementação reportada aqui. Um fabricante deseja um resumo matinal de não‑conformidades para a linha L1. O agente combina contagens, estados e prazos de ação. Não decide se libera um produto. O gestor de qualidade possui o processo; o administrador da aplicação possui a configuração de acesso.

Comece com permissão para ler registos da L1, excluindo anexos e detalhes de funcionários. Guarde o relatório num diretório interno. Não conceda funções para fechar não‑conformidades, mudar resultados de inspeção ou enviar comunicações ao cliente apenas porque a mesma API as suporta.

Se a equipa mais tarde precisar de tarefas de ação corretiva, adicione permissão para criar um rascunho para uma equipa nomeada. A criação desse rascunho não deve mudar o estado do produto. Atualize o inventário de acesso e identifique quem trata uma tarefa atribuída incorretamente. Os identificadores neste exemplo são suposições de design, não resultados de implantação Brillnet.

O que a autorização MCP estabelece

Este guia usa a especificação MCP versão 2026‑07‑28. O seu modelo de autorização HTTP requer a verificação de que um token de acesso foi emitido para o servidor pretendido. Um token válido para outro serviço não deve conceder acesso ao MCP. As orientações de segurança do MCP também tratam do encaminhamento de tokens de cliente para APIs downstream sem validação adequada.

Isso ainda não determina se um utilizador pode ler o registo do cliente B. A autorização da aplicação deve resolver a relação entre identidade e recurso‑alvo. Escopos OAuth e filtragem por inquilino cobrem partes diferentes da fronteira. Ambas são relevantes. Verifique os detalhes do protocolo contra as versões realmente usadas pelo seu cliente e servidor; “compatível com MCP” por si só diz pouco sobre restrições de acesso.

Verificar a recusa assim como o sucesso

Um relatório correto demonstra que o caminho permitido funciona. Não prova que outros caminhos estejam fechados. Durante a aceitação, mantenha resultados para um pequeno conjunto de verificações concretas:

• solicitar o mesmo tipo de objeto a partir de outro inquilino;
• chamar uma função de escrita através do perfil de relatório;
• executar após a revogação do papel do operador;
• aceder a um ficheiro fora do diretório de relatórios;
• tentar a mesma operação proibida através de um gateway geral.

Espere recusa sem alteração de estado ou divulgação de dados de recurso. Registe o identificador da verificação, a versão da política e o resultado, excluindo segredos e registos completos de clientes. Estas são sugestões de verificações de aceitação para este fluxo de trabalho, não um programa completo de testes de segurança.

Manter um responsável por alterações de permissão

O acesso tende a crescer incrementalmente: outro conector, uma exceção, um diretório adicional. Pergunte se o agente ainda executa o mesmo trabalho. Um conector que permite enviar mensagens não deve estender silenciosamente um perfil de relatório.

O proprietário do processo aprova a necessidade de negócio. O administrador provisiona e revoga o acesso. O responsável de segurança examina exceções e rotas de bypass. Numa empresa pequena, uma pessoa pode acumular vários papéis, mas as decisões devem permanecer rastreáveis. Defina um intervalo de revisão baseado na frequência de mudanças e nas possíveis consequências. Remova privilégios de instalação assim que a instalação estiver concluída.

Amanhã, inventarie um agente. Remova uma permissão que a sua tarefa não requer e verifique a recusa fora da fronteira aprovada. Isso fornece evidência útil sem exigir a substituição completa da arquitetura.

Evidência e limites

As orientações da OWASP apoiam ferramentas restritas e verificações de autorização. O NIST publica um catálogo de controlos de segurança. O nosso modelo read/write/operate/destructive e o exemplo trabalhado são recomendações de engenharia, não legislação nem certificado de conformidade. Determine separadamente as obrigações organizacionais aplicáveis. A documentação interna do Ads MCP, versão 1.0 datada de 28 de julho de 2026, descreve o design de controlo citado; não prova independentemente a operação em produção para um cliente.

Fronteira

O menor privilégio reduz o impacto máximo de um erro ou abuso. Não garante que uma operação permitida seja substantivamente correta. Por isso combinamos com validação de entrada, aprovação para ações de alto impacto e trilho de auditoria.

Volte ao guia de agentes de IA seguros ou veja Segurança Brillnet.

Duas organizações fictícias, uma tarefa limitada

Num ambiente de demonstração dedicado, dê permissão a um assistente para ler um procedimento aprovado na organização fictícia A e preparar um rascunho. Excluir aprovação, publicação, alterações de permissão e acesso à organização B. O serviço de aplicação estabelece o contexto da organização a partir do ator autenticado e do relacionamento permitido; um identificador alterado na solicitação não representa autoridade para usar os dados de outra organização.

Teste a leitura permitida, uma aprovação excluída e uma solicitação para a organização B. Para cada caso, registre o resultado esperado e inspecione o resultado real. Os casos de recusa devem deixar o estado proibido inalterado e não retornar dados não relacionados do inquilino. Mantenha a versão da política e os metadados mínimos de eventos necessários para reconstruir a verificação, excluindo credenciais e conteúdo de documento desnecessário.

Inclua uma instrução inofensiva na fonte sintética solicitando uma exportação não relacionada. Trate-o como conteúdo de documento. A tarefa aprovada e as permissões do servidor permanecem a base para a operação permitida. Isto mostra como o tratamento imediato e o acesso forçado precisam trabalhar juntos no projeto proposto.

No Pulsar, registre o requisito, o risco, a ação e as evidências fictícias para revisão. Isso testa como sua equipa documenta o controle. Isso não significa que a avaliação pública do Pulsar expõe um gateway MCP ou implementa todas as permissões de agente em sua arquitetura. Revise o teste de 14 dias, a forma de pagamento exigida e os termos de cancelamento e concorde com uma integração externa separadamente, se necessário.

Fontes

• OWASP AI Agent Security Cheat Sheet. Acedido: 2026-10-02.
• OWASP Authorization Cheat Sheet. Acedido: 2026-10-02.
• Model Context Protocol — The 2026-07-28 Specification. Acedido: 2026-10-02. Fontes verificadas: 2026-10-10.
• MCP — HTTP authorization specification, 2026-07-28 — Autorização de transporte e tokens vinculados a recursos.
• MCP — security best practices — Segurança de integração e limites de autorização.
• NIST SP 800-53 Rev. 5 — Princípios de controle de acesso e controle de auditoria.
• OWASP — LLM01 Prompt Injection — Instruções de documentos não confiáveis ​​e riscos do agente.
• OWASP — Logging Cheat Sheet — Registros de eventos úteis e informações confidenciais excluídas.
• Pulsar GRC — data-exchange scope — Limite para reivindicações de integração pública.
• Escopo do produto e termos de avaliação publicados — Escopo do produto e termos de avaliação publicados.

Revise os termos e inicie o teste de 14 dias

Auditar uma operação de IA: autorização, resultado e estado verificado

CAPA de produção de alimentos: da descoberta à avaliação da eficácia

Um POP farmacêutico alterado: verifique o formação e a versão fonte