Reglas de seguridad que todo Tech Lead debería aplicar
Estas son las reglas de seguridad enumeradas que este sitio destila para lanzar Claude en producción, condensadas aquí como valores predeterminados aplicables; el razonamiento completo y los modelos de amenazas se encuentran en la cobertura dedicada de seguridad y canalización RAG de este sitio.
Cómo usar esta lista de verificación
- Aplica estas reglas a cada sistema que permita a Claude llamar a una herramienta, leer un documento o actuar en nombre de un usuario, no solo a las funciones "agénticas".
- Trata esto como una puerta de pre-lanzamiento para cualquier función que otorgue a Claude acceso de escritura a un sistema real.
- Vuelve a ejecutar esta lista de verificación cada vez que se agregue una nueva herramienta, servidor MCP o fuente de datos a un agente existente.
- Combina con Reglas de diseño de herramientas, que cubre la contraparte a nivel de herramienta de varias reglas aquí.
Reglas de alcance de permisos
- Aplica el mínimo privilegio a cada credencial a la que un sistema impulsado por Claude pueda acceder. Una herramienta, un servidor MCP o una clave API deben tener exactamente el acceso que requiere su tarea, sin una concesión más amplia "por si acaso se necesita más adelante".
- Alcance las credenciales por herramienta o por integración, no por agente. Una credencial compartida con privilegios excesivos significa que un error o mal uso en una sola herramienta puede afectar a todo lo que esa credencial pueda alcanzar.
- Nunca otorgues acceso de escritura por defecto. Comienza cada nueva integración en modo de solo lectura y agrega acceso de escritura deliberadamente, con revisión, una vez que la ruta de solo lectura haya demostrado ser confiable.
- Expira y rota las credenciales de las que dependen los sistemas impulsados por Claude. Las claves API de larga duración y nunca rotadas son un riesgo permanente independientemente de cuán cuidadosamente esté diseñada la herramienta en sí.
- Mantén las credenciales de producción y staging completamente separadas. Una herramienta probada contra staging nunca debe estar a un cambio de configuración de tocar datos de producción.
Reglas de validación de salida
- Trata la salida del modelo como entrada no confiable, no como una instrucción confiable. El texto generado y los argumentos de la herramienta deben pasar la misma validación que cualquier entrada externa y no autenticada - nunca ejecutes un comando o consulta generado por el modelo directamente.
- Nunca interpeles la salida del modelo directamente en un comando de shell, consulta SQL o ruta de archivo. Utiliza consultas parametrizadas, comandos permitidos y validación de rutas exactamente como lo harías para cualquier valor enviado por el usuario.
- Valida la salida estructurada contra un esquema antes de actuar sobre ella. Una respuesta mal formada o con una forma inesperada debe ser rechazada y reintentada, no parcialmente confiada.
- Sanea cualquier salida del modelo que se muestre a los usuarios finales. La salida destinada a la visualización puede contener marcado o formato inyectado de entradas adversarias anteriores en la conversación; sanea antes de renderizar, al igual que cualquier otro contenido influenciado por el usuario.
- Asume que cualquier contenido externo que Claude lea (documentos, páginas web, datos recuperados) puede contener instrucciones adversarias. Diseña herramientas y prompts de manera que las instrucciones incrustadas en el contenido recuperado no puedan anular silenciosamente la autoridad real del prompt del sistema.
Reglas de registro y auditoría
- Registra cada llamada a herramienta sensible independientemente de la transcripción de la conversación. Una transcripción puede ser editada, truncada o perdida; un registro de auditoría dedicado para llamadas destructivas o que tocan datos sobrevive de forma independiente y apoya la revisión de incidentes.
- Registra quién o qué desencadenó una acción sensible, no solo que ocurrió. Para sistemas agénticos, captura al usuario, sesión y versión del prompt que desencadenó la acción junto con la acción en sí.
- Conserva los registros de auditoría durante más tiempo que el historial de conversación subyacente. Las necesidades de cumplimiento y revisión de incidentes suelen superar las ventanas de retención de conversaciones normales; no permitas que la retención de registros herede silenciosamente un valor predeterminado más corto.
- Alerta sobre patrones anómalos de llamadas a herramientas, no solo sobre fallos individuales. Una sola llamada a herramienta fallida es ruido; un pico repentino en el volumen de llamadas de una herramienta específica o una secuencia inusual de llamadas es una señal por la que vale la pena generar una alerta.
Reglas de secretos y credenciales
- Nunca coloques secretos en un prompt, mensaje del sistema o archivo de memoria. Cualquier cosa que el modelo pueda leer, también puede repetirla; las credenciales pertenecen a una bóveda, variable de entorno o gestor de secretos, nunca en texto que el modelo procesa.
- Nunca permitas que el mensaje de error de una herramienta filtre una credencial o detalle interno de vuelta al contexto del modelo. Un error de autenticación fallido que incluya la clave intentada o un rastreo de pila interno entrega esa información a quien lea la transcripción a continuación.
- Audita las funciones de memoria y almacenamiento a largo plazo para detectar la persistencia accidental de secretos. Una herramienta de memoria o un almacén entre sesiones al que se escribió accidentalmente una credencial seguirá reproduciéndola en sesiones futuras hasta que se encuentre y se elimine.
- Utiliza tokens de corta duración y con alcance limitado en lugar de claves estáticas de larga duración siempre que la integración lo soporte. Un token que expira limita la ventana de daño si alguna vez se expone.
Reglas de inyección y aislamiento de prompts
- Aísla el contenido no confiable de las instrucciones que el modelo debe tratar como autorizadas. Separa claramente las instrucciones a nivel de sistema del contenido proporcionado por el usuario o recuperado, de modo que una inyección de prompt incrustada en datos recuperados no pueda hacerse pasar por una instrucción del operador.
- Nunca permitas que un solo agente ingiera contenido externo no confiable y mantenga acceso a herramientas de alta privilegio en el mismo turno sin revisión. El riesgo clásico de inyección es una herramienta que lee un documento influenciado por un atacante y una herramienta que puede realizar una acción destructiva, ambas disponibles a la vez; sepáralas o agrega una puerta de confirmación entre ellas.
- Prueba los agentes contra entradas adversarias antes del lanzamiento, no solo contra entradas de "happy path". Incluye intentos de inyección de prompts, argumentos de herramientas mal formados y solicitudes que empujen los límites en el conjunto de pruebas pre-lanzamiento para cualquier agente que use herramientas.
Reglas de gobernanza
- Asigna un propietario explícito para la revisión de seguridad de cada función impulsada por Claude. Las barreras de seguridad se degradan de la misma manera que cualquier otra regla sin un propietario; consulta Cómo las reglas de opinión previenen incidentes de producción con Claude.
- Revisa las barreras de seguridad cada vez que el acceso a herramientas o el alcance de datos de una función se expande. Una función que comenzó como solo lectura y luego obtuvo acceso de escritura necesita que su revisión de seguridad se repita, no que se apruebe automáticamente desde el lanzamiento original.
Preguntas frecuentes
¿Cuál es la brecha de seguridad más común en los sistemas impulsados por Claude?
Confiar en la salida del modelo como si fuera una instrucción verificada en lugar de una entrada no confiable: interpolar texto generado directamente en un comando, consulta o ruta sin validación.
¿Por qué la inyección de prompts es diferente de un error normal de validación de entrada?
Porque la "entrada" es a menudo contenido que se le pide al modelo que lea y razone, no contenido enviado directamente por un usuario; una instrucción maliciosa incrustada en un documento o página web puede intentar redirigir el comportamiento del modelo a mitad de tarea, lo que la validación de entrada normal no cubre.
¿Debería registrarse cada llamada a herramienta o solo las destructivas?
Como mínimo, cada llamada a herramienta con un efecto secundario: escrituras, eliminaciones, pagos, comunicaciones externas. Las llamadas de solo lectura también se pueden registrar para depuración, pero el requisito de pista de auditoría es más fuerte para cualquier cosa que cambie el estado.
¿Cómo se aplica el mínimo privilegio a un solo agente con muchas herramientas?
Cada herramienta debe llevar su propia credencial con alcance limitado en lugar de que el agente posea una credencial amplia que todas sus herramientas compartan; de esa manera, un error o mal uso en una herramienta no puede alcanzar sistemas a los que solo otra herramienta necesitaba acceso.
¿Cuál es el riesgo de almacenar secretos en una función de memoria o almacenamiento a largo plazo?
Cualquier cosa que se persista en la memoria se reproducirá en el contexto de sesiones futuras; una credencial escrita una vez, incluso accidentalmente, seguirá siendo leída por el modelo en cada sesión subsiguiente que monte esa memoria hasta que alguien la encuentre y la elimine.
¿Por qué separar las credenciales de producción y staging?
Porque una herramienta probada con datos de staging, con credenciales con alcance de staging, nunca debería estar a un solo cambio de configuración de operar en producción; separarlas elimina una clase completa de incidentes de "probado accidentalmente en producción".
¿Se aplican estas reglas a las integraciones de solo lectura también?
Sí, aunque con menor urgencia; el acceso de solo lectura todavía necesita un alcance de mínimo privilegio y aún puede filtrar datos sensibles a través de la salida del modelo, incluso sin una ruta de escritura.
¿Con qué frecuencia se debe repetir una revisión de seguridad?
Como mínimo, cada vez que cambie el acceso a herramientas o el alcance de datos de una función, y de forma periódica de lo contrario; una función que no ha cambiado aún puede volverse riesgosa si el panorama de amenazas o los datos que toca han cambiado.
¿Qué se debe incluir en las pruebas adversarias pre-lanzamiento?
Intentos de inyección de prompts incrustados en contenido recuperado, argumentos de herramientas mal formados o que empujan los límites, y solicitudes diseñadas para que el agente realice una acción fuera de su alcance previsto, no solo solicitudes típicas de "happy path".
¿Es la alerta sobre el volumen de llamadas a herramientas excesiva para un equipo pequeño?
No necesariamente; incluso una alerta de umbral simple sobre un pico inusual en el recuento de llamadas de una herramienta sensible detecta bucles descontrolados y mal uso mucho antes de descubrirlo durante una auditoría manual o una queja de un cliente.
¿Cómo se relacionan estas reglas con la cobertura más profunda de seguridad-rag-pipelines en este sitio?
Esta página es la forma condensada y aplicable de las reglas; la sección de seguridad-rag-pipelines cubre los modelos de amenazas completos, los patrones de arquitectura y los ejemplos trabajados de los que se derivan estas reglas.
Relacionado
- Reglas de diseño de herramientas para agentes Claude seguros y componibles - la contraparte a nivel de herramienta de varias reglas en esta página.
- Cómo las reglas de opinión previenen incidentes de producción con Claude - por qué estas reglas necesitan un propietario para mantenerse aplicadas.
- Las Reglas Centrales de Claude: Una Lista de Referencia Rápida - la versión condensada de estas reglas junto con todas las demás categorías.
- Mejores Prácticas de Reglas de Claude - cada regla en esta sección se repite como una lista de verificación.
Versiones de Stack: Escrito contra la línea de modelos de Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado) y Claude Haiku 4.5 - y el SDK oficial de Python
anthropic(última versión 0.x). Los nombres de los modelos, precios y versiones del SDK cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs antes de confiar en ellos.