RBAC Compatible con IA
Por qué el control de acceso tradicional falla cuando los agentes de IA actúan en nombre de los usuarios, y cómo Edison Watch aplica límites de datos rastreando audiencias de origen.
Función Alpha: RBAC Compatible con IA está en desarrollo activo. Las funciones y APIs pueden cambiar. Para el análisis completo, consulte Agentic AI Disrupts Traditional Data Security Posture.
Las llamadas a herramientas MCP no llevan identidad de acceso del backend. Cuando un agente lee un documento de Google Drive, la respuesta contiene el contenido del archivo pero no quién tiene permitido verlo. Cuando el agente luego envía un email, la llamada contiene el destinatario pero nada que lo vincule a la lista de acceso del documento de origen. El RBAC tradicional se detiene en la autenticación - nunca rastrea si la audiencia de destino es un subconjunto de la audiencia de origen.
El problema
Un agente conectado a Google Drive y Gmail puede leer un documento compartido con los usuarios A y B, luego enviar su contenido al usuario C. Desde la perspectiva del proveedor de identidad, no ocurrió ninguna violación - las credenciales de Alice accedieron a los archivos de Alice y enviaron los emails de Alice. Pero los datos llegaron a alguien fuera de la lista de acceso original.
La causa raíz: las llamadas a herramientas MCP no propagan la lista de control de acceso de los datos que devuelven. La sesión del agente aplana todo en un solo contexto sin memoria de quién tenía permiso para ver qué.
Por qué esta es una amenaza específica de IA
Las aplicaciones tradicionales aplican RBAC en la capa de API - cada solicitud está limitada a un usuario, un recurso, una acción. Los agentes de IA rompen este modelo porque:
- Acumulación de contexto - el agente lee de múltiples fuentes en una sesión, mezclando datos con control de acceso en una sola ventana de contexto
- Flujo implícito de datos - cuando el agente resume información de la fuente A en un mensaje enviado a través de la herramienta B, no existe ninguna operación de "copia" explícita para que DLP la detecte
- Colapso de identidad - el agente actúa como un usuario pero maneja datos con múltiples ámbitos de acceso
Cómo Edison Watch resuelve esto
Edison Watch extiende el Lethal Trifecta con rastreo de origen y destino de datos, asegurando que los destinatarios sean un subconjunto estricto de quienes tenían acceso de lectura a los datos de origen.
Rastreo de origen - cuando un agente lee de una fuente (Drive, Confluence, OneDrive), Edison registra la lista de acceso de ese recurso: quién puede ver estos datos.
Validación de destino - cuando el agente intenta enviar datos (email, mensaje de Slack, compartir archivo), Edison resuelve el conjunto de destinatarios y verifica: ¿está cada destinatario en la lista de acceso original? Si no, la acción se bloquea.
Aplicación de subconjunto - la regla es simple: destinatarios ⊆ lectores_origen. Si el usuario C no está en la lista de acceso del documento que el agente leyó, el envío se deniega - aunque Alice misma tenga permiso para enviar emails a C.
Esto va más allá del Lethal Trifecta estándar (que señala categorías amplias de riesgo) al hacer una determinación precisa, por acción, basada en las identidades reales involucradas.