Cómo crear una matriz de pruebas de permisos de WordPress para agentes de IA

Una matriz de permisos debe demostrar las acciones de WordPress permitidas y rechazadas para cada identidad de IA, no solo enumerar los roles previstos o demostrar una solicitud exitosa.

La IA es más útil aquí como organizadora de pruebas, motor de comparación y asistente de redacción. Puede facilitar la inspección de una tarea compleja de WordPress, pero no puede crear una autoridad inexistente, certificar hechos que no observó ni convertir silenciosamente una recomendación en permiso para actuar.

En una frase: una matriz de permisos debe demostrar las acciones de WordPress permitidas y rechazadas para cada identidad de IA, no solo enumerar los roles previstos o demostrar una solicitud exitosa.

Lo que esta guía le ayuda a lograr

Construir una matriz ejecutable que conecte identidades, capacidades, objetos, estados y resultados esperados con pruebas positivas y negativas reproducibles.

• Una matriz de permisos por identidad y acción con respuestas esperadas exactas.
• Fixtures positivos, negativos, de propiedad de objetos y de transición de estados.
• Una distinción entre fallo de autenticación, denegación de autorización, fallo de validación y capacidad no admitida.
• Una suite de regresión para modos protegidos y capacidades personalizadas.

El artefacto terminado debe ser comprensible para la persona responsable de la decisión y reproducible por alguien que no participó en el prompt original. Una respuesta fluida no basta. Toda conclusión importante necesita una fuente, un alcance y una ruta de verificación. Cuando las pruebas no pueden establecer algo, la salida correcta es una incógnita explícita o una hipótesis comprobable.

Pruebas e insumos que preparar

• Los contratos actuales de cobertura de roles, capacidades y WP Agent Control.
• Las rutas REST o capacidades registradas y sus callbacks de permisos.
• Usuarios de prueba dedicados y fixtures seguros de WordPress.
• Resultados esperados de nivel HTTP, de herramienta o de aplicación.
• Un plan de restablecimiento limpio del entorno y de retención de pruebas.

Antes de proporcionar pruebas a un asistente, elimine credenciales, valores secretos e información personal no relacionada. Conserve los identificadores, versiones, marcas de tiempo, configuración regional, unidades y etiquetas de fuente necesarios para interpretar lo que queda. Una captura de pantalla sin URL, estado o fecha puede ser un contexto útil, pero rara vez es autoridad suficiente para una decisión de producción.

No empiece con una solicitud amplia como «revise esto», «arregle esto» o «mejore esto». Defina la decisión que el trabajo debe respaldar, la población incluida, la fuente que tiene autoridad para cada campo, las operaciones permitidas y las acciones que siguen prohibidas. La etapa de planificación o investigación debe utilizar un repositorio local, un fixture aislado o pruebas exportadas y no requiere acceso a WordPress de producción.

La intención del rol no es prueba de permiso

La matriz debe ejercitar el endpoint, la capacidad o la acción de WordPress real en el estado de objeto pertinente.

Una denegación necesita clasificación

401, 403, los errores de validación y las operaciones no admitidas tienen significados diferentes. Registrar solo «falló» oculta el control que realmente se probó.

El objeto y el estado importan

Una identidad puede editar su propio borrador, pero no la entrada de otro autor, o actualizar un borrador, pero no una página publicada. Pruebe los límites pertinentes.

Mantenga separadas la observación, la inferencia y la autoridad

Una revisión controlada debe distinguir al menos cuatro estados:

1. Observado: presente directamente en un registro, archivo, respuesta, página renderizada o prueba ejecutada identificada.
2. Inferido: una interpretación plausible respaldada por pruebas, pero no establecida directamente.
3. Recomendado: una decisión humana o próxima acción propuesta.
4. Autorizado y verificado: un cambio aprobado por separado que se ejecutó y luego se comprobó frente a los criterios de aceptación.

La salida de IA suele comenzar en los tres primeros estados. No pasa a estar autorizada solo porque sea detallada, internamente coherente o técnicamente convincente. Conserve esta distinción en tablas, informes, tickets y estudios de caso públicos.

Un flujo de trabajo seguro

1. Inventariar identidades, perfiles, rutas, capacidades, objetos y estados.
2. Definir el resultado esperado de permitir o denegar y la justificación para cada celda importante.
3. Crear fixtures aislados con ID estables y procedimientos de restablecimiento.
4. Ejecutar los casos permitidos y conservar las pruebas exactas de solicitud y resultado.
5. Ejecutar los casos prohibidos, malformados y fuera de alcance.
6. Investigar cada discrepancia sin ampliar permisos para que la prueba pase.
7. Añadir los casos verificados a la cobertura de regresión automatizada cuando sea práctico.
8. Publicar solo una matriz saneada y revocar las identidades temporales.

Esta secuencia sitúa deliberadamente una revisión responsable entre el análisis y la implementación. Si una etapa posterior necesita un acceso más amplio, cree una nueva tarea, una nueva identidad o un cambio explícito de permiso. No eleve silenciosamente la identidad analítica porque alcanzó un límite correcto.

Receta del prompt

Sustituya cada valor entre corchetes antes de utilizar el prompt. No pegue contraseñas, claves de API, cookies de autenticación, registros privados de clientes ni información personal no relacionada.

Está revisando [TASK SCOPE] para [SITE, REPOSITORY OR DATASET] utilizando únicamente las pruebas proporcionadas.

Objetivo:
Construya una matriz ejecutable que conecte identidades, capacidades, objetos, estados y resultados esperados con pruebas positivas y negativas reproducibles.

Devuelva los siguientes campos:
- Identidad
- Perfil
- Objeto
- Estado
- Acción
- Ruta o capacidad
- Resultado esperado
- Estado esperado
- Resultado observado
- Prueba
- Disposición
- Versión

Reglas:
1. Utilice identidades de prueba dedicadas y fixtures que no sean de producción.
2. Pruebe las acciones permitidas y prohibidas.
3. Conserve las clases de respuesta exactas y los cuerpos de error después de sanearlos.
4. No reinterprete una denegación inesperada como permiso para conceder más acceso.
5. No publique credenciales ni detalles sensibles de endpoints.

Para cada hallazgo:
- identifique la fuente, el registro, la URL, el archivo, la línea, el ID de objeto, el estado o la fila de conjunto de datos exactos;
- conserve fechas, versiones, unidades, configuración regional, identificadores y denominadores;
- separe observación, inferencia, recomendación e incógnita;
- indique qué pruebas no estaban disponibles;
- no cambie WordPress, código fuente, datos comerciales, analítica, sistemas externos ni contenido publicado.

Por qué este prompt está estructurado de esta forma

El prompt crea un contrato de pruebas antes de pedir recomendaciones. Hace visibles los datos faltantes, reduce la probabilidad de que un modelo complete un registro incompleto con prosa plausible y produce una salida que puede revisarse sistemáticamente. Los campos estructurados también facilitan comparar ejecuciones repetidas o entregar un subconjunto aprobado a un flujo de implementación posterior.

Una implementación de producción puede añadir un esquema JSON, entradas de herramientas tipadas o validación automatizada. Esos mecanismos mejoran la coherencia, pero no establecen que las pruebas fuente sean verdaderas, completas o actuales. La revisión humana y la verificación específica del sistema siguen siendo necesarias.

Límite de acceso recomendado

Use ningún acceso a WordPress durante la etapa de planificación o investigación para la etapa descrita en esta guía. Las capacidades exactas disponibles para una identidad deben proceder de la versión de producto instalada, el contrato de cobertura publicado y el método de conexión que se utiliza realmente.

Lo que debe permanecer fuera de esta tarea

• Cambios de permisos
• Recurso a Full Power
• Pruebas de producción
• Reescritura de resultados esperados después de la ejecución
• Garantías de seguridad no admitidas

Una acción rechazada puede ser una prueba útil de que el límite de control funciona. No responda a un rechazo esperado concediendo una cuenta amplia de administrador o Full Power. Determine primero si la acción pertenece al mandato actual. Si es así, cree una etapa autorizada por separado con la capacidad más limitada necesaria.

Cómo encaja WP Agent Control

Este es un flujo general de WordPress, no una promesa de que Agent Control pueda editar todos los objetos o integraciones tratados. En la ruta guiada, empiece por las páginas públicas. Las operaciones de plugins, temas, usuarios, ajustes, archivos, eliminación, WooCommerce, ACF y constructores no son tareas guiadas nativas. Utilice herramientas y permisos evaluados por separado cuando sea necesario.

Obtén información estructurada del sitio e inspecciona páginas publicadas seleccionadas después de conectar. Esta lectura pública no requiere una tarea temporal. También puedes navegar por páginas públicas sin el plugin; Agent Control añade acceso estructurado y continuidad hacia operaciones autorizadas en WordPress.

Conectar tu IA: docs first profile · Ver funciones y compatibilidad: coverage

Lista de verificación

• ☐ La tarea, la población, el periodo, el entorno y la decisión son explícitos.
• ☐ Cada observación importante está vinculada a pruebas exactas o etiquetada como hipótesis.
• ☐ Se conservan ID, URL, versiones, fechas, unidades, configuraciones regionales y denominadores estables.
• ☐ Las pruebas faltantes y los límites de cobertura siguen siendo visibles.
• ☐ La identidad analítica o de investigación no realizó ninguna mutación prohibida.
• ☐ Un responsable cualificado revisó las implicaciones de seguridad, accesibilidad, legales, comerciales o de lanzamiento cuando procede.
• ☐ Cualquier implementación tiene un mandato, nivel de acceso, plan de respaldo y plan de verificación separados.
• ☐ Las identidades temporales, fixtures y pruebas sensibles se revocan, restablecen o desechan después de la tarea.

Modos de fallo comunes

• Demostración solo de éxito: la matriz demuestra que una acción funciona, pero nunca que las acciones prohibidas fallen.
• Sustituto por nombre de rol: los resultados esperados se copian de las etiquetas de rol sin probar capacidades filtradas o personalizadas.
• Contaminación de fixtures: una prueba cambia el estado del objeto e invalida resultados posteriores.
• Aplanamiento de denegaciones: todos los fallos se tratan como equivalentes, ocultando defectos de autenticación o validación.

Un fallo transversal recurrente es la deriva de permisos: la tarea inicial encuentra un límite y el operador amplía el acceso antes de determinar si la operación faltante es necesaria, admitida o segura. Esto destruye el valor probatorio del rechazo y hace difíciles de atribuir los resultados posteriores.

Nota avanzada

Una matriz de permisos gobernada puede generarse a partir del grafo de autoridad declarado, pero la declaración sigue siendo solo una expectativa hasta que las pruebas ejecutadas confirmen cada celda importante. Las autorizaciones inesperadas son defectos; las denegaciones esperadas son prueba del producto.

Guías relacionadas

• ¿Qué nivel de acceso de WordPress debe dar a una IA?
• Guía de la API Abilities de WordPress para flujos de trabajo con IA
• Cómo exponer una Ability personalizada de WordPress mediante MCP
• Cómo crear un plan de pruebas de WordPress con IA

Siguiente paso

Continúe con la guía de apoyo más pertinente y utilice la guía de niveles de acceso antes de cualquier tarea autenticada. Cuando ya no se necesite acceso temporal a WordPress, termine revocando la identidad.