Respuesta directa
En pocas palabras
Para gestionar secretos en un sistema de IA, registra cada credencial sin copiar su valor, vincúlala con un propietario, consumidor, finalidad, ambiente y permisos, y entrega el secreto desde un gestor autorizado solo durante la ejecución. Prefiere identidades de servicio y tokens de corta duración frente a claves estáticas compartidas; impide que prompts, RAG, memoria, logs o datasets reciban credenciales; rota con un periodo controlado de coexistencia; y revoca después de demostrar que ningún workload, integración o proceso de recuperación depende del valor anterior.
Separa identidad, secreto, token y permiso antes de elegir una herramienta
Una identidad responde quién o qué solicita acceso. El secreto es material confidencial usado para autenticar, firmar, cifrar o derivar otra credencial. El token representa una autorización con emisor, audiencia, alcance y vigencia. El permiso define la acción permitida sobre un recurso. Mezclarlos conduce a controles débiles: esconder una API key no reduce sus privilegios, y cifrar un token no corrige una audiencia demasiado amplia.
Incluye claves de APIs de modelos, contraseñas de bases, tokens OAuth, refresh tokens, llaves SSH, certificados, claves de firma, webhooks, credenciales de nube, cuentas de servicio y material de recuperación. No todo debe gestionarse igual. Una clave de cifrado de largo plazo requiere custodia distinta de un token de sesión. Define tipo, propósito, emisor, consumidor y consecuencia de exposición antes de fijar almacenamiento o rotación.
Construye un inventario de referencias y dependencias, no una hoja con valores
Registra identificador, tipo, sistema emisor, consumidores, propietario técnico, responsable de negocio, ambiente, organización, región, finalidad, permisos, fecha de creación, vencimiento, última rotación, próxima revisión y ruta de revocación. Guarda una referencia al vault o proveedor, nunca el valor. Relaciona cada entrada con servicio, job, agente, herramienta, pipeline, notebook, modelo y proveedor que podría fallar al cambiarla.
Descubre secretos fuera del catálogo mediante escaneo de repositorios, historial Git, imágenes, manifests, variables de CI, archivos locales, notebooks, tickets, wikis, backups, logs y configuraciones de proveedores. Trata un hallazgo como posible exposición aunque el archivo ya no esté en la rama actual: el historial, una imagen o un fork pueden conservarlo. Verifica alcance antes de borrar evidencia o rotar de forma desordenada.
Asigna una identidad distinta a cada workload y agente
Un servicio, worker, pipeline o agente no debe actuar con la cuenta personal de un desarrollador ni con una credencial compartida por todo el equipo. Asígnale una identidad de workload reconocible por ambiente y función. La identidad debe permitir responder qué componente hizo la solicitud, en nombre de qué organización, bajo qué release y con qué política, incluso cuando la acción comenzó por una persona.
NIST SP 800-207A lleva zero trust desde la ubicación de red hacia identidades de aplicaciones y servicios con políticas granulares. La red sigue aportando contexto, pero estar dentro de una VPC no concede confianza. Autentica el workload, valida su estado y autoriza cada recurso. En sistemas multi-tenant, la identidad de plataforma no sustituye el límite de organización: el servicio aún debe comprobar el objeto y la autoridad del usuario o proceso que originó la acción.
Prefiere credenciales temporales y federación cuando el proveedor lo permita
Una credencial estática puede permanecer útil después de copiarse. Una identidad federada puede intercambiar una prueba de workload por un token corto, limitado a una audiencia y conjunto de acciones. Prefiere este patrón para CI/CD, nube y servicios compatibles. Reduce duración hasta el tiempo operativo necesario y diseña renovación explícita. Corta no significa segura si el token puede renovarse indefinidamente o su emisor está comprometido.
Conserva secretos estáticos solo donde el sistema no admita una alternativa, documenta por qué y reduce su blast radius. No conviertas un secreto raíz de largo plazo en requisito de cada contenedor. Usa un broker, identidad administrada, sidecar o mecanismo equivalente para que el workload reciba lo mínimo. Comprueba issuer, audience, subject, firma, expiración y scopes en el destino; poseer un token no debe bastar si fue emitido para otro servicio.
| Criterio | Uso apropiado | Control decisivo |
|---|---|---|
| Secreto estático | Compatibilidad heredada o clave duradera justificada | Scope mínimo, vault, rotación y revocación |
| Token corto | Sesión o acceso delegado con vigencia limitada | Issuer, audience, subject, scopes y expiración |
| Identidad de workload | Servicio que obtiene acceso sin clave distribuida | Attestation, política por recurso y trazabilidad |
| Break-glass | Recuperación excepcional cuando falla el camino normal | Custodia separada, uso aprobado, alerta y rotación posterior |
Centraliza custodia y entrega el secreto durante runtime
Usa un servicio diseñado para almacenar, versionar, autorizar, auditar y rotar secretos. Cifra tránsito y almacenamiento, separa administración de consumo y protege la clave o identidad que abre el gestor. Un vault no debe convertirse en una interfaz donde cualquier mantenedor revela valores. Prefiere que el workload solicite la credencial durante su ciclo de vida, en lugar de que CI la copie a imágenes, artefactos o archivos permanentes.
Reduce el tiempo en texto plano y la cantidad de componentes que lo tocan. Un secreto puede llegar por memoria, archivo temporal protegido, socket, sidecar o integración nativa, según plataforma y amenaza. Evita argumentos de proceso, nombres de archivo descriptivos, páginas de error y variables visibles a procesos vecinos. Si un servicio debe reiniciarse para adoptar la nueva versión, incorpora esa dependencia en el procedimiento de rotación.
Separa ambientes, organizaciones, proveedores y funciones
Producción no debe reutilizar valores de desarrollo, demo o pruebas. Separa proyectos, cuentas, vaults, claves y políticas cuando el riesgo lo exija. Un incidente en un notebook no debería abrir producción. Evita una API key global para varios clientes, regiones o agentes si el proveedor permite identidades o proyectos distintos. La segmentación debe facilitar revocar una parte sin detener todo el servicio.
Separa lectura, escritura, envío, exportación y administración. Una integración que consulta disponibilidad no necesita modificar precios. Un agente que redacta una propuesta no necesita enviar correo. Un evaluador offline no requiere credenciales de producción. Las herramientas disponibles para el modelo deben recibir permisos desde una capa determinista; el texto del prompt no puede ampliar scopes ni seleccionar otra organización.
Mantén secretos fuera de prompts, RAG, memoria, logs y datasets
No insertes claves, tokens, contraseñas o cadenas de conexión en system prompts, plantillas, documentos recuperables, memoria conversacional o ejemplos de evaluación. El modelo no necesita leer la credencial para pedir una herramienta. La aplicación valida identidad, organización, finalidad, parámetros y aprobación; después entrega el secreto directamente al cliente autorizado que ejecuta la operación.
Trata documentos, HTML, plugins y contenido recuperado como entradas no confiables. Una instrucción indirecta no debe poder pedir al agente que muestre variables, lea archivos de configuración o llame una herramienta administrativa. Aplica allowlists, esquemas estrictos, sandbox, egress limitado y respuesta redactada. Excluye secretos de trazas, prompts de depuración, observabilidad, feedback y datasets; en pruebas usa valores sintéticos que no sean aceptados por ningún sistema real.
Autoriza la acción mínima y comprueba la política en el destino
Define permisos por recurso y verbo, no con roles genéricos como integración o agente. Limita cuenta, proyecto, modelo, endpoint, tabla, bucket, Buyer Room o webhook. Añade condiciones de ambiente, región, hora, red, release o aprobación cuando aporten una frontera real. Revisa permisos efectivos, incluidas herencias, grupos, políticas administradas y capacidad para crear nuevas credenciales.
Prueba que las acciones necesarias funcionan y que las prohibidas fallan. Incluye acceso entre organizaciones, administración, exportación, cambio de precio, envío, lectura de secretos y escalamiento de permisos. Un error visible y seguro es mejor que un fallback silencioso a una identidad más poderosa. La disponibilidad no justifica usar una clave maestra como respaldo automático.
Rota con dos versiones y una condición clara de retiro
Inventaría consumidores y mide una baseline antes del cambio. Emite una versión nueva, distribúyela solo a identidades autorizadas y permite una ventana acotada en la que ambas versiones funcionen cuando el proveedor lo soporte. Actualiza canary o una población pequeña, confirma autenticación, acciones y errores, y amplía por etapas. La fecha de creación de la clave nueva no demuestra adopción.
Retira la versión anterior después de verificar réplicas, workers, jobs, notebooks, integraciones, regiones, backups operativos y procesos de recuperación. Observa intentos de uso del valor revocado: identifican consumidores olvidados o posible abuso. Define rollback sin reactivar indefinidamente una credencial expuesta. Si el cambio falla, corrige el consumidor o usa una excepción temporal aprobada con vencimiento y monitoreo.
Cuando aparece un secreto, presume exposición hasta delimitarla
Un secreto en Git, chat, ticket, captura, log, notebook o respuesta del modelo puede haber sido copiado antes de borrarse. Conserva el hallazgo, identifica valor, permisos, vigencia, consumidores, repositorios, forks, artefactos, logs y periodo. Revoca o rota con prioridad proporcional al alcance y la accesibilidad. Eliminar la línea no invalida el material ya distribuido.
Busca uso anómalo por identidad, recurso, acción, origen, horario y volumen. Si la credencial permite emitir otros tokens, firmar artefactos o administrar políticas, amplía el alcance a los derivados. Separa exposición de abuso confirmado e incidente. Comunica según evidencia y obligaciones; no publiques el valor en un reporte. Después del cambio, valida que el anterior falla y que no quedan sesiones, cachés o credenciales descendientes activas.
Registra el uso sin volver a registrar el secreto
Audita quién o qué solicitó acceso, recurso, decisión, política, versión, hora, expiración, resultado y correlación con release o acción humana. No registres el valor, Authorization headers, payloads completos ni respuestas del vault. Protege los logs contra modificación y sincroniza tiempo. La auditoría del gestor prueba entrega; combínala con el log del servicio destino para demostrar la acción efectiva.
Alerta por lectura masiva, recurso inusual, ambiente equivocado, error repetido, uso desde una identidad o red inesperada, creación de credenciales, cambio de política, intento con secreto vencido y acceso break-glass. Ajusta reglas con baseline y riesgo. Un contador alto puede ser un despliegue normal; una sola lectura de una clave de firma puede ser crítica. Conserva runbook, owner y prueba periódica por alerta.
Diseña recuperación y break-glass sin crear una puerta permanente
El gestor de secretos y sus identidades son dependencias críticas. Define disponibilidad, backup cifrado, recuperación de claves, restauración y acceso cuando el proveedor o identidad primaria falla. NIST SP 800-57 Part 2 trata política, planificación, custodia, continuidad y recuperación de material criptográfico como responsabilidades organizacionales, no como opciones de una consola.
Mantén credenciales break-glass separadas, con custodia dividida o aprobación proporcional, acceso limitado, alerta inmediata y procedimiento probado. Cada uso crea un incidente o revisión, se registra sin exponer el valor y termina con rotación. Prueba que funciona antes de necesitarla y que no evita límites de organización o datos. Una copia de emergencia sin dueño, prueba o vencimiento es otro secreto huérfano.
Mide cobertura y capacidad de revocar, no solo cantidad de secretos
Mide porcentaje inventariado con owner, consumidores trazables, credenciales compartidas, secretos estáticos, permisos excesivos, vencimientos próximos, rotaciones fallidas, consumidores del valor anterior, filtraciones detectadas, tiempo hasta revocar y uso break-glass. Separa ambientes y criticidad. Una reducción de secretos puede ser buena si proviene de federación; puede ser mala si el inventario perdió cobertura.
Revisa el programa con desarrollo, plataforma, seguridad, datos, privacidad y responsables del servicio. Prioriza raíces de confianza, claves de firma, administración, acceso multi-tenant y credenciales que emiten otras credenciales. Mantén excepciones con razón, control compensatorio, owner, fecha y prueba. El cierre exige que la identidad correcta acceda a lo mínimo, el valor anterior falle y el recorrido operativo siga funcionando.
Aplica el control de secretos a los límites verificables de Cerravi
En Cerravi, la gestión se relacionaría con identidad, organización, ambiente, release, finalidad, acción, proveedor, referencia protegida, rotación y evidencia. Los secretos no formarían parte de prompts, Buyer Rooms, propuestas, logs públicos ni datasets. Una herramienta recibiría la credencial después de validar el contexto y la autoridad, y los cambios conservarían backup, journal, readiness, release anterior y rollback.
Este diseño no amplía capacidades públicas. Cerravi organiza contexto y propone siguientes pasos para revisión humana; no envía mensajes ni cambia etapas automáticamente desde los recorridos públicos. Las propuestas usan productos y precios conocidos y piden revisión si falta un importe. Las monedas permanecen separadas salvo conversión aprobada. Forecast aplica reglas transparentes del CRM, no un modelo predictivo entrenado o calibrado, y no garantiza cierres. Un vault y una rotación reducen exposición; no certifican seguridad, cumplimiento ni ausencia de credenciales comprometidas.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Dónde deben guardarse las API keys de un sistema de IA?
En un gestor de secretos autorizado, con cifrado, control de acceso, auditoría, versiones y una referencia estable. El workload debe obtenerlas durante runtime mediante su propia identidad. No deben quedar en código, imágenes, notebooks, prompts, RAG, logs, tickets ni archivos compartidos.
¿Una variable de entorno es un gestor de secretos?
No. Puede ser un mecanismo de entrega, pero no aporta por sí sola inventario, autorización granular, rotación, auditoría o revocación. Además puede quedar visible a procesos, diagnósticos o dumps. La seguridad depende de cómo se genera, limita, entrega y elimina el valor.
¿Qué diferencia hay entre una API key y una identidad de workload?
Una API key suele ser un valor que quien lo posee puede reutilizar. Una identidad de workload permite autenticar un servicio por su contexto y obtener acceso limitado, a menudo temporal, sin distribuir una clave duradera. Ambas requieren autorización en el recurso destino.
¿Cómo se rota un secreto sin detener producción?
Emite una versión nueva, permite coexistencia durante una ventana breve, actualiza primero un canary, verifica autenticación y función, expande por etapas y revoca la anterior solo después de confirmar todos los consumidores. Monitorea cualquier intento posterior con el valor retirado.
¿Borrar una API key filtrada del repositorio resuelve la exposición?
No. El historial, forks, artefactos, cachés y clones pueden conservarla. Debe revocarse o rotarse, delimitar permisos y periodo, buscar uso anómalo, revisar credenciales derivadas y demostrar que el valor anterior ya no funciona.