Modelo de Risco & Classes de Proteção

Capacidade total de agente não significa que um agente pode fazer tudo. Significa que o sistema pode descrever de forma estruturada cada um de seus estados e cada uma de suas capacidades, incluindo as capacidades que permanecem fundamentalmente vedadas a um agente. O modelo de risco é a ferramenta que traça esse limite: de forma precisa, legível por máquina e sem exceções.

Áreas sensíveis

Algumas partes de um sistema exigem proteção maior, não apenas contra invasores externos, mas também contra agentes internos. Um equívoco comum diz:

O usuário pode ver, portanto a IA também pode ver.

Isso não é correto. O acesso efetivo da IA resulta da interseção de permissão do usuário, permissão do agente, nível de confiança do cliente, sensibilidade do recurso, finalidade e status de confirmação. Cada um desses elementos é uma barreira independente, não apenas a função do usuário.

As áreas sensíveis que precisam ser especialmente protegidas incluem:

• Dados financeiros, dados bancários, dados de pagamento, detalhes de faturamento
• Dados de saúde, documentos médicos, prontuários, atestados
• Dados salariais, salário, bônus, histórico salarial, ciclos de folha de pagamento
• Dossiês de pessoal, contratos, documentos de candidatura, avaliações internas
• Credenciais de acesso & API Keys, senhas, chaves privadas, tokens de acesso
• Funções de exclusão e em massa, excluir usuários, excluir tenant, exportação em massa
• Gestão de direitos, conceder e revogar permissões, alterar funções
• Logs de segurança, Audit Trails, Security Events, sessões ativas
• Comunicação privada, notas confidenciais, avaliações internas
• Dados fiscais e contratos, documentos fiscalmente relevantes, contratos com efeito jurídico
• Dados pessoais nos termos do RGPD, todos os dados que identificam uma pessoa natural

Seis classes de proteção

Cada Resource e cada Tool é atribuída a uma das seis classes de proteção. A classe determina quem tem acesso, se um agente vê a Tool na Discovery e qual aprovação é necessária antes da execução.

Public

Conteúdo publicamente acessível sem restrições. Sem autenticação, sem função especial, sem confirmação necessária. Adequado para artigos de ajuda, informações de produto e capacidades de sistema documentadas.

help.article.read
public.product_info.read

Internal

Apenas para usuários autenticados. A autenticação é suficiente; sem direitos especiais necessários. Típico para consultas de lista, pesquisas e visualizações de trabalho gerais do próprio contexto.

project.list
contact.search

Confidential

Acessível apenas com função explícita e scope atribuído. Um simples login não é suficiente. Os dados são internos, mas não destinados a todos os colaboradores.

contract.read
customer_private_note.read

Sensitive

Apenas com aprovação adicional ou transmissão de contexto restrita. Um agente não pode carregar esses dados sem verificação em seu contexto. Ao transmitir para uma IA, o escopo deve ser estritamente limitado e a finalidade documentada.

salary.read
bank_account.read
health_document.read

Critical

A IA não pode agir de forma autônoma nesta classe. Cada execução requer uma aprovação explícita do usuário, frequentemente Step-up Authentication. As ações geram efeito externo, são difíceis de reverter ou afetam terceiros diretamente.

payment.execute
user.delete
contract.send
email.send_external
security.change_permissions

Forbidden for AI

Esta classe é um limite rígido, não uma decisão de policy. Tools e Resources desta classe são completamente ocultadas da Tool Discovery para agentes. Um agente não pode lê-las, invocá-las nem usá-las como referência.

password.read
private_key.read
full_database_export
raw_access_token.read

O modelo de risco

O modelo de risco traduz as classes de proteção em regras operacionais para cada caso de execução. Define se a autonomia é permitida, se a confirmação é necessária e que tipo de aprovação é exigida.

Low

Operações puramente de leitura ou ações sem efeito externo permanente. Agentes podem invocar essas Tools de forma autônoma.

Medium

Dados ou estados são criados ou alterados, mas dentro de um scope estritamente definido sem efeito externo. A execução autônoma é permitida quando o scope e o contexto emergem inequivocamente do workflow.

High

Ações que alteram estados relevantes do sistema ou afetam outros usuários e recursos externos. Uma confirmação explícita é geralmente necessária.

Critical

Comunicação externa, pagamentos, exclusões, alterações de permissões. Sempre confirmação, frequentemente Step-up Auth. A execução autônoma não é permitida.

Forbidden

Completamente bloqueado para AI Agents, nem leitura nem escrita. Não visível na Discovery, não invocável, não utilizável como referência.

UX de Aprovação

O modelo de risco técnico só funciona completamente quando a interface do usuário também cumpre seu papel. Uma confirmação é tão boa quanto a informação com base na qual ela é concedida.

Antes de um humano confirmar uma ação crítica de agente, ele deve ser capaz de reconhecer claramente sete coisas:

1. O que o agente quer fazer?, A ação concreta, não a intenção do agente em suas próprias palavras.
2. Por que o agente quer fazer isso?, Qual intenção ou tarefa desencadeou essa ação.
3. Quais dados são usados?, Destinatários, anexos, entidades referenciadas.
4. Quais efeitos externos surgem?, O que muda fora do sistema: e-mail é enviado, pagamento é disparado, documento é transmitido.
5. Quem é afetado?, Pessoas, empresas, tenants, partes externas.
6. A ação pode ser desfeita?, Declaração clara: reversível ou irreversível.
7. O que acontece ao confirmar?, Descrição completa dos próximos estados do sistema.

O exemplo a seguir mostra como um cartão de aprovação completo para a tool emails.send_external se parece:

O agente aguarda a decisão do usuário. Ele não pode antecipar a confirmação, definir uma ação padrão nem basear a execução no timestamp de uma aprovação anterior.