Pular para o conteúdo principal

Modelo de segurança da IA

O princípio

O assistente listando as capacidades e as lacunas da conta que pergunta Perguntado o que pode fazer, o assistente relata as permissões efetivas de quem consulta — inclusive o que falta. Aqui ele nomeia os códigos ausentes e conclui que a conta é de um curador que pode limpar, deduplicar e consolidar, mas não configurar o esquema nem excluir registros.

Um agente age como o usuário autenticado. Não há conta de serviço, nem credencial intermediária, nem identidade privilegiada à qual a camada de IA recorra.

Este é todo o modelo de segurança, e ele é deliberadamente monótono. O alcance de um agente é exatamente o alcance de quem o opera, então raciocinar sobre o que um agente pode fazer se reduz a raciocinar sobre o que aquela pessoa pode fazer — uma pergunta que você já sabe responder.

O que um agente não pode fazer

Não podePorque
Ver dados que quem o opera não pode verTodas as camadas são reavaliadas por requisição
Reconstruir um valor mascaradoEle recebe a máscara; o mascaramento ocorre na geração da resposta
Elevar suas permissõesEle não tem identidade própria para elevar
Agir sem rastroToda ação é auditada, atribuída ao usuário
Alterar dados num passo irrefletidoAlterações exigem prévia e efetivação explícitas

Dados não confiáveis

Dados mestres contêm texto livre fornecido por outras pessoas — nomes, comentários, descrições, corpos de requisição. Qualquer um deles pode conter texto que se pareça com uma instrução.

O prompt do sistema instrui o modelo a tratar a saída das ferramentas como dado não confiável e a delimitá-la ao exibi-la.

Isto é uma instrução ao modelo, não um controle no servidor

Resultados de ferramentas são devolvidos como respostas brutas da API; o servidor atualmente não os envolve num invólucro de dado não confiável. Portanto essa mitigação depende de o modelo seguir instruções, que é exatamente a suposição que a injeção de prompt ataca.

A defesa que sustenta tudo é o modelo de permissões, não o prompt. Mesmo um agente completamente subvertido carrega apenas as permissões de quem o opera, então o pior que ele alcança é o que aquela pessoa já poderia alcançar — e toda ação é auditada sob a identidade dela.

Trate a delimitação como defesa em profundidade. Se o seu modelo de ameaças exige aplicação no servidor, levante isso como lacuna em vez de supor que está presente.

Valores mascarados

Um agente recebe valores mascarados como máscaras e só pode repeti-los. Não há nada a reconstruir.

Instruí-lo a remover a máscara não é recusado por política — é impossível. O valor não está presente no que o agente recebeu.

Autonomia não é autorização

Um modo de autonomia governa se uma pessoa é consultada antes de uma ação. Nunca governa o que a requisição subjacente tem permissão de fazer.

Um agente no modo mais permissivo, operando para um usuário somente-leitura, continua sem poder escrever.

Alterações

Operações de escrita exigem dois passos explícitos: uma prévia mostrando o que mudaria, depois a efetivação. Um agente não pode se autoconfirmar — a confirmação não é algo que ele consiga produzir sozinho.

Toda alteração exposta é reversível, e é isso que torna os modos de autonomia mais permissivos defensáveis.

Auditoria

Ações de agente vão para o mesmo log de auditoria somente-adição de qualquer outra ação, atribuídas ao usuário cuja identidade foi utilizada. Não há caminho separado nem menos rastreável.

A seguir


Última verificação no commit d3c2586b (2026-08-03)