Seguridad de agentes de IA: Lista de verificación de controles prácticos

La seguridad de los agentes de IA es el sistema de control que rodea a un modelo capaz de leer el contexto, elegir herramientas y actuar en diferentes etapas. Un diseño seguro asume que la salida del modelo, el contenido recuperado y los resultados de las herramientas pueden ser erróneos o maliciosos. Limita el acceso, valida cada acción, visibiliza la incertidumbre y asigna una responsabilidad a las personas responsables de los cambios que se produzcan.

Ottermind aplica este mismo enfoque de límites prioritarios al trabajo conectado: el contexto de origen y los entregables permanecen revisables, mientras que las acciones consecuentes siguen sujetas a permisos y aprobación humana. Es una opción del espacio de trabajo, no un sustituto de la revisión de seguridad de la organización.

Investigación y divulgación: La lista de verificación se basa en NIST Marco de gestión de riesgos de IA, OWASP Top 10 para aplicaciones de LLM y Guía de seguridad del agente Anthropic, revisadas el 3 de septiembre de 2026.

Los cinco límites de seguridad

La seguridad se distribuye a lo largo del flujo de trabajo. Una última indicación pidiendo a un agente que “tenga cuidado” no es un control de seguridad.

Modelo de amenazas antes del diseño de la funcionalidad

Anote qué puede observar el agente, qué puede modificar y quién podría beneficiarse de un error. Considere un usuario curioso, un conector comprometido, texto malicioso en un documento recuperado, una herramienta que devuelve datos inesperados y una interrupción del servicio durante una operación de escritura. Para cada amenaza, indique un control de prevención, una señal de detección y una acción de recuperación. Este modelo de amenazas simplificado suele revelar que la funcionalidad más riesgosa es un conector demasiado amplio, en lugar del modelo en sí.

Identidad y aislamiento de inquilinos

Autentique al usuario antes de iniciar la ejecución y autorice cada recuperación y llamada a la herramienta con esa identidad. No asuma que un ID de proyecto visible para el modelo es confiable. Verifique los permisos a nivel de inquilino, proyecto, rol y registro en el servicio propietario de los datos. Para espacios de trabajo multiusuario, pruebe explícitamente una solicitud entre inquilinos y verifique que los registros no expongan nombres de archivo, fragmentos o argumentos de herramientas prohibidos.

Integridad de la recuperación

Los sistemas de recuperación pueden filtrar datos, devolver registros obsoletos o mostrar instrucciones incrustadas en documentos. Almacene la procedencia con cada fragmento: identificador de origen, propietario, fecha de vigencia y decisión de permisos. Priorice los registros de la fuente de verdad actual y exponga los conflictos. Trate los HTML, PDF, correos electrónicos y comentarios de incidencias como datos, no como instrucciones. Un modelo nunca debería poder otorgarse acceso a sí mismo solo porque un párrafo recuperado lo indique.

Aislamiento de herramientas y tiempo de ejecución

Utilice herramientas específicas que reflejen la intención del negocio en lugar de una consola genérica o un cliente HTTP sin restricciones. Valide los argumentos, aplique cuotas, establezca tiempos de espera y garantice la idempotencia de las escrituras. Ejecute el código o las acciones del navegador en un entorno aislado con un sistema de archivos desechable y acceso restringido. Separe las credenciales de desarrollo de las de producción y rote los tokens temporales después de la ejecución.

Diseño con aprobación humana

La aprobación debe mostrar la acción propuesta, el objetivo, la evidencia de origen, los efectos secundarios y las alternativas. La opción "Aprobar" no debe ocultar un conjunto de escrituras no relacionadas. Se requiere una revisión más rigurosa para la comunicación externa, la eliminación, el pago, los cambios de acceso y las actualizaciones de políticas. Almacene el aprobador, la marca de tiempo, la decisión y cualquier edición para que un reintento no pueda eludir silenciosamente el punto de control.

Casos de prueba de equipo rojo

Cree un pequeño conjunto de regresión que incluya la inyección de mensajes en un documento, un usuario sin acceso, una herramienta que devuelve JSON mal formado, una credencial caducada, un esquema modificado, un reintento duplicado y una solicitud para enviar o eliminar. El resultado esperado no siempre es una tarea completada; el rechazo seguro, la escalada y un error útil son resultados válidos. Ejecute el conjunto cada vez que cambien los mensajes, las herramientas, los conectores o las versiones del modelo.

Lista de verificación de operaciones de seguridad

• Mantener un inventario de modelos, herramientas, conectores y almacenes de datos.
• Revisar periódicamente los ámbitos de los conectores y los roles privilegiados.
• Generar alertas sobre volúmenes inusuales de herramientas, recuperaciones entre proyectos y acciones bloqueadas.
• Conservar los registros de seguimiento el tiempo suficiente para investigar incidentes sin almacenar información confidencial innecesaria.
• Documentar cómo revocar el acceso, detener una ejecución y restaurar el registro de origen.
• Proporcionar a los usuarios una forma clara de informar sobre sugerencias inseguras o contexto filtrado.

Asignación de controles a las etapas del agente

Las revisiones de seguridad son más sencillas cuando siguen el ciclo del agente. En la entrada, verifique la identidad, el propósito y los datos permitidos. Durante la recuperación, aplique los permisos y adjunte la procedencia. Durante el razonamiento, restrinja el esquema de salida y marque la incertidumbre. Antes de llamar a una herramienta, valide los argumentos y los efectos secundarios. Después de la llamada, verifique el resultado y registre la transición. Antes de finalizar, requiera la intervención del revisor correspondiente y guarde el estado final. Este mapa por etapas evita que los equipos traten la seguridad como una única puerta de enlace para un agente que, de otro modo, no tendría restricciones.

Riesgo en la cadena de suministro y los conectores

La capacidad efectiva de un agente incluye su SDK, complementos, servidores MCP, extensiones de navegador, plantillas de mensajes y ámbitos de conectores. Inventarie estas dependencias y revise las actualizaciones antes de que lleguen a producción. Utilice versiones con PIN cuando sea posible, firme o verifique los paquetes y mantenga las credenciales de prueba separadas de los datos del cliente. Un conector que puede leer una unidad completa puede generar mayor vulnerabilidad que el proveedor del modelo, incluso cuando el modelo en sí está configurado correctamente.

Contenido de una revisión de seguridad útil.

Registre el flujo de trabajo previsto, la clasificación de datos, las identidades, las herramientas, las versiones del modelo y del SDK, los escenarios de amenazas, los controles, los casos de prueba, los riesgos no resueltos y el responsable. Incluya un ejemplo de una acción bloqueada y un ejemplo de una escalada segura. Revise la documentación cuando se introduzca un nuevo conector, herramienta, modelo o nivel de autonomía; la aprobación anterior no debe ocultar silenciosamente una superficie de acción sustancialmente diferente.

Privilegios mínimos en la práctica

Proporcione a un agente solo los recursos y las herramientas necesarios para la tarea actual. Separe las credenciales de lectura y escritura. Limite el alcance de los archivos por proyecto e identidad, restrinja los destinos de red y haga expirar el acceso temporal. Pruebe el límite de permisos con un usuario que no debería poder ver el código fuente.

Contrato de llamada a herramienta

{
  "tool": "create_draft_task",
  "arguments": {"title": "...", "owner": "...", "due_date": "..."},
  "requires_approval": true,
  "idempotency_key": "project-123:brief-v2"
}

Valide los tipos, los valores permitidos, la identidad y los efectos secundarios en el código de la aplicación. Se requiere confirmación para enviar, eliminar, comprar, cambiar el acceso o publicar. Se garantiza la seguridad de los reintentos mediante claves de idempotencia.

Recuperación e inyección de mensajes.

Se tratan los documentos, páginas web, correos electrónicos y resultados de herramientas como datos no confiables. Separarlos de las instrucciones del sistema, conservar los identificadores de origen e impedir que el texto recuperado modifique los permisos o la política de la herramienta. En caso de conflicto entre fuentes o si la recuperación no tiene resultados, devolver un estado de escalada en lugar de intentar adivinar.

Evaluación y respuesta a incidentes

Pruebe casos normales, incompletos, adversarios, entre inquilinos, sensibles y de fallos de herramientas. Realice un seguimiento de las acciones bloqueadas, las sugerencias inseguras, los intentos de exposición de datos, los errores de las herramientas y las correcciones de los revisores. Mantenga una ruta de reversión y un responsable que reciba los incidentes.

Preguntas frecuentes

¿Puede un agente de IA ser totalmente autónomo?

La autonomía es una configuración limitada del producto, no una propiedad de seguridad. Cuanto más trascendental sea la acción, más estrictos deben ser los controles de aprobación, supervisión y reversión.

¿Un modelo privado resuelve la seguridad del agente?

No. Un modelo privado puede modificar el riesgo del flujo de datos, pero la identidad, la recuperación, los permisos de las herramientas, el aislamiento en tiempo de ejecución, el registro y la revisión humana siguen siendo importantes.

¿Qué deberían proteger primero los equipos?

Comience con la identidad, los permisos de recuperación y los límites de escritura de las herramientas. Un flujo de trabajo de solo lectura con trazas claras es una implementación inicial más segura que un acceso autónomo amplio.

Para la estructura del sistema, consulte Arquitectura del agente de IA; para detalles de implementación, compare con Guía Claude Agent SDK.