Ad Actum
Revisión Enfocada
EN Solicitar revisión
00  /  Ad Actum · Revisión Enfocada

Tu agente entregó el cambio.
Ad Actum revisa su efecto sobre el resto del sistema.

Revisiones enfocadas de arquitectura, confiabilidad y seguridad para equipos que usan desarrollo asistido por IA. Definimos un alcance claro, analizamos los efectos en el sistema y entregamos hallazgos priorizados, un plan de remediación y, cuando forma parte del alcance, un pull request para revisión.

Solicitar una revisión acotada Ver un hallazgo de ejemplo →

Acceso anticipado · Acceso limitado al repo · NDA bajo solicitud · Integración controlada por tu equipo

Crítico · Acceso entre proyectos
Hallazgo de seguridad representativo

La autenticación validaba al usuario, pero no la propiedad de los datos.

Radio de impacto
Múltiples endpoints · lectura, escritura y eliminación entre proyectos
Causa raíz
Los recursos padre verificaban la propiedad. Los servicios de recursos hijos consultaban por ID sin limitarse al proyecto.
Remediación de ejemplo
Validación centralizada de propiedad + consultas limitadas por proyecto, contenidas en un pull request revisable.
Ejemplo representativo. Los identificadores y el alcance son ilustrativos.
01  /  El problema

Los agentes de programación se concentran en el cambio solicitado.
La responsabilidad sobre el sistema sigue siendo del equipo.

Un cambio puede cumplir el pedido inmediato y pasar las pruebas disponibles, pero aun así debilitar un límite de propiedad, duplicar lógica de ciclo de vida o complicar la limpieza y la recuperación. Son riesgos habituales del software; una entrega más rápida vuelve más importante la revisión cuidadosa del sistema.

Cada sesión de programación tiene un contexto limitado sobre las decisiones y los cambios anteriores.

El flujo que produjo un cambio puede no revelar sus efectos fuera del alcance inmediato.

Ad Actum agrega una revisión enfocada de esos efectos sobre el sistema.

02  /  Revisar · Planificar · Implementar

Evidencia en el código, un plan de remediación acotado e implementación opcional.

Cada trabajo comienza con un alcance definido. Los hallazgos se vinculan con el código y documentan su impacto y sus limitaciones. Cuando la implementación está incluida, los cambios se entregan como un pull request para revisión.

Revisar

Hallazgos priorizados

Rutas relevantes, comportamiento observado, impacto y limitaciones. Cada hallazgo se respalda con evidencia en el código.

Planificar

Plan de remediación acotado

Los hallazgos confirmados se convierten en pasos concretos con criterios de aceptación y un límite de implementación claro.

Implementar

Pull request para revisión

La implementación puede incluirse en el alcance. Tu equipo revisa el pull request resultante y decide qué integrar.

03  /  Tres estudios

Elige el área
que quieres revisar.

Estudio 01

Ad Actum War Room

Una revisión enfocada de arquitectura y ciclo de vida que cubre propiedad, acoplamiento, límites entre módulos, código muerto y puntos críticos estructurales.

  • Puntos débiles estructurales documentados
  • Acoplamiento riesgoso y brechas de propiedad examinados
  • Límites entre módulos y código muerto hechos explícitos
  • Una ruta de remediación acotada, con implementación disponible
Solicitar una revisión acotada
Estudio 02

Ad Actum Investigación de Confiabilidad

Una investigación enfocada de errores activos, condiciones de carrera, estado obsoleto, integridad de datos, limpieza y recuperación.

  • Fallas activas de correctitud reproducidas cuando es posible
  • Condiciones de carrera y estado obsoleto trazados a través del flujo relevante
  • Brechas de integridad de datos y recuperación documentadas
  • Implementación disponible dentro del alcance acordado
Solicitar una revisión acotada
Estudio 03

Ad Actum Auditoría de Seguridad

Una revisión enfocada de autorización, límites de confianza, manejo de secretos, controles que fallan de forma abierta y rutas concretas de ataque.

  • Rutas de autorización y propiedad trazadas de extremo a extremo
  • Rutas exentas comparadas con los controles centrales de seguridad
  • Controles fail-open y transporte de secretos examinados
  • Rutas concretas de ataque documentadas dentro del alcance
Solicitar una revisión acotada
04  /  Hallazgos representativos

Arquitectura, confiabilidad y seguridad.
Tres ejemplos del nivel de detalle.

Estos ejemplos representativos muestran cómo un hallazgo conecta el comportamiento observado, su impacto y una ruta de remediación acotada. Los identificadores y el alcance son ilustrativos.

Confiabilidad · Falla de limpieza/recuperación
Alta · Datos huérfanos

Un registro de análisis quedaba fuera de la limpieza del cambio.

El registro no tenía un identificador de proyecto ni de solicitud de cambio, por lo que la limpieza canónica no podía alcanzarlo. Los análisis completados dejaban registros huérfanos.

Remediación de ejemplo: agregar campos de propiedad e incluir la colección en la limpieza canónica.

Seguridad · Límite de propiedad
Crítico · Acceso entre proyectos

La autenticación pasaba; la propiedad de los datos no.

Los recursos padre verificaban la propiedad, pero las consultas de recursos hijos usaban IDs sin limitarse al proyecto. Un usuario autenticado podía acceder a datos fuera de su proyecto desde múltiples endpoints.

Remediación de ejemplo: centralizar la validación de propiedad y limitar las consultas por proyecto.

Seguridad · Desvío de transporte de tokens
Alta · Exposición de credenciales

Un endpoint rechazaba tokens en la URL; otro los aceptaba.

Un endpoint con secreto compartido rechazaba tokens en los parámetros de consulta, mientras que un endpoint privilegiado de contenido multimedia los aceptaba. Los tokens podían filtrarse a través del historial del navegador, logs de proxy o encabezados de referencia.

Remediación de ejemplo: usar autenticación Bearer y rechazar tokens en los parámetros de consulta.

Ver un hallazgo de ejemplo →
05  /  Cómo funciona

Cuatro pasos, una entrega clara.

01

Aplica

Cuéntanos sobre el repositorio, subsistema, cambio o área de riesgo que quieres revisar.

02

Alcance

Acordamos un área acotada, el acceso necesario y las preguntas que debe responder la revisión.

03

Revisión

Trazamos el comportamiento relevante a través del código, documentamos los hallazgos y registramos las limitaciones materiales.

04

Entrega

Recibes los hallazgos y el plan de remediación. Si se incluye implementación, tu equipo revisa el pull request y decide qué integrar.

06  /  Custodia del código

Nos das acceso a tu repo.
Lo tratamos así.

El acceso al repositorio se limita al alcance acordado, los secretos quedan fuera salvo que sean necesarios y tu equipo conserva el control sobre cada cambio.

  • ▸ Acceso al repositorio limitado a los repositorios y al alcance acordados.
  • ▸ NDA disponible bajo solicitud antes del acceso.
  • ▸ Sin necesidad de acceso amplio a producción.
  • ▸ Los secretos quedan fuera salvo que estén explícitamente en alcance.
  • ▸ Tu equipo conserva el control de revisión e integración.
  • ▸ Limitaciones materiales documentadas junto con los hallazgos.
07  /  Una nota del fundador

Creé Ad Actum a partir de una idea sencilla: producir un cambio más rápido no hace que sus consecuencias sean más fáciles de entender.

Ad Actum revisa una parte definida de la base de código, documenta los riesgos que pueden respaldarse con evidencia y propone pasos concretos. Cuando la implementación forma parte del alcance, el trabajo se entrega como un pull request para que el equipo lo revise.

El objetivo no es sustituir el criterio del equipo de ingeniería, sino facilitar la comprensión y la revisión de cambios difíciles.

Andrés Murillo · Fundador
08  /  Solicitar una revisión

Empieza con un repositorio, subsistema,
cambio o área de riesgo concretos.

Cuéntanos qué cambió o qué se ha vuelto difícil de analizar. Definiremos un alcance de revisión acotado antes de comenzar.

Acceso anticipado · alcance definido tras revisión. NDA disponible. Secretos fuera del alcance salvo que estén explícitamente incluidos.

Solicitar una revisión acotada

Cuéntanos qué quieres revisar y por qué importa.

URL del repoResponsable de ingenieríaPreocupación principal

Emails de trabajo y URLs de repo nos ayudan a definir alcance más rápido. Puedes compartir un repo privado después del NDA si es necesario.