--- title: "Cómo dar acceso al código a un agente programador de IA sin arriesgar producción" description: "Un diseño de seguridad con espacios aislados, credenciales breves, ramas protegidas, tests, revisión humana, logs y respuesta a incidentes." author: "Carlos García" published: 2026-09-06 updated: 2026-09-06 language: es human_url: "https://kiia.cloud/es/blog/agente-programador-ia-acceso-codigo-seguridad/" --- > **En 60 segundos:** Tratá al agente como un colaborador no confiable con capacidades útiles. Empezá con lectura y permití escritura solo dentro de una rama o patch aislado. No le des secretos duraderos ni acceso directo a producción. Filtrá la red, ejecutá tests y escaneos, exigí revisión protegida y registrá sus acciones. El texto del repositorio es dato, no instrucción confiable. Prepará una respuesta ante una ejecución comprometida antes de habilitar trabajo autónomo. Conectar un chat al repositorio puede acelerar cambios pequeños. También puede permitir que un issue malicioso, un script de dependencia o un comando equivocado llegue a credenciales y configuración de despliegue. El objetivo no es confiar más en el modelo. Es diseñar un camino donde una mala propuesta siga siendo un cambio revisable y no un incidente de producción. ## Separá lectura, propuesta y aplicación Usá tres niveles de autoridad. En lectura, el agente inspecciona un checkout limitado y explica un cambio. En propuesta, crea un patch o commit en su propia rama. En aplicación, una automatización protegida o una persona hace merge y despliega después de las comprobaciones. La mayoría de equipos debería empezar con acceso de propuesta. El agente hace trabajo útil mientras el proceso de ingeniería continúa siendo responsable de producción. No conectes un agente al checkout principal de una laptop si puede leer archivos ajenos, llaves SSH, sesiones del navegador o credenciales cloud. Dale a cada tarea un espacio descartable con repositorio y ciclo de vida definidos. ## Protegé el repositorio fuera del modelo GitHub Rulesets puede exigir pull requests, revisiones, status checks, historial lineal, commits firmados y restricciones a force push. Revisá las [reglas disponibles en rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets) y aplicá el camino de producción en la plataforma. Una instrucción como "nunca hagas push a main" es útil, pero no es un control. El token o la instalación deben carecer de ese permiso y la rama debe rechazar la acción. Protegé por separado los entornos de despliegue. Hacer merge y desplegar producción son permisos diferentes. Un agente capaz de abrir un PR no necesita aprobar un release. ## Construí un flujo de ejecución aislado 1. Creá un runner efímero o worktree administrado para una sola tarea. 2. Descargá únicamente el repositorio y referencia necesarios. 3. Empezá con permisos de lectura. 4. Habilitá escritura acotada a una rama cuando la tarea lo requiera. 5. Eliminá credenciales persistentes y usá tokens breves con alcance mínimo. 6. Limitá la salida de red a los servicios indispensables. 7. Permití que el agente edite y pruebe dentro del espacio aislado. 8. Escaneá diff, dependencias, archivos generados y secretos. 9. Abrí un pull request con comandos ejecutados y riesgos restantes. 10. Exigí revisores y checks habituales antes del merge. 11. Destruí el runner y revocá las credenciales de la tarea. La explicación de GitHub sobre su [arquitectura de seguridad para flujos con agentes](https://github.blog/ai-and-ml/generative-ai/under-the-hood-security-architecture-of-github-agentic-workflows/) trata aislamiento por capas y manejo seguro de salidas. Las [notas de seguridad de Codex Action](https://github.com/openai/codex-action/blob/main/docs/security.md) recomiendan ejecución sin privilegios y perfiles acotados. Usalas como referencias y comprobá los controles de tu runner real. ## Tratá el contenido del repositorio como entrada no confiable Un issue puede pedir al agente que suba variables de entorno. Un README puede ordenar ejecutar un instalador remoto. Una captura puede ocultar texto. Una instalación puede ejecutar scripts. Un log de tests puede incluir contenido de un atacante. OWASP incluye prompt injection y manejo inseguro de salidas entre sus [riesgos para aplicaciones con LLM](https://genai.owasp.org/resource/llm-top-10-for-llms-v1-1/). Separá las instrucciones de la tarea de los datos del repositorio. No insertes títulos de issues o campos del PR directamente dentro de comandos. Validá argumentos y rutas. Ejecutá el agente después de los pasos sensibles cuando sea posible. Si modifica el espacio, los pasos posteriores deben asumir que scripts y archivos cambiaron. Guardá artefactos de revisión, no credenciales. ## Entregá capacidades, no archivos con secretos Muchas tareas no requieren secretos. Cuando sean necesarios, preferí un proxy o capacidad limitada. Revisar una migración puede necesitar metadata del esquema, no la contraseña de producción. Comprobar un deploy puede necesitar estado de solo lectura, no escritura sobre la cuenta cloud. Acotá credenciales por repositorio, entorno, acción y tiempo. Ocultar un secreto en logs no sirve si el proceso puede enviarlo por la red. Combiná aislamiento con límites de salida. ## Los tests son una capa Exigí build, lint, tipos, tests y escaneos habituales. Cuando se pueda, agregá un test de regresión antes de implementar. Revisá cambios no relacionados y cualquier modificación a CI o despliegue. Que los tests pasen no demuestra seguridad. Pueden estar incompletos, haber sido modificados por el agente o no detectar una dependencia maliciosa. Protegé los checks obligatorios para que el colaborador no pueda quitarlos. La revisión humana debe mirar comportamiento, acceso a datos, permisos, dependencias e impacto de despliegue. Un diff grande y generado requiere más atención, no menos. ## Prepará la respuesta a una ejecución comprometida Escribí un playbook breve: detener el job, revocar credenciales, conservar logs, cerrar o aislar el PR, inspeccionar artefactos, revisar tráfico y buscar la misma exposición en cambios recientes. Asigná responsable antes del lanzamiento. Probá los controles con un fixture inofensivo que contenga una instrucción maliciosa. El camino inseguro debe fallar de manera visible. Revisá permisos cuando cambien agente, repositorio, runner o proveedor. El [AI Risk Management Framework de NIST](https://www.nist.gov/itl/ai-risk-management-framework) ayuda a asignar gobierno y respuesta a incidentes sin tratar al modelo como una excepción de seguridad. Kiia puede diseñar el límite del repositorio, la ruta de revisión y el primer flujo seguro. El resultado útil no es un agente con acceso ilimitado, sino un colaborador que hace propuestas acotadas mientras tus controles mantienen la autoridad. ## Preguntas frecuentes ### ¿Un agente programador debería acceder directamente a la rama de producción? No. Dejalo trabajar en una rama aislada o generar un patch, y aplicá el proceso normal de revisión y merge protegido. ### ¿Los tests vuelven seguro el código generado? Reducen riesgo, pero no prueban corrección ni seguridad. Mantené revisión, privilegio mínimo, escaneo y controles de despliegue. ### ¿Qué datos pueden contener prompt injection? Tratá issues, pull requests, comentarios, commits, documentación, capturas, dependencias y salidas de herramientas como entradas no confiables.