ISO 27001 y codificación segura (A.8.28) cuando el código lo escriben agentes de IA: lo que te va a pedir el auditor

¿Qué pide el control A.8.28 de la ISO 27001?

El control 8.28 de la ISO/IEC 27001:2022, Secure coding, pide aplicar principios de codificación segura al desarrollo de software. Llegó con la edición de 2022. Su guía en la ISO/IEC 27002:2022 cubre tres etapas, antes de programar, mientras se programa y en la verificación y el mantenimiento, y alcanza también al código de terceros y a los componentes open source.

La certificadora DQS describió el nuevo control en enero de 2023, en un artículo de su auditor Markus Jegelka: el marco «is to be applied holistically both to the company's own program code and to software from third parties and open source sources», es decir, se aplica de forma integral tanto al código propio como al software de terceros y open source. La edición de 2022 es la única que usa hoy un auditor: la transición desde la edición anterior terminó el 31 de octubre de 2025, y los certificados emitidos con ella caducaron ese mismo día, como recuerda la certificadora irlandesa NSAI, que cita el documento obligatorio MD 26 del IAF.

Un auditor lee el 8.28 junto con los controles de desarrollo que lo rodean, y cada uno se convierte en una pregunta muy concreta en cuanto el código lo escriben agentes:

Los títulos son los del Anexo A de 2022, en su versión inglesa. ISO vende los textos de sus normas, así que las frases que se citan en esta guía vienen de certificadoras y consultoras que las reproducen.

¿Dice algo la ISO 27001 sobre los agentes de IA que programan?

ISO 27001 no dice nada sobre los agentes de IA que programan. Su edición de octubre de 2022 solo tiene una enmienda, según el catálogo de ISO, y ningún control del Anexo A trata de IA. El código que escribe un agente en tu repositorio, con una cuenta tuya, es tu código, y se le aplican los mismos controles.

Es una respuesta que decepciona a quien espera una cláusula especial, y es la más útil. La guía del 8.28 ya te pide mantener fuera del código las prácticas inseguras, entre ellas las contraseñas incrustadas en el código y los fragmentos de código no aprobados, tal como resume ISMS.online la ISO 27002. Un agente que copia un patrón de otra parte del repositorio o de su entrenamiento está produciendo justo eso, un fragmento de código no aprobado, y más deprisa de lo que un revisor puede leerlo línea a línea. El control se escribió para código de cualquier origen, y los agentes son un origen más.

Cuando un equipo usa agentes aparecen otras dos preguntas, y las dos quedan fuera del 8.28. ¿Qué envía el agente a su proveedor de modelos, y está ese proveedor evaluado dentro de tu gestión de proveedores? Nuestras guías sobre lo que Claude Code envía a Anthropic y lo que guarda Cursor responden a la primera, herramienta por herramienta. Y si alguien te pregunta si necesitas la ISO/IEC 42001, la norma de sistemas de gestión de IA que ISO publicó en diciembre de 2023 para organizaciones «providing or utilizing AI-based products or services», es decir, que ofrecen o usan productos o servicios basados en IA, se trata de una certificación aparte, y la ISO 27001 no la exige.

¿Qué evidencias pide el auditor cuando el código lo escriben agentes?

El auditor pide tres tipos de evidencia: documentos que expliquen cómo desarrollas de forma segura, configuración que demuestre que tus comprobaciones se aplican, y registros que prueben que se ejecutaron sobre los cambios del periodo auditado. Con agentes, los documentos tienen que nombrar a los agentes, y los registros, cubrir cada cambio fusionado, también los que no escribió ninguna persona.

La consultora Advisera resume la prueba del 8.28 en una línea en su página sobre el control: el auditor comprueba «if principles for secure coding are integrated into the software lifecycle process», si los principios de codificación segura están integrados en el ciclo de vida del software, y si no los encuentra, «this is considered a nonconformity», se considera una no conformidad. Los documentos en sí «are not mandatory, but are recommended», no son obligatorios pero sí recomendables: una política de desarrollo seguro (Secure Development Policy) en una pyme, una política de codificación segura (Secure Coding Policy) aparte en una empresa más grande. En la práctica, el auditor hace unas cuantas preguntas y muestrea cambios para contrastar las respuestas:

Los tests merecen un aviso aparte. Cuando el agente escribe la funcionalidad y sus tests en la misma sesión, que todo salga en verde solo demuestra que el código hace lo que el agente entendió. En el estudio controlado de CybeDefend, al menos un tercio de las desviaciones de las reglas que el agente dejó en el código estaban cubiertas por sus propios tests, que pasaban, así que la CI no las habría señalado nunca. Lo que da sentido al 8.29 es una prueba de seguridad que no haya escrito el agente, un escaneo o una comprobación de tu CI.

¿Sirve un CLAUDE.md o un AGENTS.md como prueba de codificación segura?

Un CLAUDE.md o un AGENTS.md no es una prueba: es una política que el agente lee al empezar la sesión, y nada en él registra si el código la cumplió. En el estudio controlado de CybeDefend del 24 de agosto de 2026, una sección de reglas realista dejó tantas reglas incumplidas por ticket como sin archivo, 2,27 frente a 2,28.

Los equipos que preparan una auditoría con agentes suelen meter su estándar de codificación segura en CLAUDE.md o en AGENTS.md, y es un buen sitio para que el agente lo encuentre. La propia documentación de Anthropic sobre la memoria marca el límite: Claude trata estos archivos «as context, not enforced configuration», como contexto y no como configuración que se impone, y «there's no guarantee of strict compliance», no hay garantía de que se cumplan al pie de la letra. Nuestro estudio midió lo que eso significa en tickets reales. Un agente, Claude Opus 5, trabajó en treinta tickets de desarrollo con tres configuraciones, noventa ejecuciones evaluadas a ciegas con rúbricas selladas. Con una sección de reglas mantenida a mano, el agente implementó de forma exacta 7 de los 55 valores concretos de las reglas, la misma nota que sin archivo. Con el corpus completo de reglas pegado tal cual en el archivo, llegó a 7 de 11. Tienes los detalles en nuestro artículo sobre si Claude Code sigue tu CLAUDE.md.

Para un auditor, esa es la diferencia entre diseño y operación. El archivo demuestra que pusiste el estándar por escrito y se lo diste al agente, lo que ayuda con el 8.25 y el 8.28. Sobre el código que salió no demuestra nada. En el mismo estudio funcionó mejor entregar cada regla en el momento en que el agente escribe la línea, con 0,28 reglas incumplidas por ticket, y eso es lo que hace VibeDefend. Aun así, lo que el auditor acepta como evidencia es la comprobación que se ejecutó sobre el cambio y el registro que dejó.

¿Cómo demuestras qué código ha escrito un agente?

Tu historial de git dice qué código escribió un agente, si deja rastro. Claude Code marca por defecto cada commit con un trailer Co-Authored-By que nombra el modelo, y un ajuste lo quita. El 27 de octubre de 2026 lo llevaban 467 de los 494 commits de los 90 días anteriores en la rama principal del repositorio de nuestra web.

Para contarlos lanzamos dos comandos en ese repositorio:

git log origin/main --since=2026-07-29 --no-merges --format=%H | wc -l
git log origin/main --since=2026-07-29 --no-merges -i --grep="Co-Authored-By: Claude" --format=%H | wc -l

Los trailers nombran cinco modelos distintos de Claude a lo largo del periodo, así que el historial dice qué modelo escribió cada cambio, y los otros 27 commits no llevan ningún trailer. La referencia de ajustes explica de dónde sale: por defecto, Claude Code añade Co-Authored-By: <name> <noreply@anthropic.com>, donde el nombre es el del modelo en uso, y poner attribution a false lo oculta. Un rastro que cada desarrollador puede desactivar es una convención. Si lo quieres entre tus evidencias, fíjalo en los managed settings que despliega tu organización, y comprueba qué dejan tus otros agentes en los commits y las pull requests, porque cada herramienta lo hace a su manera.

Saber quién es el autor le dice al auditor qué cambios mirar, pero el control en sí es el conjunto de gates por los que pasa cada cambio. Nuestro artículo sobre cómo revisar las pull requests de un agente de IA explica por qué una cuenta de máquina dedicada con commits firmados vale más que una etiqueta que un colaborador puede no poner.

¿Pide SOC 2 lo mismo que la ISO 27001?

SOC 2 pide casi lo mismo que la ISO 27001 con dos criterios. CC8.1 exige que los cambios de software se autoricen, diseñen, desarrollen, documenten, prueben, aprueben e implanten. CC7.1 exige detección y monitorización de vulnerabilidades nuevas, y uno de sus puntos de enfoque es escanear vulnerabilidades. Un informe Type II comprueba luego que esos controles funcionaron durante un periodo.

Los Trust Services Criteria del AICPA están detrás de un login en su web, así que el texto que sigue es el que reproduce la documentación de Wazuh. CC8.1: «The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.» CC7.1: «To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.» Entre los puntos de enfoque (points of focus) que acompañan a cada criterio, CC8.1 incluye «Tests System Changes» y «Approves System Changes», probar y aprobar los cambios del sistema, y CC7.1 incluye «Conducts Vulnerability Scans», hacer escaneos de vulnerabilidades.

La diferencia con la ISO 27001 está en la forma del resultado. ISO certifica un sistema de gestión, con los controles del Anexo A que hayas seleccionado en tu Declaración de Aplicabilidad. SOC 2 es un informe de atestación. En palabras de la firma de auditoría TrustNet, «A licensed CPA gives an opinion on whether your controls are properly designed (Type I) and, if applicable, effectively operating over time (Type II)»: un CPA con licencia opina sobre si tus controles están bien diseñados y, en el Type II, si funcionan de forma efectiva a lo largo del tiempo. Con agentes, un periodo Type II significa registros de cada cambio durante meses, y el auditor los muestrea igual que lo haría un auditor de ISO. Un equipo preparado para una de las dos está cerca de estar preparado para la otra.

¿Qué tienes que tener listo antes de la auditoría?

Antes de la auditoría necesitas una política de desarrollo seguro que nombre a tus agentes, un estándar de codificación segura, un escaneo de cada cambio tras un gate que rechace los hallazgos críticos, un registro de excepciones con aprobador y caducidad, pull requests probadas y aprobadas, y un informe del periodo auditado, todo al día cuando el auditor muestree.

1. La política nombra a los agentes. Qué agentes, con qué cuentas, en qué repositorios, y qué no puede hacer el agente por su cuenta, como fusionar o desplegar.
2. El estándar es corto y se puede hacer cumplir. Enumera lo que prohíbes y apunta a la comprobación que detecta cada punto. Una regla que ninguna comprobación detecta es una regla que solo puede hacer cumplir un revisor.
3. Todos los cambios pasan por el mismo escaneo. Código, dependencias, secretos y archivos de infraestructura, en cada pull request, la abra una persona o un agente.
4. El gate decide y deja constancia. Un hallazgo crítico bloquea el merge; un riesgo menor genera un aviso y el cambio sale. Cada excepción tiene un alcance, una fecha, una justificación y la aprobación de alguien con nombre y apellidos.
5. La aprobación y los tests van con el cambio. La pull request lleva la aprobación, la ejecución de CI y el resultado del escaneo, así que un cambio muestreado se explica solo.
6. El informe cubre el periodo. Un documento que el auditor pueda leer, generado a partir de los escaneos y no copiado de una hoja de cálculo.

Ticket con requisitosEl agente escribe el cambioEscaneo del cambioEl gate bloquea o avisaAprobado y probadoEn el informe

Los puntos 3, 4 y 6 son lo que produce la plataforma AppSec de CybeDefend. Analiza cada repositorio: debilidades del código (SAST), dependencias (SCA), secretos, infraestructura como código, contenedores y pipelines de CI/CD. Una política de seguridad escrita como código bloquea el merge ante un hallazgo crítico y avisa en los riesgos menores, a nivel de organización, de sus equipos y de sus proyectos, y cada excepción se acota a una ruta, lleva fecha, justificación y la aprobación de una persona con nombre, y deja una línea en el registro de auditoría. Los informes de seguridad relacionan los hallazgos con el OWASP Top 10 y el CWE Top 25, por organización, equipo o proyecto, y se exportan en PDF para el auditor, o en HTML o JSON para una herramienta GRC. Si estás preparando la ISO 27001 o SOC 2 con un equipo que programa con agentes, lo vemos juntos. Y para ver en conjunto lo que cambia cuando los agentes escriben el código, empieza por nuestra guía sobre la seguridad de los agentes de código IA.

Preguntas frecuentes

¿Puedo programar con agentes de IA y certificarme en ISO 27001?

Sí. Nada en la ISO/IEC 27001:2022 lo prohíbe, y ninguno de los controles del Anexo A trata de IA. El código que un agente escribe en tu repositorio es tu código, así que los controles 8.25 a 8.29 y el 8.32 se le aplican igual que al código que teclea un desarrollador. Tu política tiene que decir qué agentes están permitidos y cómo se comprueban sus cambios.

¿Es obligatorio el control 8.28 de la ISO 27001?

Para una empresa que desarrolla software, en la práctica sí. La ISO 27001 te deja excluir un control del Anexo A, pero el apartado 6.1.3 d) exige justificarlo en tu Declaración de Aplicabilidad, y excluir la codificación segura mientras escribes código es difícil de defender. Un auditor que no encuentra principios de codificación segura en tu proceso de desarrollo levanta una no conformidad.

¿Qué es una política de codificación segura en la ISO 27001?

Es un documento que fija los principios de programación que siguen tus desarrolladores y tus agentes, y cómo los compruebas. La ISO 27001 no lo hace obligatorio, pero los auditores esperan ver esos principios en algún sitio: dentro de una política de desarrollo seguro si eres una pyme, en una política de codificación segura aparte si eres una empresa más grande.

¿Me vale un CLAUDE.md o un AGENTS.md para pasar la auditoría de ISO 27001?

No. Demuestra que le diste tu estándar al agente, no que el código lo cumpla. Anthropic dice que Claude trata estos archivos como contexto y no como configuración que se impone, y en el estudio de CybeDefend del 24 de agosto de 2026 un archivo de reglas realista dejó 2,27 reglas incumplidas por ticket, frente a 2,28 sin archivo. El auditor quiere registros de comprobaciones que se ejecutaron en cada cambio.

¿Tiene que revisar una persona cada cambio que escribe un agente?

El auditor espera que cada cambio se apruebe antes de llegar a producción: aprobar los cambios del sistema es uno de los puntos de enfoque de CC8.1 en SOC 2, y el 8.32 de la ISO 27001 cubre la gestión de cambios. Tu política decide cómo se aprueban los cambios de los agentes, y el auditor comprueba que las pull requests que muestrea coinciden con lo que dice la política.

¿Necesito la ISO 42001 si mi equipo programa con agentes de IA?

No. La ISO/IEC 42001:2023 es una norma aparte para sistemas de gestión de IA, pensada por ISO para organizaciones que ofrecen o usan productos o servicios basados en IA. La ISO 27001 no la exige, y tu auditor de 27001 evalúa cómo usas los agentes a través de los controles de la 27001.

¿SOC 2 obliga a hacer escaneos de vulnerabilidades?

El criterio CC7.1 pide detección y monitorización que identifiquen vulnerabilidades nuevas, y «Conducts Vulnerability Scans» es uno de sus puntos de enfoque. Los criterios no nombran ninguna herramienta. El auditor prueba los controles que tú has descrito y, en un informe Type II, los prueba durante todo el periodo.

¿Cómo demuestro qué código ha escrito un agente de IA?

Con lo que tus agentes escriben en git. Claude Code añade por defecto a cada commit un trailer Co-Authored-By con el nombre del modelo, y el ajuste attribution puede quitarlo, así que fíjalo en los managed settings. Una cuenta de máquina dedicada con commits firmados es más sólida. La autoría le da al auditor el alcance; las evidencias son los controles por los que pasa cada cambio.