Identifica qué permite hacer la clave
Antes de integrar un servicio, averigua si el valor es una credencial privada, un identificador público o una clave diseñada para utilizarse en el navegador. Las condiciones varían entre servicios. Para una credencial privada, registra finalidad, proyecto y permisos necesarios, sin incluir el propio valor en la documentación compartida de la aplicación.
Imagina una aplicación que envía confirmaciones de solicitudes mediante un servicio externo. La credencial utilizada para autorizar el envío puede permitir acciones en nombre de la empresa. Si alguien la obtiene, el impacto depende de sus poderes: puede haber envíos indebidos, acceso a información o consumo de recursos, según el servicio y la configuración.
Esa distinción ayuda a formular preguntas concretas al agente. En lugar de pedir que conecte la plataforma de cualquier manera, indica la operación necesaria y pide que identifique el tipo de credencial adecuado. No concedas automáticamente permisos de administración cuando la aplicación solo necesita ejecutar una tarea delimitada en ese servicio.
Evita repartir la misma credencial entre proyectos que no necesitan compartirla. Separar finalidades y limitar permisos facilita comprender el alcance de un problema y sustituir el acceso afectado. La organización debe saber quién gestiona cada credencial y qué aplicaciones necesitan actualizarse cuando cambia.
Estas elecciones forman parte de planificar la aplicación antes de construir. Una integración tiene un propósito y un límite, además de una conexión técnica que funciona. Escribir ese límite ayuda a revisar la implementación e impide aceptar la configuración más poderosa solo porque resolvió la primera prueba.
Para preparar el siguiente paso, consulta Seguridad de aplicaciones desarrolladas con IA.
Prepara la configuración sin pegar el secreto en la conversación
Pide al agente que prepare los nombres de variables y los espacios por completar, con valores ficticios o vacíos. El valor real debe introducirse mediante el mecanismo de configuración elegido para el proyecto. Un archivo de entorno necesita permisos y tratamiento adecuados; su nombre no lo protege por sí solo.
En el ejemplo de las confirmaciones, la documentación puede indicar que existe una variable para el token del servicio de envío y explicar dónde configurarla. No necesita contener el token. La persona responsable puede completar la configuración sin convertir la credencial en un ejemplo copiado a instrucciones, informes o mensajes de soporte.
También debes definir qué puede mostrar el agente durante la comprobación. Puede confirmar que la variable está presente y se reconoció la configuración sin imprimir el valor completo. Un intento de ayudar, como mostrar todas las variables para diagnosticar un error, puede crear otra exposición en el registro de la conversación.
Al preparar el entorno para trabajar con Claude Code, distingue el archivo de ejemplo de los que contienen valores reales. El primero puede acompañar al proyecto con instrucciones de instalación. Los demás deben quedar fuera de los materiales compartidos y gestionarse según el entorno en el que se ejecutará la aplicación.
Confirma qué entrega la aplicación al navegador
Guardar una clave en una variable de entorno no basta si la configuración o el código terminan enviándola al navegador. Comprueba dónde se lee el valor y qué contenido sale del servidor. Para una operación con credencial privada, el navegador debe recibir solo la información necesaria para el resultado autorizado de esa operación.
En Next.js, las variables utilizadas con el prefijo NEXT_PUBLIC_ pueden incorporarse al JavaScript entregado al navegador. Ese mecanismo sirve para valores públicos y no debe utilizarse para un secreto privado. La comprobación debe considerar la versión construida, además del nombre de la variable existente en el archivo de configuración.
El servidor también puede revelar por error una credencial en una respuesta o un mensaje de error, incluso sin utilizar un prefijo público. Por eso, sigue el recorrido del valor desde la configuración hasta la llamada al servicio. Confirma que la respuesta devuelta a la aplicación no incluye información que solo necesitaba conocer la integración.
En el envío de confirmaciones, el usuario solicita la acción prevista y recibe el estado correspondiente. El sistema sigue necesitando verificar quién puede pedir ese envío y en qué condiciones. Mantener la clave privada en el servidor no autoriza a cualquiera a utilizar la operación sin límites o sin una regla de acceso.
Revisa el repositorio y los materiales de apoyo
La revisión debe abarcar el código actual, el historial relevante y los archivos que acompañan la entrega. Confirma que las exclusiones del repositorio se aplican a los archivos correctos. Añadir un archivo al mecanismo de exclusión no retira automáticamente contenido que ya estaba bajo seguimiento del control de versiones.
Pide al agente que identifique posibles credenciales por ubicación y categoría, sin copiarlas en la respuesta. El informe puede explicar que encontró un valor sospechoso en un archivo de configuración o en una versión anterior. Después, la confirmación debe realizarse mediante un proceso que no vuelva a propagar ese valor.
Observa también capturas de pantalla, ejemplos de solicitudes, exportaciones técnicas y registros de ejecución. Un archivo utilizado para explicar una integración puede contener más información de la necesaria. Al preparar datos de anuncios para analizarlos con IA, ayuda el mismo criterio: separar los datos útiles de la configuración y los accesos empleados para obtenerlos.
Las herramientas de detección automática pueden ayudar a encontrar patrones conocidos, pero el resultado necesita contexto. Una señal puede corresponder a un valor ficticio y la ausencia de alertas no demuestra que se reconocieran todos los formatos posibles. Combina la búsqueda con revisar los lugares donde la aplicación recibe, utiliza y presenta credenciales.
Trata una clave expuesta como un acceso que debes sustituir
Si confirmas que una credencial privada quedó expuesta, la prioridad es revocarla o sustituirla según el servicio y actualizar los lugares que dependen de ella. Retirar el valor del archivo público no invalida las copias que alguien pudo obtener. La respuesta debe incluir la credencial, la causa y la continuidad de la aplicación.
Identifica los servicios afectados y quién tiene autoridad para sustituirla. Confirma después que la aplicación utiliza la configuración nueva y que el acceso anterior dejó de ser válido. El proceso debe considerar posibles interrupciones, sin mantener indefinidamente una credencial comprometida solo porque el cambio exige coordinación entre personas.
Evalúa también el periodo y los lugares de exposición, incluidos historial y materiales compartidos, y revisa la actividad disponible en el servicio. Esa información ayuda a entender qué ocurrió y qué necesita seguimiento. No concluyas que hubo abuso sin evidencia ni confundas la ausencia de alertas con prueba de que no pasó nada.
Por último, corrige el camino que permitió la exposición y registra la comprobación realizada sin guardar el secreto en el informe. Puede ser una regla de publicación, un registro demasiado detallado o un valor situado en el lado equivocado de la aplicación. La prevención mejora cuando se resuelve esa causa y la siguiente entrega repite los controles relevantes.