RBAC Compatível com IA
Por que o controle de acesso tradicional falha quando agentes de IA agem em nome dos usuários, e como o Edison Watch impõe limites de dados rastreando públicos de origem.
Recurso Alpha: RBAC Compatível com IA está em desenvolvimento ativo. Recursos e APIs podem mudar. Para a análise completa, consulte Agentic AI Disrupts Traditional Data Security Posture.
As chamadas de ferramentas MCP não carregam identidade de acesso do backend. Quando um agente lê um documento do Google Drive, a resposta contém o conteúdo do arquivo mas não quem tem permissão para vê-lo. Quando o agente depois envia um email, a chamada contém o destinatário mas nada que o vincule à lista de acesso do documento de origem. O RBAC tradicional para na autenticação - nunca rastreia se o público de destino é um subconjunto do público de origem.
O problema
Um agente conectado ao Google Drive e Gmail pode ler um documento compartilhado com os usuários A e B, depois enviar seu conteúdo para o usuário C. Da perspectiva do provedor de identidade, nenhuma violação ocorreu - as credenciais de Alice acessaram os arquivos de Alice e enviaram os emails de Alice. Mas os dados chegaram a alguém fora da lista de acesso original.
A causa raiz: as chamadas de ferramentas MCP não propagam a lista de controle de acesso dos dados que retornam. A sessão do agente achata tudo em um único contexto sem memória de quem tinha permissão para ver o quê.
Por que esta é uma ameaça específica de IA
Aplicações tradicionais aplicam RBAC na camada de API - cada solicitação é limitada a um usuário, um recurso, uma ação. Agentes de IA quebram este modelo porque:
- Acumulação de contexto - o agente lê de múltiplas fontes em uma sessão, misturando dados com controle de acesso em uma única janela de contexto
- Fluxo implícito de dados - quando o agente resume informações da fonte A em uma mensagem enviada via ferramenta B, não existe nenhuma operação de "cópia" explícita para o DLP detectar
- Colapso de identidade - o agente age como um usuário mas lida com dados com múltiplos escopos de acesso
Como o Edison Watch resolve isso
O Edison Watch estende o Lethal Trifecta com rastreamento de origem e destino de dados, garantindo que os destinatários sejam um subconjunto estrito de quem tinha acesso de leitura aos dados de origem.
Rastreamento de origem - quando um agente lê de uma fonte (Drive, Confluence, OneDrive), o Edison registra a lista de acesso desse recurso: quem pode ver estes dados.
Validação de destino - quando o agente tenta enviar dados (email, mensagem do Slack, compartilhamento de arquivo), o Edison resolve o conjunto de destinatários e verifica: todos os destinatários estão na lista de acesso original? Se não, a ação é bloqueada.
Aplicação de subconjunto - a regra é simples: destinatários ⊆ leitores_origem. Se o usuário C não está na lista de acesso do documento que o agente leu, o envio é negado - mesmo que Alice tenha permissão para enviar emails para C.
Isso vai além do Lethal Trifecta padrão (que sinaliza categorias amplas de risco) fazendo uma determinação precisa, por ação, baseada nas identidades reais envolvidas.