¿Puede una tabla de evidencias SOC 2 demostrar las acciones de los agentes?

La actividad de los agentes crea un problema de auditoría que los registros habituales de una aplicación no resuelven. El registro de una cuenta de servicio puede indicar que una credencial llamó a un endpoint. Normalmente no puede decirte si un proceso de agente concreto tenía autorización en ese momento, si una persona aprobó la acción, si esa autorización se retiró después o si el registro entregado al auditor es el mismo que se generó originalmente.

Un paquete de evidencias SOC 2 útil debe reconstruir una decisión, no limitarse a mostrar una cronología. Para cada acción relevante, el auditor debería poder pasar del actor y la autorización a la llamada, el resultado y la integridad del registro conservado. Si alguna relación depende de la memoria de un administrador o de una hoja de cálculo editada manualmente, el control es más débil de lo que parece.

Sallyport se basa en esa cadena: el agente recibe los resultados de las acciones, mientras las credenciales permanecen en la bóveda local cifrada y la aplicación registra la ejecución del agente y cada llamada individual. Este diseño solo resulta útil cuando conviertes sus registros en evidencias comprobables, en lugar de tratar el diario como un simple elemento decorativo de cumplimiento.

Un control necesita una decisión que pueda reconstruirse

Los Trust Services Criteria de 2017 de AICPA son criterios, no un menú de capturas de pantalla. Los criterios comunes de seguridad piden a la dirección establecer y operar controles que restrinjan el acceso lógico, supervisen el funcionamiento del sistema, respondan a los problemas identificados y gestionen los cambios. El auditor prueba el control descrito, su población y si funcionó durante el periodo examinado.

Esta diferencia importa en el caso de las acciones de los agentes. «El agente necesitaba aprobación» describe un comportamiento del producto. «Cada proceso de agente iniciado debía recibir una autorización atribuible antes de poder usar un canal de acciones protegido, y la empresa conservaba registros que relacionan esa autorización con las llamadas resultantes» es una afirmación de control que puede probarse.

Escribe el riesgo antes de solicitar la evidencia. Una formulación práctica sería:

Un proceso de agente no aprobado o cuya aprobación anterior fue retirada podría invocar una API externa o un comando SSH usando credenciales de la organización, lo que provocaría un acceso no autorizado o un cambio operativo no autorizado.

El control debe responder al riesgo con un lenguaje claro. La evidencia debe responder cinco preguntas más concretas:

1. ¿Qué proceso intentó realizar la acción?
2. ¿Qué autoridad tenía en ese momento?
3. ¿Quién le concedió esa autoridad, si alguien lo hizo?
4. ¿Qué acción externa exacta se produjo después?
5. ¿Puede alguien detectar un intento de reescribir el historial?

Los equipos suelen mezclar estas preguntas. Llaman control de aprobación a una lista de destinos permitidos, registro de autorización a una respuesta correcta de una API o registro inmutable a una exportación que solo puede leerse. Cada afirmación describe algo distinto.

Una restricción de destino limita dónde puede actuar un proceso. Los registros de autorización indican quién permitió que actuara. Los registros de llamadas establecen qué intentó hacer y qué ocurrió. La verificación de integridad indica si se alteró la secuencia conservada. Mantén separadas estas afirmaciones en la descripción del sistema y en la tabla de evidencias. Los auditores no necesitan lenguaje de moda. Necesitan un responsable del control que pueda formular una afirmación delimitada y presentar el registro que la respalda.

La tabla de evidencias SOC 2 que los auditores pueden probar

Usa una tabla de evidencias como acuerdo de trabajo entre ingeniería, seguridad y el auditor. No la conviertas en una lista de funciones del producto. Cada fila debe indicar el riesgo, la actividad de control, la población de origen, el método de prueba y la señal de fallo.

Las referencias a los criterios son puntos de partida, no una promesa de cobertura. La descripción del servicio, la evaluación de riesgos, los límites del sistema y el criterio del auditor determinan la correspondencia final. En particular, no fuerces todos los registros de agentes bajo CC8.1. Los ejemplos y las guías de AICPA tratan la gestión de cambios como el control de las modificaciones de los programas de aplicación y de la tecnología relacionada. Una llamada que edita una cuenta de cliente, envía una respuesta de soporte o reinicia un proceso remoto es una acción operativa. Solo se convierte en evidencia de gestión de cambios cuando forma parte de un cambio aprobado y probado del propio sistema.

La tabla también evita un fallo habitual durante la semana de auditoría: recopilar un artefacto perfecto de un solo día. Un examen de tipo 2 pregunta si los controles declarados funcionaron eficazmente durante todo un periodo. La columna de población no es burocracia. Te indica qué universo completo debes poder producir antes de que alguien extraiga una muestra.

La aprobación de sesión demuestra la autoridad del proceso, no la gestión de identidades

La aprobación por sesión demuestra que una ejecución concreta de un agente recibió permiso para usar la puerta de enlace de acciones. No demuestra que la empresa gestionara correctamente el acceso de sus empleados, aprovisionara bien una cuenta del proveedor de identidad o revisara un rol de administrador en la nube. Esas cuestiones necesitan sus propios controles y registros.

La afirmación útil es más limitada. La primera llamada protegida de un proceso nuevo recibe una decisión de aprobación antes de que la sesión pueda actuar. El registro debe conservar un identificador de sesión, la identidad del proceso, la autoridad de firma de código cuando esté disponible, la hora de la decisión, la identidad del aprobador y el estado de terminación. En Sallyport, la tarjeta de aprobación muestra primero la autoridad de firma de código del proceso, de modo que la decisión humana se refiere al ejecutable que solicitó el acceso, no a una etiqueta imprecisa proporcionada por el agente.

Es una diferencia importante. Un agente puede llamarse como quiera en una instrucción, en el título de una terminal o en un argumento del proceso. Un control que aprueba un nombre declarado por el propio agente invita a un bypass sencillo. Un control que muestra la autoridad de firma de código ofrece al revisor un atributo estable que puede evaluar. No elimina la necesidad de confiar en el software firmado, pero describe el límite de confianza con honestidad.

Para probar la aprobación de una sesión, pide al auditor que seleccione una muestra de la población de sesiones y rastree cada registro en ambas direcciones:

• Empieza con la aprobación de la sesión y encuentra la primera llamada protegida que la siguió.
• Empieza con una entrada de actividad y encuentra la sesión que la autorizó.
• Confirma que la hora de la llamada queda después de la aprobación y antes de la salida o revocación de la sesión.
• Confirma que las sesiones denegadas no tienen llamadas protegidas correctas.
• Confirma que el registro de sesión identifica el proceso con la solidez exigida por el control declarado.

No dependas de una captura de pantalla del diálogo de aprobación. Las capturas sirven para documentar el diseño del control, pero no son evidencia de población. El registro debe seguir disponible cuando se cierre el diálogo, poder consultarse por identificador y relacionarse con el registro de actividad sin que una persona tenga que decidir qué fila parece correcta.

Evita también afirmar que la aprobación de sesión aplica el mínimo privilegio si no es así. Una decisión de sesión puede controlar si un proceso puede actuar. El mínimo privilegio depende de las credenciales, el alcance de los destinos, las operaciones y los permisos disponibles después de la aprobación. Si un agente aprobado puede usar una credencial con derechos de producción sin restricciones, la aprobación es una barrera, no una reducción del alcance. Descríbela de ese modo.

La aprobación por llamada es para acciones que no puedes agrupar con seguridad

Un control de aprobación por llamada ofrece una garantía distinta de la aprobación de sesión. Solicita una decisión humana nueva justo cuando está a punto de utilizarse una credencial concreta. Úsalo para acciones cuyo riesgo está en la invocación individual, no solo en permitir que un proceso de agente empiece a trabajar.

Entre los buenos candidatos están las credenciales de producción que pueden modificar derechos de acceso, eliminar datos, cambiar información de facturación, publicar un despliegue o ejecutar comandos contra un host especialmente sensible. El objetivo no es volver tediosa cada acción del agente. Es situar la revisión en el límite de la transacción, donde un solo uso indebido tendría consecuencias.

La evidencia debe vincular la aprobación con un único uso. Un registro de actividad sólido contiene, como mínimo:

• Un identificador único de llamada y el identificador de sesión asociado.
• La referencia a la credencial protegida, sin incluir su secreto en el registro.
• El canal, el destino, la operación y la marca de tiempo.
• El estado de la decisión y el aprobador cuando la llamada necesitaba aprobación.
• El resultado, incluido un resultado denegado, fallido o completado.

No aceptes un registro de aprobación que simplemente aparezca cerca de una acción posterior. La proximidad temporal no crea una relación. Si un revisor aprueba la llamada A y el agente ejecuta la llamada B con la misma credencial, la evidencia debe mostrar si B necesitaba y recibió una aprobación independiente.

Aquí los equipos suelen reaccionar en exceso. Colocan a una persona delante de acciones rutinarias de lectura y los revisores aprueban una secuencia de tarjetas casi idénticas sin mirar. El control sigue generando registros, pero la revisión se ha vuelto ceremonial. Reserva la aprobación por llamada para la clase limitada de credenciales o acciones que realmente la merecen. Usa la aprobación de sesión para el trabajo normal y reduce por separado el alcance de las credenciales.

El revisor necesita contexto suficiente para decidir. En una acción HTTP, normalmente eso significa el método, el destino, la identidad de la credencial y una descripción segura del efecto de la solicitud. En SSH, significa la identidad del host y el comando, o una descripción de comando restringida. Nunca pongas el secreto en la carga de aprobación solo para enriquecer la evidencia. Un secreto mostrado a un revisor en una tarjeta de aprobación sigue estando expuesto.

La revocación debe generar una denegación que puedas demostrar

La evidencia de revocación no sirve si solo registra un evento de la interfaz. El control funciona cuando termina la autoridad y un intento posterior falla por ese motivo.

Haz esta prueba antes de que el auditor la solicite. Inicia una sesión con permiso para usar una acción de prueba no productiva. Confirma una llamada correcta. Revoca la sesión mientras el proceso siga ejecutándose. Después, haz que el mismo proceso intente una segunda llamada. Conserva los cuatro registros relacionados: la primera llamada correcta, el evento de revocación, la segunda llamada denegada y el estado de la sesión.

La hoja de trabajo de la prueba puede ser tan sencilla como esta:

Test ID: AGT-REV-01
Session ID: ____________________
First call ID and result: ____________________
Revocation time and actor: ____________________
Second call ID and denial result: ____________________
Reason shown for denial: ____________________
Reviewer and date: ____________________

El orden es el control. Un evento de revocación a las 14:03 seguido de una llamada correcta a las 14:07 es un fallo, un problema de reloj o una señal de que el identificador de sesión no significa lo que afirmaste. Ninguna de esas situaciones merece una explicación improvisada.

Trata de forma distinta la salida normal de una sesión y la revocación explícita. La salida termina un proceso porque dejó de ejecutarse. La revocación termina la autoridad porque un revisor decidió retirarla. Ambas deben bloquear las llamadas posteriores, pero solo la revocación demuestra que una persona puede terminar una ejecución activa ante una sospecha. Mantén separados los tipos de evento en la tabla de evidencias.

Este control también debe formar parte de la práctica de respuesta a incidentes. Si un revisor detecta una secuencia sospechosa de llamadas, debe saber quién puede revocar la ejecución, cuánto tarda en aplicarse la denegación y dónde aparece el evento en el diario. Un procedimiento escrito que diga «deshabilitar el agente» sin nombrar la acción concreta no basta cuando el agente ya está ejecutando trabajo.

La verificación sin conexión prueba el historial cuando la aplicación ya no está presente

Un diario de actividad proporciona responsabilidad. Una cadena de hash verificable de forma independiente permite comprobar si la secuencia conservada sigue encajando. Son elementos relacionados, pero no intercambiables.

Sallyport proyecta las vistas de sesión y actividad a partir de un registro de auditoría cifrado, de solo escritura, en el que ambas se basan. El comando sin conexión sp audit verify comprueba la cadena sobre el texto cifrado y no necesita acceso a la bóveda. Es una evidencia útil porque el verificador puede probar el historial conservado sin pedir al sistema que generó el informe que descifre credenciales o conceda acceso a su bóveda.

No exageres lo que demuestra. La verificación de una cadena de hash puede detectar un registro ausente, reordenado o alterado dentro del alcance verificado, según el diseño de la cadena y el material conservado. No demuestra que la aplicación haya emitido todos los eventos que deberían haber existido. Tampoco demuestra que la fuente temporal fuera exacta, que el aprobador tomara una buena decisión o que la API externa subyacente hiciera lo que afirmaba. Son preguntas de control distintas.

Conserva un registro de verificación para un intervalo definido. Este formato de documento de trabajo basta para muchos equipos:

{
  "verification_id": "audit-2026-07-15-01",
  "period_start": "2026-07-01T00:00:00Z",
  "period_end": "2026-07-14T23:59:59Z",
  "command": "sp audit verify",
  "verifier_version": "record the installed version",
  "source_archive": "encrypted audit export identifier",
  "result": "pass or fail",
  "performed_by": "reviewer identity",
  "exceptions": []
}

No inventes un resultado correcto después de una verificación fallida. Registra el fallo, conserva el material, determina si se debió al manejo de la exportación, a la conservación, a un defecto de software o a una posible alteración, y tramítalo mediante la gestión de incidentes. Un fallo de integridad no es automáticamente una brecha. Es un evento que requiere investigación porque tu cadena de evidencias ha dejado de ser fiable.

Ejecuta la verificación con una frecuencia que corresponda al volumen y al riesgo de la actividad de los agentes, y repítela antes de preparar las evidencias. Un trabajo mensual puede ser suficiente para un entorno pequeño. Un equipo que permite a los agentes operar sistemas de producción todo el día no debería esperar hasta el final del trimestre para descubrir un problema de integridad. La frecuencia importa menos que poder demostrar que se ejecutó de forma constante y que alguien gestionó los fallos.

Las acciones operativas y los cambios del sistema necesitan pruebas distintas

Este es el límite que más se difumina. Una acción de un agente puede cambiar algo. Eso no la convierte en un cambio controlado del sistema para CC8.1.

Considera tres ejemplos. Un agente usa una API para modificar el estado de suscripción de un cliente. Es una operación de negocio y necesita autorización, trazabilidad y, quizá, revisión. Un agente edita un archivo de infraestructura en un repositorio de código fuente, la solicitud de incorporación recibe revisión, las pruebas pasan y una canalización de despliegue la aplica. Eso es un cambio del sistema. Un agente ejecuta un comando SSH que edita directamente un archivo de configuración de producción. Es una acción operativa de riesgo elevado y probablemente infringe el proceso de cambios si tu política exige despliegues revisados.

El paquete de evidencias debe hacer visibles estas rutas, en vez de obligar al revisor a inferirlas a partir de la prosa. Añade una clasificación de acción al registro de actividad o al análisis de evidencias:

CC8.1 espera que la dirección autorice, diseñe, desarrolle o configure, documente, pruebe, apruebe e implemente los cambios en infraestructura, datos, software y procedimientos. Un diario de agente puede enriquecer esa historia mostrando que un agente abrió una solicitud de incorporación o invocó una acción relacionada con un despliegue. No puede sustituir la revisión, las evidencias de prueba ni el registro de despliegue.

Esto resulta incómodo porque un único registro de auditoría parece capaz de responder a todas las preguntas. No puede. Conserva el rastro de actividad del agente como registro de la acción delegada. Conserva los registros de cambios de ingeniería como prueba de que los cambios del sistema siguieron el proceso exigido. Relaciónalos solo cuando el agente haya participado en ese proceso.

Construye el paquete de evidencias a partir de una población, no de una carpeta de capturas

Construye un paquete repetible para cada periodo de revisión. La primera tarea es definir la población. Para la actividad de los agentes, normalmente incluye todas las sesiones, todas las llamadas protegidas, todas las denegaciones de llamadas, todas las revocaciones y todas las ejecuciones de verificación de registros del periodo. Si no puedes proporcionar recuentos o una exportación completa, no puedes afirmar de forma creíble que el auditor seleccionó la muestra de toda la población.

Después prepara un pequeño manifiesto de evidencias que apunte a artefactos de origen inmutables o conservados. No subas una pila de archivos con nombres como final-final-auditoria. Usa identificadores estables, ubicación de origen, periodo, responsable y una nota que explique qué demuestra el artefacto.

Un revisor puede seguir esta secuencia:

1. Obtén las poblaciones de sesiones y actividades del periodo, junto con los registros de verificación de integridad.
2. Concilia el número de identificadores de sesión referenciados por las entradas de actividad con la población de sesiones y luego investiga los registros no coincidentes.
3. Selecciona muestras de sesiones aprobadas, intentos denegados, llamadas sensibles, revocaciones y distintos intervalos temporales.
4. Rastrea cada llamada seleccionada hasta su autorización y hacia delante hasta su resultado. Después inspecciona el registro de verificación que cubre el intervalo conservado correspondiente.
5. En el caso de cambios en la puerta de enlace o en controles de producción relacionados, rastrea por separado la solicitud de incorporación, las pruebas, la aprobación y el registro de despliegue pertinentes.

Esta secuencia revela rápidamente las deficiencias. Si una llamada no tiene sesión, falló la relación con la autorización. Si una sesión no tiene identidad de proceso, no puedes probar la afirmación sobre el proceso. Si una revocación no tiene una prueba de denegación posterior, solo sabes que alguien pulsó un botón. Si los registros de verificación cubren un archivo que no puede reproducirse, la afirmación de integridad es débil.

Conserva las notas del revisor junto con la muestra. Una nota breve como «El ID de llamada 54b coincide con el ID de sesión 12a; el empleado A aprobó la sesión; se requería y estaba presente la aprobación por llamada; el resultado de la actividad fue completado; la verificación del intervalo de auditoría fue correcta» es más útil que diez capturas de pantalla. Indica qué se probó y deja un rastro cuando cambie el control.

Las evidencias fallan cuando los responsables no pueden explicar las excepciones

Incluso la mejor tabla de evidencias falla si nadie es responsable de la ruta de excepciones. Las acciones de los agentes serán denegadas. Las solicitudes de aprobación caducarán. Las llamadas fallarán en el endpoint remoto. Las sesiones serán revocadas. La verificación puede informar de un problema. Esos resultados deben aparecer en la población y el equipo debe saber cuáles requieren una acción.

Define un conjunto moderado de categorías de excepción: intento no autorizado, rechazo de aprobación, fallo de acción remota, intento posterior a una revocación, relación de registros ausente y fallo de verificación. Asigna un responsable, una frecuencia de revisión y un registro esperado a cada categoría. No conviertas cada solicitud de API denegada en un incidente de seguridad. Varias denegaciones de un proceso firmado inesperado probablemente merecen más atención que un ingeniero que rechaza su propio comando experimental.

La prueba útil es comprobar si alguien puede explicar una excepción seleccionada sin reconstruir una historia a partir de mensajes de chat. El registro de actividad debe indicar el motivo inmediato. El registro de sesión debe identificar la ejecución. El seguimiento debe indicar si el equipo aceptó el resultado, corrigió la configuración, revocó el acceso o inició la gestión de un incidente.

Aquí también los cambios de control necesitan disciplina. Si modificas el comportamiento de las aprobaciones, las marcas de las credenciales, los campos de registro o el procedimiento para verificar los registros conservados, trátalo como un cambio del entorno de control. Actualiza la descripción del control, prueba el nuevo comportamiento y registra el despliegue mediante el proceso de ingeniería existente. De lo contrario, tu tabla de evidencias describirá el sistema del trimestre pasado mientras los agentes de este trimestre utilizan otra cosa.

No esperes a que el auditor te diga si las evidencias están conectadas. Elige esta semana una sesión real, rastrea el recorrido desde la autorización hasta el resultado de la llamada, revócala en un entorno seguro y verifica sin conexión el intervalo de auditoría conservado. Si tu equipo no puede completar el ejercicio con los registros ya disponibles, corrige la ruta de evidencias antes de discutir la redacción del control.