Como projetar um assistente de IA limitado por ferramentas, permissões e contexto

Um assistente de IA limitado é um serviço cujo contrato executável define o que pode consultar, produzir e alterar. Dizer no prompt “não envie mensagens” não basta se a ferramenta conectada e sua credencial ainda permitem o envio. A fronteira real está nos dados elegíveis, nas operações expostas, na identidade atuante, nas permissões do sistema de destino, nos limites operacionais e nas condições de interrupção.

A unidade prática de controle é cada capacidade visível ao usuário, não o assistente inteiro. Pesquisar, resumir, recomendar, redigir, atualizar, enviar, excluir e aprovar exigem autoridades diferentes, mesmo quando aparecem na mesma conversa. Essa divisão permite verificar antes da estreia quais ações são possíveis e, depois, descobrir qual capacidade falhou, mudou de comportamento ou acumulou acesso além do necessário.

O que o assistente deve ter permissão para fazer?

A equipe deve começar por uma carta de serviço de uma frase e decompor sua promessa em capacidades específicas. Uma fórmula útil é: “Para usuários elegíveis, o assistente pode realizar determinada família de tarefas, usando um escopo aprovado de informações, para produzir um resultado permitido, mas não pode realizar os não objetivos ou as decisões consequenciais declaradas”. Verbos vagos como “ajudar” ou “gerenciar” devem dar lugar a operações observáveis.

• Usuários elegíveis e forma de autenticação.
• Ambiente de implantação e tarefas apoiadas.
• Fontes e classificações de dados permitidas.
• Resultados que podem ser respondidos, propostos, redigidos ou executados.
• Supervisão humana, responsáveis pelo risco e resultados proibidos.

O AI RMF do NIST orienta documentar finalidade, ambiente de uso, tarefas apoiadas, limites de conhecimento, escopo, supervisão humana e tolerância a risco. A OWASP recomenda oferecer somente a funcionalidade mínima da ferramenta e preferir uma operação estreita a uma extensão aberta. Transformar esses princípios em uma matriz por capacidade é uma síntese editorial prática, não uma exigência formal imposta por nenhuma das organizações.

Quais informações cada capacidade pode usar?

O limite de contexto deve ser um envelope de informação, e não apenas um orçamento de tokens. Para cada capacidade, registre sistemas aprovados, tipos de registro, classificações, filtros de objeto, intervalo temporal, expectativa de atualização, direitos do usuário e dados proibidos. Os resultados Map do NIST pedem limites de conhecimento, escopo de aplicação e supervisão documentados para o uso das saídas.

• Fontes, contas, registros e campos elegíveis.
• Filtros por usuário, objeto, data e classificação.
• Atualização mínima exigida para responder.
• Classes de confiança do conteúdo recuperado.
• Histórico disponível somente na sessão.
• Memória persistente, isolamento, expiração e exclusão.
• Dados que nunca podem ser armazenados.

A OWASP orienta tratar mensagens externas, documentos, anexos, respostas de API e conteúdo recuperado como não confiáveis e mantê-los separados das instruções do serviço. Para memória persistente, a orientação da OWASP inclui validação antes da gravação, isolamento por usuário e sessão, expiração, limite de tamanho, análise de dados sensíveis e proteção de integridade. Quando a evidência necessária estiver ausente, inacessível ou desatualizada, o assistente deve recusar ou qualificar a resposta; ampliar a janela de contexto não cria autoridade nem comprova uma afirmação.

Como identidade, ferramentas e permissões devem impor a fronteira?

Autenticação, autorização e aprovação são decisões diferentes. A primeira estabelece quem é o usuário, cliente, agente ou processo; a segunda decide qual operação essa identidade pode realizar sobre um recurso protegido; a terceira aceita uma ação proposta específica. A especificação de autorização do MCP distingue cliente, servidor de recurso protegido e servidor de autorização emissor de tokens, mas essa arquitetura não é uma obrigação universal para ferramentas fora do protocolo.

• Escolha explicitamente entre autoridade delegada do usuário e identidade controlada do serviço.
• Exponha operações estreitas, com parâmetros e formatos validados.
• Restrinja verbos, recursos, objetos, campos e destinos.
• Limite duração da credencial e público de destino do token.
• Defina limites próprios de taxa, repetição, cadeia, lote, gasto e tempo.

Em integrações MCP protegidas, a especificação recomenda escopos de privilégio mínimo e permite vincular a autorização ao servidor de recurso pretendido. A OWASP recomenda permissões mínimas no sistema de destino, preservação do contexto de autorização do usuário e mediação de cada solicitação pelo sistema que protege o recurso. A permissão deve ser aplicada pelo gateway da ferramenta e pelo sistema que protege o recurso, usando a identidade atuante; o prompt não é um controle de autorização. O NCSC recomenda privilégio mínimo, padrões seguros, restrições às ações acionáveis por IA e mecanismos externos de proteção quando necessários.

A conversa pode ser contínua, mas sua autoridade deve ser dividida em capacidades pequenas e impostas de forma independente.

Até onde cada capacidade pode agir?

Cada capacidade precisa de um teto de ação explícito, com controles independentes mais fortes à medida que se aproxima de uma mudança externa. Uma escala editorial útil separa informação, proposta, rascunho, gravação reversível, ação externa consequencial e decisão proibida. Ela é uma síntese prática apoiada nos princípios citados, não uma classificação oficial do NIST, do NCSC ou da OWASP.

• Responder ou resumir informações elegíveis sem mudar estado.
• Recomendar ou montar uma proposta inspecionável.
• Criar um rascunho em destino não final.
• Alterar campos autorizados dentro de fluxo reversível.
• Enviar, publicar, excluir, conceder acesso ou assumir compromisso externo.
• Recusar decisões reservadas a especialista ou processo separado.

Para ações consequenciais, a OWASP orienta separar decisão e execução e validar uma aprovação vinculada aos elementos exatos da ação. A OWASP também orienta vincular a aprovação de uma ação de alto impacto ao ator, à ferramenta, ao recurso, aos parâmetros normalizados, ao momento e à validade. A aprovação deve mostrar uma prévia verificável e ser invalidada se destinatário, conteúdo ou parâmetros mudarem. Aprovação não concede uma permissão ausente, não amplia o acesso permanente e não transforma uma decisão proibida em permitida. O NCSC recomenda restringir as ações que um componente de IA pode acionar e adotar proteções externas, baseadas ou não em IA, quando necessário.

O que deve ocorrer quando o assistente atinge uma fronteira?

Recusa, ajuda parcial segura, encaminhamento humano e escalada de segurança devem ser resultados explícitos do serviço, acompanhados de uma condição real de parada. O assistente precisa declarar a fronteira sem revelar detalhes sensíveis e jamais afirmar que consultou uma fonte, obteve aprovação, executou uma ferramenta ou gravou um registro quando isso não ocorreu. Os resultados Measure do NIST incluem falha segura além dos limites de conhecimento documentados e avaliação em condições semelhantes às de uso.

• Tarefa fora do escopo.
• Informação não elegível.
• Autorização insuficiente.
• Aprovação necessária.
• Evidência ausente ou desatualizada.
• Julgamento de especialista necessário.
• Ferramenta ou dependência indisponível.
• Limite operacional alcançado.
• Sinal de segurança detectado.

O encaminhamento deve levar objetivo original, contexto não sensível, capacidade tentada, motivo, evidência disponível ou ausente, próximo passo e identificador de rastreamento. Rotina de atendimento, aprovação de negócio e incidente de segurança precisam de destinos e responsáveis distintos, embora possam compartilhar evidências. O NCSC recomenda planos de incidente com cenários de resposta, escalada e remediação, profissionais preparados e registros de auditoria de boa qualidade. A OWASP inclui desvio de aprovação, elevação de privilégio, exfiltração de dados, envenenamento de memória e abuso recursivo de ferramentas entre os casos relevantes de abuso de agentes.

Como transformar as fronteiras em um desenho operacional?

A equipe deve preencher uma linha de canvas para cada operação visível ao usuário e ligar a linha a controles aplicáveis, evidências, testes, métricas e responsáveis. A recomendação da OWASP de minimizar ferramentas e permissões sustenta controles separados para consultar, redigir e enviar. O canvas é uma síntese editorial: seu valor depende de a arquitetura realmente impor o que foi documentado.

• Capacidade, tarefa e resultado que caracteriza sucesso.
• Ator elegível, autenticação e identidade atuante.
• Envelope de informação, sessão e memória.
• Operação da ferramenta, recursos, campos e limites.
• Teto de ação, aprovação, recusa e ajuda parcial.
• Registro, cenários de avaliação, métricas, escalada e responsável.

A orientação de monitoramento da OWASP contempla decisões, chamadas de ferramenta, resultados de autorização, identificadores de aprovação, versões de política, desfechos, uso de recursos e padrões anômalos, com redação de dados sensíveis. Os resultados de governança do NIST pedem papéis claros, linhas de comunicação, responsabilidades humanas e de IA diferenciadas, monitoramento contínuo e revisão periódica. Portanto, uma linha sem sinal operacional, teste e dono nomeado ainda não constitui um controle completo.

Quais evidências permitem liberar e manter o assistente?

A liberação exige evidência de que o serviço permitido e as negativas esperadas funcionam em condições semelhantes às reais. O AI RMF do NIST contempla testes representativos do uso, monitoramento em produção, limites de generalização documentados, falha segura e avaliações regulares de segurança. O NCSC recomenda avaliação de segurança antes da liberação e comunicação das limitações e dos modos de falha conhecidos.

• Tarefas positivas e variações legítimas.
• Acesso a outra conta ou recurso.
• Ferramenta ou campo não autorizado.
• Evidência ausente, antiga ou adulterada.
• Conteúdo recuperado com instrução adversarial.
• Dados proibidos e tentativa de exfiltração.
• Desvio de aprovação ou parâmetros alterados.
• Repetição duplicada e falha de dependência.
• Cadeia excessiva e acionamento do interruptor de segurança.

Os registros devem reconstruir solicitante, capacidade, política, classes de fonte e ferramenta, decisões de autorização e aprovação, ação resultante e versões ativas, sem guardar segredos ou contexto sensível ilimitado. O NCSC recomenda monitorar saídas e desempenho para perceber mudanças de segurança súbitas ou graduais, respeitando requisitos de privacidade e proteção de dados. Os indicadores devem ser definidos por capacidade: uso inesperado de ferramenta, negativas repetidas, falhas de autorização, mudanças de aprovação, sequências anômalas, latência, consumo e falhas.

Segundo o NCSC, mudanças em dados, modelos e prompts podem alterar o comportamento e precisam aparecer no regime de testes e avaliação. A mesma disciplina deve alcançar alterações materiais em recuperação, memória, ferramentas, permissões, políticas, fornecedores e contexto operacional. Toda mudança material deve reabrir os testes e as evidências das capacidades afetadas. Comece pela menor capacidade útil e amplie a autoridade por revisão controlada, envolvendo responsáveis por segurança, identidade, privacidade, registros, risco e serviço sempre que o impacto exigir.