SEGURIDAD DE IAv1.0Validada

LLM Security Review

CyberSkill operativa para revisar la superficie de seguridad de una solución basada en LLM.

01

Objetivo

  • Identificador: CS-01
  • Versión / estado: v1.0 · Validada
  • Autor: No definido
  • Responsable: No definido
  • Última revisión: 18/09/2026
  • Criticidad: Alta
  • Rol de ejecución: Security Engineer / AI Security Engineer
  • Tiempo estimado: 4–8 horas para revisión documental; pruebas controladas pueden ampliar el tiempo
  • Marcos de referencia: ISO/IEC 27001 · NIST AI RMF · NIST CSF 2.0 · OWASP GenAI Security Project · AI Act cuando resulte aplicable al sistema

Objetivo operativo

Revisar la superficie de ataque de una solución basada en LLM y determinar si entradas, contexto, herramientas, datos, salidas y dependencias están protegidos con controles verificables. Habilita una decisión de aceptación, remediación o escalado antes de producción o tras un cambio relevante.

Límite explícito: No certifica el modelo ni valida por sí sola cumplimiento jurídico, privacidad, seguridad del proveedor ni ausencia total de jailbreaks o prompt injection.

Cuándo se usa

  • Antes de poner en producción una aplicación con LLM o cambiar de modelo/proveedor.
  • Tras incorporar herramientas, function calling, archivos, memoria, conectores o nuevas fuentes de datos.
  • Durante una revisión de seguridad, auditoría técnica o respuesta a un incidente relacionado con el LLM.

Skills relacionadas: Secure RAG Review cuando exista recuperación documental; MCP Security Review cuando las herramientas se publiquen mediante MCP; AI Agent Security Review cuando el LLM pueda planificar y ejecutar acciones autónomas.

02

Entradas mínimas

  • Obligatoria:Diagrama de arquitectura y flujos de datos del componente LLM, incluyendo proveedor, endpoints y fronteras de confianza.
  • Obligatoria:Inventario de modelos, versiones y parámetros de despliegue utilizados en el entorno revisado.
  • Obligatoria:System prompts, plantillas de prompt, reglas de tool/function calling y política de contexto accesible al modelo.
  • Obligatoria:Matriz de identidades y permisos de usuarios, servicios y herramientas invocables por el LLM.
  • Obligatoria:Clasificación de los datos que pueden entrar en prompts, contexto, memoria o salidas.
  • Obligatoria:Configuración de logging, retención, filtros/guardrails, límites de uso y gestión de secretos.
  • Opcional:Resultados previos de red team, pruebas de jailbreak, prompt injection o evaluación de abuso.
03

Secuencia operativa

  1. Delimitar la superficie LLM. Enumerar modelo, prompts, contexto, archivos, memoria, herramientas, APIs, usuarios, datos y dependencias externas. Entregable intermedio: Mapa de superficie y fronteras de confianza.
  2. Revisar exposición de instrucciones y contexto. Verificar qué instrucciones, secretos, datos internos o metadatos podrían filtrarse mediante interacción directa o indirecta. Entregable intermedio: Registro de vectores de exposición y evidencia asociada.
  3. Evaluar prompt injection y abuso de instrucciones. Ejecutar pruebas controladas sobre prompts directos e indirectos, instrucciones conflictivas y contenido no confiable sin salir del alcance autorizado. Entregable intermedio: Bitácora de pruebas, resultado, entrada utilizada y comportamiento observado.
  4. Revisar herramientas y autorización. Comprobar que cada herramienta opere con mínimo privilegio, validación de parámetros, autorización fuera del modelo y límites de acción. Entregable intermedio: Matriz herramienta → identidad → permiso → control.
  5. Revisar datos, memoria y secretos. Comprobar retención, aislamiento de sesión, tratamiento de PII/confidencial, secretos y persistencia de contexto. Entregable intermedio: Matriz de datos y evidencias de configuración.
  6. Revisar salida, monitorización y respuesta. Verificar controles de salida, registro de eventos, detección de abuso, límites, alertas y capacidad de revocación. Entregable intermedio: Registro de cobertura de controles detectivos y de respuesta.
  7. Cerrar la revisión. Consolidar hallazgos, riesgo residual, evidencia pendiente y puntos que requieren aprobación humana o del proveedor. Entregable intermedio: Informe LLM Security Review y registro de pendientes.
04

Principios de ejecución

Controles y evidencias

  • Aislamiento de instrucciones y datos: Separación entre instrucciones de sistema, contenido no confiable y datos sensibles; evidencia: prompts/configuración y pruebas controladas.
  • Autorización de herramientas: La autorización debe verificarse fuera de la decisión generada por el modelo; evidencia: IAM/policies, código o configuración y logs.
  • Gestión de secretos: Ausencia de secretos embebidos en prompts, repositorios o parámetros visibles; evidencia: referencias a secret manager y configuración.
  • Mínimo privilegio y límites de acción: Scopes, allowlists, cuotas, timeouts y restricciones de operación; evidencia: policies y configuración efectiva.
  • Trazabilidad: Registro suficiente para asociar usuario/sesión, modelo, herramienta y acción; evidencia: muestra de logs y política de retención.
  • Controles de abuso: Rate limiting, detección de patrones anómalos y mecanismos de bloqueo; evidencia: configuración y eventos de prueba.

Criterios de aceptación

  • Todos los componentes LLM y herramientas relevantes están dentro del alcance documentado.
  • Todas las entradas obligatorias han sido revisadas o su ausencia está registrada como limitación.
  • Cada hallazgo referencia una evidencia concreta o declara expresamente que la evidencia está pendiente.
  • Las pruebas controladas son reproducibles y no exceden el alcance autorizado.
  • Los riesgos altos no aceptados quedan escalados con propietario y decisión pendiente.

Límites y escalado

  • Exposición confirmada de secretos, datos sensibles o capacidad de acción no autorizada.
  • Controles del proveedor no verificables que resulten determinantes para el riesgo.
  • Impacto jurídico o de privacidad que requiera DPO/Legal/Compliance.
  • Necesidad de pruebas ofensivas fuera del entorno o alcance expresamente autorizado.
La skill no debe asumir controles, evidencias ni decisiones no demostradas. Los puntos jurídicos, humanos o de fabricante quedan fuera de la autonomía de ejecución y deben escalarse al responsable correspondiente.
05

Resultado

Informe de revisión de seguridad LLM con alcance, mapa de superficie, matriz de herramientas/permisos, pruebas ejecutadas, evidencias, hallazgos, riesgo residual y acciones pendientes. Destino: expediente técnico o repositorio de evidencias definido por el proyecto.

SKILL.md portable

El SKILL.md contiene la misma versión operativa de la skill en formato Markdown portable: metadatos, objetivo, triggers, entradas, secuencia, controles/evidencias, criterios de aceptación, salida, límites y referencias. La versión Validada se congela y se acompaña de un hash SHA-256 separado. El hash acredita integridad del fichero, no firma digital ni no repudio. Autor y responsable permanecen como “No definido” hasta que exista una asignación formal.

Ver SKILL.md portable →