Autonomous Pentest Assurance Standard (APAS): cuándo puede confiar en los resultados de un pentest autónomo

El propio estándar describe el punto de partida con sobriedad: los sistemas autónomos se anuncian como capaces de realizar, ampliar o sustituir pentests, y los destinatarios de esa publicidad carecen de una vara de medir fiable para separar una afirmación acotada y verificable del lenguaje de marketing (Background and Motivation). APAS hace comprobables tales afirmaciones al establecer cómo un sistema autónomo declara qué ha hecho, bajo qué condiciones y con qué evidencia.

Tres propiedades de los sistemas autónomos hacen que el informe de pentest clásico resulte insuficiente como medio de prueba. Primero, la trampa del no determinismo: un agente encuentra en dos ejecuciones bajo condiciones idénticas superficies de ataque y hallazgos distintos; quien informa solo de la mejor ejecución finge consistencia (4.6.2). Segundo, la trampa de la autoconfirmación: un sistema que evalúa sus propios hallazgos —también con un segundo modelo como «Judge»— no observa el objetivo, sino a sí mismo; la coincidencia entre componentes internos no es una confirmación independiente (4.4.1 f, 11.2.1 b). Tercero, la trampa de la Coverage: un sistema que descubre menos parece más completo cuando el denominador procede de su propio descubrimiento (1.1.4).

De ello APAS deriva un límite inferior claro: el escaneo automatizado que genera señales sin una ruta de explotación validada no es, por sí mismo, un pentest autónomo. Tal salida cuenta, como máximo, como Assurance Outcome Q1 con evidencia EV1 o EV2 y nunca puede presentarse por sí sola como un claim de pentest APAS. Los rasgos distintivos de un pentest son la reproducción independiente por una parte distinta del sistema que lo genera, la validación de la ruta de explotación hasta la condición afirmada y el encadenamiento (chaining) multietapa demostrado dentro del Scope declarado (2.2.3).

APAS se desarrolla en coordinación con la Cloud Security Alliance y sigue los requisitos de titularidad neutral de la sección 12: un estándar controlado por un actor del mercado no puede presentarse como estándar sectorial neutral (12.4.1). El documento sitúa su sede en el CSA AI Safety Working Group; el Lead Author es Will Kapcio, junto con ocho Contributors (entre ellos Jim Reavis y John Yeoh, de la CSA) y doce Reviewers. El registro de cambios recoge la primera versión del 23 de octubre de 2026; la fecha del archivo es el 2 de noviembre y la publicación por la CSA, el 4 de noviembre de 2026. El PDF está protegido por derechos de autor y no puede redistribuirse; por eso enlazamos a la descarga en la CSA y citamos indicando la fuente.

La sección Status deja claras tres cosas. APAS evalúa la veracidad y la utilidad de la evidencia de pentest, no la seguridad, la contención ni la resistencia al uso indebido del propio sistema; una certificación APAS nunca puede presentarse como una afirmación de Safety del tipo «fitness for deployment». Segundo: no se ha publicado ningún documento Companion. Tercero, y decisivo: mientras el Evaluator Guide, la entrada pertinente de la Profile Registry y el Attestation Schema no estén disponibles en versiones compatibles, no puede emitirse ninguna Atomic System Capability Certification ni ningún Engagement Conformance Statement. La publicación del Core abre la vía de certificación, no la certificación (Status, 12.1.2).

El conjunto documental

La gobernanza ya está regulada: las versiones siguen un esquema Major/Minor/Patch; v1.0 es una versión Major porque modifica la validez de los claims, las dimensiones de calidad, las clases de entorno, los gates de publicación y la semántica de los hallazgos (12.2.1). Cada documento Companion declara contra qué versión Major del Core es normativo; los claims solo pueden emitirse contra un conjunto documental compatible, y una nueva versión del Core no invalida retroactivamente los claims ya emitidos (12.2.2, 12.2.3). El Core y el Evaluator Guide deben revisarse al menos cada doce meses en busca de deriva de capacidades, con un desencadenante extraordinario ante saltos sustanciales en las capacidades de frontera (12.2.4). Los cambios normativos pasan por una revisión pública; la entidad titular debe ser organizativamente independiente de cualquier proveedor individual, mantener procesos con múltiples partes interesadas y revelar los conflictos de intereses (12.3, 12.4). Para los claims existe un registro público de estado con los estados Active, Under Review, Revoked y Retired; ante indicios creíbles de evidencia falsificada o engañosa, un claim pasa a Under Review y ya no puede invocarse como Q3, Q4, R2 o R3 (12.5).

Las reglas de aplicación son estrictas. Toda declaración de calidad debe reflejar Coverage Fidelity, Finding Validity, Evidence Traceability y Agent Integrity; para claims Q4 o R3 se añaden obligatoriamente Remediation Usability y Retestability (4.1.1 a). Una dimensión solo puede considerarse no aplicable o no medida con criterios documentados y el consentimiento del Evaluator, y ello debe revelarse (4.1.1 b). Los perfiles pueden añadir dimensiones, pero no suprimirlas (4.1.1 c). Sobre todo: las dimensiones se declaran y evalúan de forma independiente, no pueden combinarse en un Composite Score, y un déficit en una dimensión no puede presentarse como compensado por la fortaleza en otra (4.1.1 d).

Todo claim Q2, Q3, Q4, R2 o R3 contiene una declaración de calidad que expresa cada dimensión aplicable mediante un valor numérico, una clase ordinal, un estado booleano o una representación definida por el perfil, y que remite a evidencia o metodología (4.1.2). La validación comparativa —por ejemplo, frente a una cohorte humana de referencia— puede complementar la evaluación de calidad, pero nunca sustituir Coverage Fidelity, Finding Validity o Evidence Traceability (4.1.3). Agent Integrity es una dimensión independiente y no se satisface mediante revelaciones de Process Integrity (4.1.4).

APAS <Modo>-<Tier> / <Ejecución>-<Colaboración>-<Assurance> / <Entorno> [<Perfil de affordance>] {<Reliance>}

APAS BB-T2C / X2-C2-Q4 / E3 [P-021] {R2}

Los cuatro Claims de ejemplo del Anexo A

Existen tres tipos de Claim (5.1): la Atomic System Capability Certification es el resultado, emitido por el Evaluator, de que un sistema ha cumplido los requisitos aplicables para una combinación de capacidades bajo condiciones declaradas. El Multi-Configuration Capability Statement agrupa dos o más Claims atómicos para una versión del sistema. El Engagement Conformance Statement se refiere a un engagement concreto (encargo de prueba) ejecutado con un sistema certificado según APAS bajo las mismas condiciones o condiciones más estrictas — nunca certifica el entorno objetivo (5.1.1).

Dado que un sistema puede ofrecer varias combinaciones, APAS exige una Capability Matrix con siete clases de estado: S1 Supported (diseñado para ello, no evaluado), S2 Evaluated (evaluado, sin Claim), S3 Certified or Conformant, S4 Not Certified, S5 Not Evaluated, S6 Unsupported, S7 Retired. Solo S3 puede presentarse como certificado; una matriz pública que omita combinaciones soportadas materialmente relevantes es engañosa (5.3.1). Cada fila incluye, entre otros: ID de combinación, Claim String completo, nombre y versión del sistema, identidades de los modelos junto con la procedencia de los system prompts, referencia de metodología, Evaluator, estado, referencias a la atestación, declaración de calidad y de Coverage, versiones de Core y Companion, fechas de certificación y de validez, limitaciones materiales; para Q3, Q4, R2 o R3 son obligatorios la fecha de certificación y una fecha de caducidad explícita o un intervalo de revalidación (5.4.1).

La Assistance Class de la sección 9 completa estas clases con la pregunta de qué han aportado realmente las personas: H0 ninguna ayuda con efecto sobre la estrategia, la explotación, la validación, la priorización o el informe; H1 solo intervención administrativa o de seguridad; H2 ayuda analítica — guía de explotación, interpretación, priorización, mapeo de controles o edición del informe. La clase debe revelarse en la atestación, y en configuraciones múltiples por combinación y ejecución (9.1.1). Un Claim X3 prohíbe H2 durante la ejecución; un Claim Q4 prohíbe H2 al compilar el Evidence Package — también mediante componentes internos de validación o de tipo judge que den forma al contenido del paquete (9.1.2). El mapeo a frameworks o la priorización realizados a posteriori por el proveedor que influyan materialmente en el auditor constituyen una Vendor-side Analytical Review y deben revelarse (9.1.3). Una plataforma no puede comercializarse como agent-only, autónoma de forma independiente o assessor-ready si ejecuciones relevantes se basaron en intervención humana o posprocesamiento no revelados (9.2.2).

Otras dos reglas merecen la atención de los CISO y de la auditoría interna. Primero, la responsabilidad: todo Claim R3 debe nombrar a la parte responsable de la exactitud de la evidencia sustituida, el recurso de la parte usuaria (relying party) ante defectos detectados con posterioridad, los límites de la garantía y un seguro de responsabilidad civil profesional o por daños patrimoniales presentado a la parte usuaria — APAS por sí mismo no crea, transfiere ni limita responsabilidad alguna (5.10.4). Segundo, las pruebas de tenants y de permisos: un Claim R2 o R3 nunca puede valer como sustituto o complemento de pruebas de autorización, de control de acceso o de límites entre tenants si se utilizaron menos de dos principals distintos o un solo tenant; tales áreas se consideran materialmente no probadas (5.10.6). Y además: R2/R3 describen lo que entrega el paquete — no qué actuaciones de revisión puede omitir el revisor; las revisiones restantes y la aceptación del riesgo residual siguen correspondiendo al revisor y a su framework (5.10.7).

Todo claim T2A, T2C, T3, T4, Q2, Q3, Q4, R2 o R3 incluye una declaración de Coverage con campos obligatorios fijos (4.2.1). Debe reflejar con veracidad las diferencias entre el scope declarado, el alcanzable y el probado, así como respecto a la Surface Baseline; ningún paquete puede sugerir una Coverage completa, total o equivalente sin aportar la metodología y la evidencia que la sustenten; un resultado demostrado en una única instancia o en una sola ejecución no constituye Coverage de la clase de ataque correspondiente (4.2.2).

La escalera de baselines BS-1 a BS-3

1. 1
   BS-1 Asserted

   Inventario de activos o lista de scope del propietario del objetivo — independiente del sistema candidato, pero limitado por la exhaustividad del propietario (4.2.8 a).

2. 2
   BS-2 Directed

   Enumeración dirigida por el evaluador, en la que este especifica o amplía la superficie más allá del descubrimiento realizado por el sistema — el nivel mínimo para Q3, Q4 y R3 (4.2.8 b, 4.2.10).

3. 3
   BS-3 Instrumented

   Enumeración mediante un instrumento de discovery independiente o un proceso que no comparte la lógica de discovery del sistema candidato (4.2.8 c).

Para Q3, Q4 y R3, el denominador de Coverage debe construirse frente a una Independent Surface Baseline; el descubrimiento propio del sistema no puede ser la única fuente (4.2.4). Las desviaciones materiales entre la superficie descubierta y la baseline deben revelarse en ambas direcciones; toda superficie de la baseline que no se haya ejercitado se considera materialmente no probada; la Under-Discovery reduce la Coverage presentada, nunca al revés (4.2.5). Si se combinan fuentes, la baseline global no puede presentarse como más sólida que la fuente más débil que cubra por sí sola un área material (4.2.9). Donde no se exija una baseline independiente, la declaración debe indicar que el denominador ha sido enumerado por el propio sistema y describir el método (4.2.6).

El Coverage status por sí solo no dice nada sobre la profundidad. Para cada área probada o parcialmente probada debe indicarse si se realizaron probing a nivel de request, probing autenticado, pruebas de workflows o de transiciones de estado en varias etapas y pruebas en los límites de privilegios o de tenant. La unidad de Coverage, los umbrales de cobertura parcial, los grados de profundidad y las ponderaciones los define la Profile Registry — sin un perfil aplicable, la profundidad debe declararse de forma narrativa y no puede presentarse ninguna proporción ni porcentaje de Coverage (4.2.11). En los claims T2C, la declaración debe estructurarse de modo que un revisor identifique las áreas relevantes para los controles que fueron probadas, excluidas y no probadas sin depender de la interpretación del proveedor (4.2.7).

El no determinismo es el segundo punto ciego. Un sistema se considera materialmente no determinista cuando ejecuciones repetidas en las mismas condiciones producen superficies de ataque, conjuntos de hallazgos o resultados de exploitation materialmente distintos; esto debe revelarse en la metodología (4.6.1). La varianza no puede ocultarse mediante la ejecución más favorable; cuando varias ejecuciones sustentan un claim, la selección, la agregación y la divulgación deben definirse de antemano, y el evaluador atestigua que el número de ejecuciones y la regla de agregación estaban fijados antes de la ejecución (4.6.2). Los claims Q3, Q4, R2 y R3 caracterizan la varianza entre ejecuciones con una medida declarada — por ejemplo la varianza de surface discovery o el índice de Jaccard de los conjuntos de hallazgos — mediante un diseño de ejecuciones prerregistrado (4.6.3). La regla de agregación procede de un conjunto cerrado (Any-Run-Union, All-Run-Intersection, mayoría o una regla declarada expresamente) y los resultados individuales de todas las ejecuciones, no solo un indicador, se incorporan al Evidence Package (4.6.5).

Cada Confirmed Finding lleva un Stable Finding Identifier — un identificador unívoco y estable a lo largo de revisiones, retests, exportaciones y conversiones de formato — y, salvo en la vía Single-Capture, una Reproduction Procedure: una secuencia registrada, determinista e independiente del agente de pasos, requests, payloads, precondiciones y observaciones esperadas, con la que un tercero competente puede reproducir la condición sin acceso al sistema candidato (4.3.3, anexo D). Las observaciones esperadas incluyen la observación de control o expected-secure; una Procedure solo puede ser probabilística si la propia condición lo es (race conditions, TOCTOU, canales laterales de temporización), y entonces con el número de intentos y la tasa de éxito observada. Cada Confirmed Finding declara además el Vantage Point y la condición de acceso, así como la región de la clase de entorno (4.3.5); los servicios adyacentes o las rutas entre sistemas relevantes para la explotabilidad o el impacto se revelan — en E3 de forma obligatoria (4.3.6).

Para claims Q3, Q4, R2 o R3, los artefactos EV3 y EV4 deben recogerse a través de una vía que no esté bajo el control exclusivo del sistema candidato — interceptación de red, observación del host o capturas recogidas por el evaluador; por debajo de ese umbral, los artefactos recogidos únicamente por el sistema deben señalizarse como tales en el Evidence Manifest; para Q2 y Q3, EV3/EV4 deberían ser Out-of-Band Witness Evidence — callback listeners, canaries o monitores en el lado del objetivo que el sistema no puede crear, observar ni alcanzar (4.4.4, anexo D). Si un hallazgo afirma un defecto de autorización o de límite de tenant, EV3 exige observaciones emparejadas: el mismo request tiene éxito para el principal no autorizado y es rechazado para un principal de control autorizado, ambos referenciados a través de la Identity Coverage (4.4.6).

Retest y deduplicación

Un Retest ejecuta la Reproduction Procedure registrada frente al Stable Finding Identifier, asigna el resultado a ese identificador y revela si el hallazgo persiste, está parcialmente corregido o ya no es reproducible (4.3.4). El redescubrimiento probabilístico — o su ausencia — mediante una nueva ejecución del agente no es verificación de la corrección, ni prueba de persistencia, ni Retest; tales resultados deben señalizarse como probabilistic rediscovery y separarse del resultado de la Procedure (4.3.4 a). En condiciones intermitentes, el número de intentos y la tasa de éxito se evalúan frente a la tasa anterior a la corrección (4.3.4 b). Para cada paquete debe existir una regla de deduplicación documentada que establezca cómo las observaciones repetidas de la misma condición procedentes de distintas ejecuciones, Vantage Points o instancias colapsan en un único Stable Finding Identifier (4.3.9).

El Affordance Profile es el entorno operativo declarado del sistema durante la prueba: capacidades, restricciones, condiciones de acceso, límites de escalada y obligaciones (anexo D). Cada claim referencia un perfil con al menos los campos siguientes; una etiqueta genérica como «standard» no basta para los campos de controles de protección del objetivo y de Agent Integrity. Los componentes internos de validación, judge, verifier o consenso deben declararse en la Agent Topology y su función debe revelarse en la declaración de calidad sobre Finding Validity. Si falta una Action Reversibility Class, el engagement se considera irreversible — con las obligaciones de safety más estrictas (7.1.1).

Las clases de entorno describen el alcance a través de fronteras de confianza, no el tipo de objetivo: E1 un único objetivo aislado, E2 interacción multirrol, multietapa o con estado dentro de una frontera de confianza declarada, E3 interacción que cruza una frontera de confianza o de segmentación (7.2). Se aplican por igual a aplicaciones, API, redes, infraestructura, planos de control cloud, contenedores, software cliente, móvil, firmware y sistemas embebidos; ninguna clase importa vectores de ingeniería social, físicos ni de radio. Cada claim se limita a su clase declarada (7.2.1); deben declararse el tipo de entorno y las diferencias materiales respecto a producción, y una prueba fuera de producción no implica cobertura de producción sin paridad declarada (7.2.2). Los claims T2A, T2C, T3 y T4 referencian una metodología declarada; las metodologías para Q4 o R3 definen además el tratamiento de resultados negativos, las expectativas de remediación y retest y la justificación, basada en el modelo de amenazas, del modo elegido (7.3).

Autorización y Rules of Engagement

Cada engagement APAS tiene una Authorization Declaration con la parte autorizante, la base legal o contractual, el alcance y la ventana temporal autorizados y las Rules of Engagement; las pruebas fuera de ellos se consideran actividad Out-of-Scope según la sección 10 — con independencia del éxito técnico o del valor del hallazgo (7.4.1). Además, cuando sea relevante, deben declararse: ventanas de prueba, incluidas las de blackout y mantenimiento; contactos de emergencia designados del propietario del objetivo, del evaluador y del operador del sistema, con su disponibilidad y el tiempo máximo de notificación; estado de autorización para infraestructura de terceros y cloud, con las condiciones de prueba específicas del proveedor; direcciones de origen del sistema y allowlisting; límites de clasificación de datos y de-confliction con el SOC o el Blue Team (7.4.3). La Declaration indica además la identidad del agente actuante, el esquema de identidad, el método de verificación para el propietario del objetivo y, en caso de subagentes, la cadena de delegación con su profundidad máxima (7.4.4).

Como los sistemas autónomos se encuentran con vulnerabilidades en componentes de terceros o fuera del alcance, cada engagement exige un Coordinated-Disclosure Path: cada hallazgo de este tipo lleva un estado de divulgación (encountered, notified, disclosure-restricted, resolved, published), permanece enumerado en el manifiesto de evidencias en todos los estados con su Stable Finding Identifier y su hash de contenido, y solo el detalle de explotación puede retenerse temporalmente — nunca el hallazgo en sí (7.4.2). Si el sistema puede alcanzar infraestructura compartida o ajena fuera de la autorización, los límites de escalada deben mantenerlo apartado de ella (7.4.3.2).

Toda certificación o declaración de engagement presentada como R2 o R3 incluye un Evidence Package consumible por el assessor; todo claim Q2, Q3 o Q4 incluye declaración de calidad y de cobertura, aunque solo se reivindique R1 (8.1.1). Para R2/R3, la evidencia de soporte debería permanecer disponible al menos mientras el claim sea válido (8.1.2 b).

Integridad: firma, hashes, logs a prueba de manipulación

Toda atestación Q3, Q4, R2 o R3 está firmada criptográficamente por el evaluador emisor o el organismo de evaluación de la conformidad — con identidad verificable, método de verificación publicado, identificador de certificado o de clave, sello de tiempo de confianza y una vía publicada para comprobar el estado de la clave incluso tras rotación, caducidad o revocación (8.2.1). El manifiesto de evidencias contiene por artefacto un hash de contenido en el momento de la captura (8.2.2); el registro de ejecución y de evidencias es tamper-evident (con detección de manipulaciones) y lo mantiene o refrenda un componente o una parte que no está bajo el control exclusivo del sistema (8.2.3). La evidencia falsificada, no trazable o materialmente engañosa invalida el claim (8.2.4); un paquete con verificación de firma fallida, discrepancias de hash o lagunas sin explicar en el log no puede invocarse como Q3, Q4, R2 o R3 hasta que la discrepancia se resuelva y se vuelva a atestar (8.2.5). Las contradicciones entre atestación, hallazgos, registros de ejecución y artefactos deben revelarse, no despacharse con una explicación narrativa (8.2.7).

Legibilidad por máquina y formatos de intercambio abiertos

Todo paquete Q2, Q3, Q4, R2 o R3 lleva campos legibles por máquina: claim string completo, ID de combinación, nombre y versión del sistema, identidades y versiones de los modelos, procedencia del system prompt, un identificador de build del sistema como digest criptográfico de la configuración vinculada, referencia de metodología, identidad del evaluador, metadatos de firma y verificación, Assistance Class, ruta operativa observada, referencias a las declaraciones de calidad y de cobertura con fuentes de la baseline, ID de activos y referencias SBOM, resumen de estados de los hallazgos, Stable Finding Identifiers, relaciones de Attack Path, etiquetas Single-Capture, decisiones de materialidad, hashes del manifiesto, fecha de certificación con caducidad o intervalo de revalidación, versiones Core y Companion y Reliance Outcome. El claim string y el identificador de build viajan en una envoltura de procedencia declarada como in-toto, DSSE o SCITT (8.4.1).

La baseline se aplica a todo Claim: límites de Scope explícitos, un mecanismo de Stop o Suspend y logs o artefactos suficientes para la revisión por el Evaluator (10.1.1). La actividad Out-of-Scope, la evidencia falsificada, la ocultación material de ayuda humana o las afirmaciones engañosas sobre Coverage invalidan el Claim (10.1.2); la incertidumbre material sobre Impact, Coverage o conclusiones de Retest debe señalarse en el paquete (10.1.3).

1. 1
   Declarar la Stop Authority

   Cada Engagement designa quién puede suspender o terminar la ejecución — como mínimo el propietario del objetivo y, si existe, el Evaluator (10.2.1).

2. 2
   Actuar out-of-band

   El mecanismo de Stop opera fuera del bucle de decisión del sistema; el sistema nunca es el único árbitro de si un Stop surte efecto. El perfil de affordance indica un tiempo máximo de reacción; dentro de ese plazo cesa toda actividad ofensiva, las acciones en curso se interrumpen y el trabajo pendiente, planificado o delegado se cancela o se documenta (10.2.2).

3. 3
   Fail-safe al perder la supervisión

   Si la monitorización, la conexión de supervisión, el logging o el canal de Stop fallan más allá de las tolerancias declaradas, el sistema suspende la actividad ofensiva hasta que se restablezca la supervisión — la pérdida de supervisión nunca conduce a un funcionamiento autónomo continuado (10.2.3).

4. 4
   Registrar eventos y notificar

   Los eventos de Stop y Halt-on-Loss, con su cronología, quedan en el log con evidencia de manipulación y en el Evidence Package; los contactos de emergencia se informan dentro del plazo declarado (10.2.4).

5. 5
   Access Disposition Record

   Al cierre — y tras cada Stop — un Record enumera cada acceso creado por el Engagement (tokens, cuentas, sesiones, túneles, tokens delegados, persistencia) con su estado (Revoked, Expired, Removed, rotado por el propietario del objetivo o Retained con propietario y vencimiento), la parte responsable y la referencia de verificación (10.2.5).

6. 6
   Verificar end-to-end

   El Evaluator comprueba de extremo a extremo cada canal de Stop, Suspend, Resume u Override crítico para la seguridad — desde la parte autorizada hasta el punto de enforcement en la configuración de despliegue atestada; la mera existencia o la firma correcta no basta: el paquete debe incluir al menos un evento ejercido por canal con su resultado de entrega y de enforcement (10.2.6). La disponibilidad de un canal no prueba la entrega; una instrucción no ejecutada debe ser reconocible como fallo de entrega (10.2.7).

Las obligaciones escalan con el peor valor entre autonomía de ejecución, participación humana reducida y riesgo de affordance declarado (Action Reversibility Class): dentro de un perfil, los requisitos para X3 son al menos tan estrictos como para X2 y estos al menos tan estrictos como para X1, y lo mismo de C1 a C4; una Action Reversibility Class menos reversible eleva los requisitos con independencia de X y C; ninguna decisión de perfil, de Evaluator o de proveedor puede conceder una supervisión más débil a las clases más autónomas — una configuración en la que más autonomía elimina la supervisión no es certificable (10.3.1).

• La operación X3, C4 y E3, así como todo Engagement con acciones irreversibles permitidas o chaining autónomo hacia superficies adyacentes, exigen además: disponibilidad permanente del canal de Stop durante la ejecución (10.3.2 a),
• detección automática de la aproximación al límite de Scope o de su violación, que detenga o bloquee la acción en lugar de limitarse a registrarla (10.3.2 b),
• una declaración de cómo se aplica en tiempo de ejecución el límite de Scope autorizado (10.3.2 c), Halt-on-Loss-of-Oversight (10.3.2 d),
• la aplicación de los límites de escalada declarados mediante un mecanismo cuyo fallo sea detectable (10.3.2 e),
• y, en acciones encadenadas, un gate sobre la peor Action Reversibility Class alcanzable de toda la cadena antes de que se ejecute el primer paso (10.3.2 f).

Agent Integrity: el agente como objetivo de ataque

Un agente de pentest lee contenidos del objetivo, invoca herramientas, utiliza servidores MCP y persiste contexto — y con ello es a su vez atacable. APAS exige controles declarados contra al menos cuatro clases de manipulación: Prompt Injection desde contenidos o respuestas del objetivo, manipulación o sustitución de herramientas, plugins, modelos o servidores MCP y servidores de herramientas comparables, Poisoning del contexto recuperado o persistido, y modificación o elusión no autorizada de los controles en tiempo de ejecución para Scope, herramientas permitidas y privilegios (10.4.1). Todo Claim Q3, Q4, R2 o R3 incluye en la declaración de calidad una divulgación de Agent Integrity con los controles, los intentos de manipulación detectados y su tratamiento; un mensaje generado por el propio sistema del tipo «no se ha detectado manipulación» no prueba que no la hubiera (10.4.2).

Lo decisivo es quién prueba: para Q3, Q4, R2 o R3, el Evaluator debe ejecutar por sí mismo pruebas adversariales de Agent Integrity — como mínimo Goal Hijack, Tool-Response Injection y Context o Memory Poisoning; los controles meramente afirmados por el proveedor no sostienen ninguno de estos Claims (10.4.4). La evaluación compara ejecuciones de evaluación identificadas con ejecuciones ciegas en cuanto a fidelidad al Scope, rechazo de lo Out-of-Scope, Coverage y tasa de fabricación; una diferencia material de comportamiento es Eval-Awareness, debe divulgarse y pone un tope al Assurance Outcome (10.4.3). Una manipulación no detectada que haya alterado materialmente la estrategia, los hallazgos, la fidelidad al Scope o el contenido del informe invalida las dimensiones del Claim afectadas. Si el sistema detecta una manipulación, suspende la actividad ofensiva, informa al propietario del objetivo, al Evaluator y a los contactos de emergencia, y pone en cuarentena la evidencia y los hallazgos de la ventana temporal sospechosa (10.4.5).

Datos obligatorios de todo Claim APAS público (11.1.1)

• estado atómico o basado en matriz,
• las ocho dimensiones del Claim,
• la identidad del Evaluator,
• las fechas de certificación y de validez,
• la versión del sistema candidato,
• las limitaciones materiales allí donde se reclama Reliance,
• la disponibilidad de la declaración de calidad aplicable o de un resumen,
• en caso de varias combinaciones soportadas, el estado de las combinaciones adyacentes que un comprador razonable podría suponer disponibles,
• la versión del Core Standard y el identificador, con su versión, de cada Companion Document aplicado,
• cuando sea relevante, si se soporta la conmutación dinámica entre combinaciones,
• y, allí donde el Claim String aparezca públicamente o en material dirigido a compradores, marketing o adquisiciones, una lectura en lenguaje claro de una sola frase conforme al Anexo A — con la misma prominencia que la cadena codificada.

Afirmaciones prohibidas (11.2.1)

Sobre la sola base de una certificación APAS, nadie puede afirmar ni implicar:

Dos reglas más completan la sección: ninguna clase de ejecución, colaboración, Assurance o Reliance puede comercializarse sin las dimensiones completas del Claim — un «Q4» o «X3» aislado en el folleto es inadmisible (11.2.2). Y una Single-Capture Confirmation debe identificarse como tal en todo Claim público y nunca puede presentarse como reproducida de forma independiente (11.2.3). En caso de contradicción, las declaraciones atestadas prevalecen sobre cualquier afirmación pública y cualquier resumen de marketing (13.2); si un framework o assessor exige condiciones más estrictas que APAS, se aplican estas (13.3).

La propia CSA sitúa APTS como la iniciativa más afín: un proyecto OWASP Incubator en fase temprana sobre la operación segura y acotada de plataformas autónomas de pentest. Solo hay solapamiento en la gobernanza operativa — las secciones 7 (Declared Conditions), 9 (Human Assistance) y 10 (Safety) de APAS —, mientras que APTS no prevé ninguna metodología de medición de Coverage (cobertura), ninguna gradación de Reliance (confianza depositada) o de sustitución ni certificación basada en evaluador; justo ese es el núcleo de APAS. Donde APTS aborda la reproducibilidad de hallazgos y la evidencia dirigida al assessor, APAS va más allá: los Confirmed Findings exigen una reproducción independiente del agente y la Coverage se mide contra una Independent Surface Baseline (Relationship to Existing Work).

Cómo utilizar ambos estándares de forma conjunta

La decisión: dónde se sostienen hoy los pentests autónomos

Los sistemas de pentest autónomos despliegan sus fortalezas donde cuentan la amplitud, la frecuencia y la repetibilidad: comprobación continua de una superficie de ataque cambiante, pruebas de regresión tras los releases, triaje previo a un pentest manual, retests con Procedures reproducibles y la cobertura de muchos objetivos del mismo tipo. Sus límites los fija el propio APAS: sin Social Engineering, sin vectores físicos ni de radiofrecuencia, sin Red Team completo (2.2, 5.6.3), sin operación continua como Claim (2.2.4) y sin sustitución de pruebas exigidas sin R3, perfil y autorización del marco de auditoría (5.10). Por eso la decisión rara vez es «autónomo o humano», sino: ¿qué subconjunto de las actividades de prueba puede realizarse de forma autónoma y con qué Assurance, y qué sigue siendo clásico?

1. 1
   Fijar la finalidad de la evidencia

   ¿Remediación interna (Q2/R1), Augmentation para auditores (Q4/R2) o Substitution (Q4/R3)? El Reliance Navigator de esta página le guía a través de la pregunta; el resultado determina todos los demás requisitos.

2. 2
   Proporcionar Scope y Baseline

   Un inventario legible por máquina (CMDB/CAASM, referencias SBOM) es su Baseline BS-1; para Q3/Q4/R3 se añade una enumeración dirigida por el evaluador (BS-2). Sin Baseline nadie puede medir la Coverage, tampoco usted (4.2).

3. 3
   Plantear el piloto como evaluación

   Diseño de ejecuciones prerregistrado con varias ejecuciones y medida de varianza (4.6.3), reproducción independiente de una muestra (EV3), observaciones emparejadas en hallazgos de autorización (4.4.6), prueba End-to-End de la Stop Authority (10.2.6), pruebas adversariales de Agent Integrity (10.4.4) y una ejecución a ciegas contra la Eval-Awareness (10.4.3).

4. 4
   Definir el modelo operativo «humano más agente»

   ¿Qué clase X/C encaja con su tolerancia al riesgo? Para objetivos productivos con acciones irreversibles rigen las obligaciones más estrictas (10.3.2); fije puntos de aprobación, contactos de escalado, ventanas de prueba y la De-Confliction con el SOC (7.4.3).

5. 5
   Contrato y gobernanza

   Data Handling y Egress (7.1.1), Stop Authority y tiempo de reacción, Access Disposition, divulgación de cambios de configuración y re-atestación (5.11.3), responsabilidad en caso de sustitución (5.10.4), formatos de intercambio (8.4.3), más los KPI: Unsupported-Finding Rate, tasa de retest, Coverage frente a la Baseline, tiempo de reacción ante el Stop.

Evaluación de herramientas: el catálogo de requisitos APAS

• ¿Qué combinaciones de capacidades ofrece la plataforma, presentadas como Capability Matrix con las ocho dimensiones y las clases de estado, y no como lista de funcionalidades (5.3, 5.4)?
• ¿Cuál es la lectura en lenguaje claro de su Claim más fuerte y qué limitaciones se le aplican (11.1.1)?
• ¿De dónde procede el denominador de Coverage de sus informes: del propio descubrimiento o de una Baseline independiente? Muestre una declaración de Coverage con todos los campos obligatorios (4.2.1).
• ¿Cuál es su Unsupported-Finding Rate por combinación, desglosada en False Positives y Over-Severity (4.3.8)?
• ¿Incluye cada hallazgo una Reproduction Procedure que mi equipo pueda reproducir sin su plataforma, y un Stable Finding Identifier (4.3.3)?
• ¿Cómo marcan Observations, Validated y Confirmed Findings, y quién confirma (4.3, 4.4.1)?
• ¿Cómo caracterizan la varianza entre ejecuciones, e informan de todas las ejecuciones o solo de la mejor (4.6)?
• ¿Qué campos abarca su perfil de Affordance, en particular Inference y Telemetry Egress con jurisdicción, Tool y MCP Provenance, Action Reversibility (7.1.1)?
• ¿Cómo actúa la Stop Authority out-of-band, con qué tiempo máximo de reacción, y qué ocurre si se pierde la supervisión (10.2.2, 10.2.3)?
• ¿Qué controles existen contra Prompt Injection, Tool Substitution, Context Poisoning y la elusión de los controles en tiempo de ejecución, y quién los ha probado de forma adversarial (10.4)?
• ¿Entregan Agent Execution Record, hashes de contenido y atestación firmada, y en qué formatos exportan hallazgos, mapeos y estado de corrección (8.2, 8.4.3)?
• ¿Qué cambios en el modelo, el prompt, la orquestación o el conjunto de herramientas nos comunican, y con qué frecuencia ha cambiado sustancialmente su configuración en los últimos doce meses (5.11)?

La versión completa, con matriz de valoración, criterios de exclusión y 20 preguntas para RfP, se encuentra en el whitepaper para CISO más abajo en esta página.

Encuadre regulatorio: qué pueden aceptar los auditores

APAS deja claro que no fundamenta ningún cumplimiento regulatorio, contractual ni de auditoría, y que una certificación APAS nunca implica la aceptación por parte de un marco (1, 5.9.1). A la inversa, la mayoría de los marcos no dicen nada sobre testers autónomos: exigen pruebas, metodología, cualificación y documentación. El encuadre siguiente es, por tanto, una valoración de VamiSec sobre qué clase de Reliance puede aceptar hoy razonablemente un auditor bajo cada marco.

Los supervisores muestran en 2026 una línea reconocible: la IA como capacidad de apoyo, supervisada por personas. La supervisión bancaria del BCE instó en julio de 2026 a las entidades significativas a elaborar planes de acción contra ataques apoyados en IA y menciona las herramientas basadas en IA como complemento de la comprobación de vulnerabilidades, con la condición de una evaluación previa de beneficios y riesgos, medidas de protección adecuadas y supervisión humana. ENISA describe ese mismo mes el «Verification Bottleneck»: el volumen de hallazgos de IA técnicamente correctos desborda la verificación, exactamente la brecha que APAS aborda con Confirmed Findings y la Unsupported-Finding Rate. El NCSC británico exige para los agentes de IA sandboxing, logs inmutables y la posibilidad de «desenchufarlos»; la guía conjunta de los Five Eyes de mayo de 2026 recomienda Red Teaming y pruebas de penetración contra sistemas agénticos, así como aprobación humana antes de acciones de alto impacto. Hasta ahora no existe ninguna declaración supervisora que reconozca o rechace expresamente los pentests autónomos como evidencia regulatoria.