IA para ciberseguridad: cómo gobernar acceso por niveles

Un modelo capaz de analizar malware, reproducir un exploit y operar herramientas puede ayudar a cerrar una vulnerabilidad o acelerar un ataque. El mismo prompt cambia de significado según el activo, la autorización, el entorno y la persona que lo ejecuta. Un control que solo decide permitir o bloquear produce dos fallos previsibles: corta trabajo defensivo legítimo o concede una superficie ofensiva demasiado amplia a cualquier cuenta que supere una revisión inicial.

Anthropic anunció el 6 de octubre de 2026 una ampliación de su Cyber Verification Program con tres niveles de acceso: Defense, Red Team y Specialized. Cada nivel reduce bloqueos para un alcance diferente y eleva requisitos de identidad, credenciales, dispositivos, red y respuesta. La noticia importa más allá de un proveedor: propone tratar la capacidad avanzada como un grant condicionado y revocable, no como una propiedad permanente del modelo o del usuario.

Defense Access cubre tareas como respuesta a incidentes, ingeniería inversa de malware y validación de vulnerabilidades. Red Team añade pruebas adversariales sobre sistemas autorizados, pero mantiene bloqueos en acciones que podrían causar daño físico o disrupción masiva. Specialized reserva los menores bloqueos para organizaciones verificadas que prueban sistemas críticos, como redes eléctricas, telecomunicaciones o transferencias interbancarias. No son tres modelos distintos: son combinaciones distintas de capacidad permitida y obligaciones alrededor del uso.

Eso desplaza la decisión desde el selector de modelo hacia un plano de control. El plano debe responder quién solicita, para qué activo, con qué evidencia de autorización, desde qué workspace, usando qué credencial, herramientas y destinos de red, y bajo qué monitoreo. Verificar una empresa al inicio no basta. El grant necesita permanecer unido a esas condiciones durante cada sesión y desaparecer cuando cambie el rol, el proyecto o el riesgo.

Empieza con una matriz que conecte tarea, activo, entorno y evidencia. Analizar un binario enviado por un cliente no equivale a escanear Internet; reproducir una falla en un laboratorio no autoriza tocar producción; pertenecer al red team no prueba que ese dominio esté en alcance. El sistema debe admitir una solicitud solo si puede resolver el propietario del activo, la ventana aprobada, la técnica permitida y la persona o workload responsable.

Modela el grant con expiración y condiciones, no con un rol eterno. Una entrada mínima puede incluir subject, purpose, asset IDs, tool set, egress allow-list, start, expiry y approval reference. La política de inferencia debe leer ese contrato antes de habilitar capacidades sensibles y registrar qué condición decidió el resultado. Así una auditoría puede reconstruir por qué una sesión recibió más capacidad que otra sin depender de una captura del panel administrativo.

Los requisitos publicados prohíben sesiones compartidas y exigen atribución a una persona o workload. Para niveles superiores, piden MFA resistente al phishing, cuentas del dominio corporativo y credenciales emitidas por la identidad nativa de la plataforma. La razón es operativa: si una API key estática representa a todo el equipo, no puedes distinguir abuso, revocar a un usuario ni demostrar quién inició una acción después de un incidente.

Separa humanos y servicios. Una persona obtiene acceso después de SSO y WebAuthn; un agente automatizado usa federación de workload, alcance mínimo y expiración corta. El gateway valida issuer, audience, subject, workspace y grant en cada llamada, sin convertir un token válido en permiso universal. Anthropic establece, para sistemas de credenciales operados por el cliente en Red Team y Specialized, un máximo de doce horas y capacidad de revocar identidades comprometidas dentro de veinticuatro horas; son requisitos del programa, no un benchmark de seguridad universal.

Un grant organizacional no debería aparecer automáticamente en todos los proyectos. Crea workspaces dedicados por programa o cliente, con miembros nombrados, almacenes separados y herramientas explícitas. Un analista de malware puede necesitar un desensamblador y muestras aisladas, pero no credenciales de despliegue. Un agente que revisa código puede leer un repositorio y abrir un hallazgo, pero no necesita secretos de producción ni acceso a otros tenants.

La segmentación también limita el blast radius de contexto. Si prompts, archivos, transcripciones y resultados de herramientas viven en el mismo espacio general, una consulta inocente puede recuperar material de una investigación sensible. Aplica namespace por grant, políticas de retrieval, cifrado y claves por entorno, y evita que memorias o caches crucen fronteras. Prueba el aislamiento con casos negativos: un usuario correcto en el workspace equivocado debe recibir un rechazo observable, no datos parciales.

Un system prompt que dice no salir del laboratorio no contiene una ejecución. El proceso que corre herramientas debe vivir en un sandbox sin capacidad de modificar su propia política. La red se restringe con una allow-list aplicada fuera del host, los destinos se resuelven antes de ejecutar y cada conexión queda registrada. Los requisitos del CVP usan esta frontera para trabajo ofensivo o agentic en Red Team y Specialized: el workstation puede ser flexible, pero la acción sensible ocurre donde el agente no controla la salida.

Aplica el mismo principio a herramientas. Define esquemas estrictos, límites de frecuencia, cuotas, rutas de archivos y confirmaciones para acciones irreversibles. Un escáner recibe targets del contrato de alcance, no texto libre; una herramienta de explotación solo apunta al entorno efímero creado para el test; una función de reporte puede escribir evidencia, pero no borrar logs. El modelo propone una acción y el runtime la autoriza contra estado actual. Esa separación sigue siendo necesaria aunque el proveedor ya aplique clasificadores de seguridad.

El programa exige retención para detectar abuso y atribuir actividad. El problema es que señales peligrosas pueden aparecer en varias sesiones o cuentas, mientras el material analizado puede contener código propietario, datos personales o información regulada. Registrar todo sin propósito crea otro riesgo; descartar cada interacción de inmediato impide correlacionar un patrón. Define eventos mínimos: identidad, grant, herramienta, target normalizado, decisión de política, resultado y hash de evidencia sensible.

Después fija quién guarda, quién puede leer, por cuánto tiempo y qué activa revisión humana. Anthropic describe Enterprise Frontier Safeguards como una arquitectura futura donde los logs permanecen en la nube del cliente, bajo sus claves, y las señales automatizadas llegan a su equipo. Hoy el CVP conserva excepciones y dependencias por plataforma. Trátalo como una capacidad anunciada en despliegue gradual, no como una garantía ya disponible para cada integración. Antes de adoptar, confirma región, retención, roles y procedimiento de borrado con el proveedor concreto.

No evalúes solo cuántas tareas completa el modelo. Construye un set con trabajo permitido, solicitudes fuera de alcance, targets ambiguos, identidades revocadas, tools no autorizadas y secuencias que distribuyen riesgo entre sesiones. Mide utilidad en tareas defensivas, tasa de bloqueo correcto, escape de acciones prohibidas, falsos positivos, atribución completa y tiempo hasta revocación. Repite con varios intentos: una política que falla una vez de cincuenta sigue teniendo un camino explotable.

Anthropic reporta que, en su evaluación CyScenarioBench, el nivel Defense bloqueó 46 de 50 intentos en algún punto, mientras Red Team no bloqueó y completó 34 de 50. Es una medición del proveedor sobre Claude Opus 5.5 y una configuración específica; no demuestra la seguridad de tu gateway ni la calidad de tu operación. Reproduce tus propios escenarios, ejecuta tabletop incidents y exige que el equipo pueda suspender un seat, revocar un workload, aislar el sandbox y preservar evidencia dentro de tiempos definidos.

Supongamos una fintech que quiere usar un agente para validar vulnerabilidades en una copia aislada de su API de transferencias. El ejemplo es hipotético y no describe un cliente de Wasyra. Seguridad crea un grant de Red Team para ocho personas, restringido a un clon sin datos reales, durante una ventana de cuatro horas. Cada miembro entra con SSO y passkey; el runner usa federación de workload; el gateway solo acepta los IDs del laboratorio y tres herramientas versionadas.

La red del sandbox solo alcanza el target, un repositorio de paquetes aprobado y el colector de evidencia. El agente puede proponer y ejecutar pruebas dentro de cuota, pero cualquier intento de cambiar destino o elevar privilegios se rechaza fuera del modelo. Los logs guardan decisiones y hashes; payloads sensibles quedan cifrados en la cuenta del equipo. Al cerrar la ventana, expiración, revocación y destrucción del entorno se prueban como parte del resultado, no como limpieza informal.

El piloto no se aprueba porque encontró más fallas. Pasa si mejora la cobertura defensiva sin escapar del alcance, cada acción conserva atribución, los falsos bloqueos permanecen manejables y el ejercicio de incidente cumple el tiempo objetivo. Un hallazgo crítico todavía requiere reproducción independiente, triage y un proceso de divulgación o corrección. El agente acelera una disciplina existente; no reemplaza la autorización ni la responsabilidad profesional.

El anuncio y la documentación describen controles de Anthropic, no un estándar independiente ni una auditoría de terceros. Sus cifras de vulnerabilidades provienen del proveedor y de reportes parciales de participantes con métodos distintos; el propio anuncio reconoce datos incompletos sobre parches y extrapola impacto probable. No uses esos números para pronosticar productividad, retorno económico o reducción de incidentes en tu empresa.

Tampoco asumas que un nivel transferirá permisos entre proveedores o nubes de la misma forma. CVP tiene disponibilidad y provisioning distintos en Claude Platform, Vertex AI, Microsoft Foundry y Bedrock, y algunas capacidades todavía dependen de Enterprise Frontier Safeguards. Verifica el contrato real, los controles técnicos y la región antes del diseño. Mantén además defensas propias: DLP, gestión de secretos, clasificación de datos, revisión de herramientas y un canal de incidentes no deben depender de un solo clasificador del modelo.

El aporte útil del acceso por niveles es convertir el riesgo dual en condiciones verificables. Alcance ejecutable, identidad individual, credenciales breves, workspaces separados, herramientas y egress contenidos, monitoreo con límites y respuesta ensayada forman un solo sistema. Si una pieza falta, verificar al solicitante no impide que una sesión legítima se desborde o que una credencial comprometida conserve poder.

Antes de pedir acceso más amplio, documenta qué tarea hoy queda bloqueada, qué capacidad mínima la resuelve y qué controles puedes demostrar. Después prueba utilidad y contención con el mismo rigor. Si necesitas convertir ese contrato en un piloto de IA operable, Wasyra puede ayudarte a diseñar el plano de control, la evaluación y el rollout gradual sin confundir acceso avanzado con autorización ilimitada.