Añádelo como fuente preferida en Google
Borrar toda tu base de datos de producción y las copias de seguridad no es algo que un humano haga a menudo, pero sí es posible que lo haga un agente de IA que actúe siguiendo instrucciones estrictas. Un agente no comprobará si hay alguna discrepancia en las credenciales dentro del código.
Sin medidas de seguridad, seguirá adelante sin más. Esto es lo que le pasó a PocketOS en abril de 2026, pero no fue culpa del agente de IA. Más bien, demuestra que la infraestructura y el control de los flujos de trabajo de los agentes necesitan supervisión humana.
En esta entrada vamos a ver cómo aplicar esas medidas de seguridad para los agentes usando las funciones de Kinsta. Tanto la API de Kinsta como el panel de control de MyKinsta tienen un papel importante. A medida que los agentes de IA asumen más trabajo, necesitan controles estrictos en los que un humano apruebe los pasos que puedan causar daños.
Por qué el acceso al entorno de producción supone un riesgo para un agente de IA
Cuando se trata de fallos, un script típico y un agente de IA fallan de formas diferentes. Con un script, ves un error en pantalla. Incluso si te sale la Pantalla Blanca de la Muerte, sigue siendo un error que se muestra en pantalla. Esto se debe a que, salvo en casos muy excepcionales, siempre se incluye la gestión de errores en un script.
Sin embargo, la naturaleza de la IA es cumplir con una tarea. Esto significa que un agente de IA puede indicar que ha tenido éxito, pero generar errores ocultos. Esto sigue ocurriendo porque el modelo quiere ayudarte a tener éxito. Esto da lugar a resultados inventados o sintetizados.
En el caso de WordPress, cualquier agente que rastree Changelogs, respuestas de API, contenido extraído o cualquier otra cosa como parte de sus tareas está expuesto a riesgos de seguridad. En abril de 2026, Essential Plugin lanzó una puerta trasera que envió código malicioso a más de 400.000 sitios web antes de que la desactivaran. Sin embargo, esto no soluciona el problema de los sitios web afectados.
Un agente de IA que aplica actualizaciones de plugins automáticamente como parte de su flujo de trabajo no distingue entre actualizaciones legítimas y aquellas que han sido manipuladas. A menos que incluyas una revisión previa, este tipo de ataque también te puede afectar a ti. El informe de Opsin Labs de 2026 sobre la adopción de agentes destaca que el 60 % de los agentes de IA tienen más permisos de los necesarios. Es el mismo problema de permisos que tienen los equipos humanos de WordPress, y que ahora se está dando también con los agentes.
Cómo el entorno staging puede convertir un error de un agente de IA en un incidente sin importancia
Una revisión de entorno staging como parte de tus instrucciones de flujo de trabajo te permite cuestionar aspectos concretos del despliegue de agentes. Por ejemplo, si un desarrollador envía un cambio planificado, ya sabe cuáles son esos cambios.
Por el contrario, un agente de IA que sigue una serie de instrucciones como parte de una tarea de varios pasos simplemente está intentando completar la tarea por ti. Si a esto le sumamos la posible síntesis de información, resulta que un punto de control para la revisión es imprescindible.
Si comparas el ataque a la cadena de suministro de WordPress con un agente que realiza actualizaciones en el entorno de producción, en ambos casos se aplican cambios sin supervisión previa. Kinsta incluye un entorno staging gratuito para todos los sitios web con el fin de ayudar a combatir este problema:
También tienes la opción de utilizar entornos staging premium si necesitas trabajar con una configuración más parecida a la de producción.
Con esto configurado, los cambios que realiza un agente de IA no pasan del entorno staging hasta que decidas publicar el entorno en producción:
Esto te ofrece opciones detalladas para transferir la base de datos, los archivos o ambos a la vez. MyKinsta también crea primero una copia de seguridad automática del entorno de destino. La misma lógica se aplica también a las actualizaciones automáticas de Kinsta.
Una forma práctica de incluir staging en tu flujo de trabajo es clonar el entorno de producción en staging antes de ejecutar una tarea de agente. A continuación, ejecuta el agente de IA en staging y revisa el resultado. Por último, la función de envío selectivo te permite aprobar los cambios y enviarlos a producción.
Aplicar el principio del privilegio mínimo antes de que un agente de IA acceda a WordPress
El acceso y los permisos de los agentes funcionan según los mismos principios que los de las personas. El principio del mínimo privilegio es un concepto fundamental de seguridad:
Un agente o una persona solo debería tener el nivel mínimo de permisos y acceso que necesite para llevar a cabo una tarea, y nada más.
La configuración actual de roles y permisos de Kinsta se aplica tanto a los agentes de IA como a las personas:
- Administrador de la empresa, que te da control total sobre toda tu cuenta de Kinsta. Casi ningún agente de IA necesita este rol.
- Desarrollador de la empresa permite a tu agente gestionar todos tus sitios y DNS.
- Administrador del sitio te permite asignar acceso completo al sitio a un agente.
- Desarrollador del sitio es el más adecuado para los flujos de trabajo de los agentes, ya que solo permite acceso al entorno staging.
Asignar roles también significa que tienes que asignar claves API a tus agentes. Una clave API de Kinsta hereda el nivel de acceso del rol que la genera. Es una buena forma de limitar automáticamente el acceso que tiene un agente de IA.
Un flujo de trabajo sólido y seguro consiste en generar claves API por agente o por flujo de trabajo. Para ello, tienes que ir a la pantalla Configuración de la empresa > Claves API en MyKinsta:
Establecer una fecha de caducidad te permite revisar los accesos. Si tu flujo de trabajo cambia, ahora tienes una forma natural de reevaluar tus accesos y permisos.
Por qué las copias de seguridad deberían ser una parte importante de tu flujo de trabajo automatizado
Como las causas de los fallos varían entre los flujos de trabajo humanos y los de los agentes, también lo hace la necesidad de contar con copias de seguridad. Por ejemplo, es normal que una persona se detenga un momento al realizar una tarea destructiva. Sin embargo, como tiene que seguir las instrucciones al pie de la letra, un agente de IA no se detendrá a pensar ni a comprobarlo dos veces. La solución es incorporar un requisito estricto.
Esto significa que una copia de seguridad solo sirve de red de seguridad cuando está fuera del alcance de lo que podría borrarla. Por ejemplo, el incidente de PocketOS es tanto un problema de arquitectura relacionado con las copias de seguridad como un problema de permisos. Almacenar copias de seguridad a nivel de volumen en el propio volumen es algo que se puede solucionar mediante código.
Sin embargo, en Kinsta no es posible restaurar tu base de datos solo con una copia de seguridad antigua:
- Las copias de seguridad automáticas diarias te proporcionan un punto de referencia independientemente de lo que haga un agente.
- Las copias de seguridad generadas por el sistema se ejecutan antes de una actualización o un envío selectivo, incluso cuando las activa un agente.
- Las copias de seguridad manuales te permiten crear tus propios puntos de restauración (con etiquetas) cuando los necesites.
La API de Kinsta te permite incorporar comprobaciones antes de que un agente de IA lleve a cabo un paso destructivo:
const KINSTA_API_URL = 'https://api.kinsta.com/v2';
const headers = {
'Content-Type': 'application/json',
Authorization: `Bearer ${process.env.KINSTA_API_KEY}`
};
const createBackup = async (envId, tag) => {
const resp = await fetch(`${KINSTA_API_URL}/sites/environments/${envId}/manual-backups`, {
method: 'POST',
headers,
body: JSON.stringify({ tag })
});
return resp.json();
};
const pollOperation = async (operationId, intervalMs = 5000, maxAttempts = 12) => {
for (let i = 0; i < maxAttempts; i++) {
const resp = await fetch(`${KINSTA_API_URL}/operations/${operationId}`, { method: 'GET', headers });
const data = await resp.json();
if (data.status === 200) return data;
if (data.status >= 400) throw new Error(`Operation failed: ${data.message}`);
await new Promise(r => setTimeout(r, intervalMs));
}
throw new Error('Operation timed out');
};
const findBackupByTag = async (envId, tag) => {
const resp = await fetch(`${KINSTA_API_URL}/sites/environments/${envId}/backups`, { method: 'GET', headers });
const data = await resp.json();
return data.environment.backups.find(b => b.note === tag) || null;
};
const runAgentTask = async (envId, agentTask) => {
const tag = `pre-agent-action-${Date.now()}`;
const backup = await createBackup(envId, tag);
if (!backup.operation_id) throw new Error(`Backup request failed: ${JSON.stringify(backup)}`);
await pollOperation(backup.operation_id);
const verified = await findBackupByTag(envId, tag);
if (!verified) throw new Error('Backup not found after completion');
return agentTask();
};
Aquí, envías una solicitud POST para crear una copia de seguridad manual de un entorno. A continuación, el agente puede consultar el ID de la operación y confirmar la copia de seguridad. Una vez confirmada, el agente puede continuar con el paso destructivo. Incorporar un paso para crear una copia de seguridad al modificar el entorno de producción es tan importante e innegociable como cualquier otra configuración de seguridad.
Cómo comprobar el alcance del flujo de trabajo de los agentes de IA en MyKinsta
Usar la información de MyKinsta te permite hacer una auditoría de a qué pueden acceder tus agentes. La opción programática que usa la API de Kinsta es casi instantánea si la integras en tus instrucciones. Sin embargo, la interfaz de MyKinsta te ofrece la posibilidad de hacer una auditoría de diez minutos realizada por una persona.
Asegúrate de que el entorno staging sea tu ruta predeterminada
Las comprobaciones aleatorias previas te permiten revisar personalmente algunos datos clave. Hay dos aspectos que debes comprobar:
- Las instancias de los ID del entorno de producción.
- Las actualizaciones automáticas de Kinsta se ejecutan en los momentos adecuados de tu flujo de trabajo.
Para encontrar tus IDs de producción y staging a través de MyKinsta, abre el panel de control de un sitio y fíjate en la URL:
https://my.kinsta.com/sites/details/{site_id}/{environment_id}?idCompany={company_id}
Usa el menú desplegable de entornos para cambiar entre los entornos que quieras comprobar. A continuación, abre cualquier configuración o script que gestione tu automatización y busca el ID del entorno. Si aparece algún ID de producción, cámbialo por tu ID de staging.
Para confirmar tu configuración de Actualizaciones automáticas, ve a la pantalla Plugins y temas. Aquí, haz clic en Cambia junto a la sección Actualizaciones Automáticas:
La solución de Kinsta te permite utilizar pruebas de regresión visual y revertir cambios cuando detectas un error. Si alguna de las capturas de pantalla del antes y el después de las páginas de tu sitio presenta diferencias, Kinsta revierte los cambios a una versión «confiable». Además, puedes ajustar la sensibilidad de las pruebas de regresión visual y trabajar también con contenido dinámico.
Revisa quién tiene acceso a tus claves API
Una comprobación sencilla es auditar tus claves API. Dependiendo del tamaño de tu equipo y de los proyectos que lleves a cabo, puede que haya muchas claves caducadas o redundantes que debas eliminar.
Para hacerlo, ve a Ajustes de la empresa > Claves API en MyKinsta. La lista no te indica el nivel de acceso de cada clave desde el panel de control. Por eso, es fundamental tener convenciones de nomenclatura y registros claros.
Debes comprobar tres elementos:
- Para qué rol se generó una clave.
- La fecha de caducidad, que se puede ver en la lista.
- Si la clave sigue utilizándose en un flujo de trabajo activo.
Para cualquier clave de API que no esté activa pero que aún no haya caducado, puedes hacer clic en el botón Revocar para eliminarla. En el caso de las claves caducadas, el botón dice Eliminar. En cualquier caso, la acción es la misma.
Puedes filtrar la pantalla Actividad del usuario en MyKinsta para ver la actividad asociada que utiliza una clave API concreta:
Para la comprobación programática, hay endpoints que permiten recuperar los registros de actividad y las claves de API de una empresa.
Sin embargo, para ver la información del nivel de acceso de una clave API, tiene que haber al menos una acción asociada a ella. Así que, si una clave nunca se ha usado, puedes eliminarla sin problema.
Comprueba que los flujos de trabajo de los agentes tengan un punto de restauración
Para tus copias de seguridad, abre un sitio y ve a la pestaña Manual dentro de Copias de seguridad:
Aquí, busca notas que falten o que estén mal. Después, piensa si algún flujo de trabajo del agente llama a la API y hace una copia de seguridad manual. Si es así, asegúrate de comprobar el estado de la operación antes de que el agente haga la copia de seguridad.
Además, puede que un agente active copias de seguridad más a menudo de lo que esperas. Si tus cinco espacios para copias de seguridad manuales están llenos, fíjate en la fecha de creación. Esto te ayudará a decidir si necesitas optimizar un proceso de copia de seguridad que genera un gasto innecesario.
Usa el registro de actividad para detectar acciones sospechosas
Vuelve a la pantalla Actividad de los usuarios y comprueba que cada acción se pueda atribuir a un usuario concreto o a una clave API. Puedes consultar el registro de actividad a nivel de empresa o de sitio.
Para cualquier entrada que quieras consultar, haz clic en ella y usa el botón Preguntar a Soporte. Así podrás enviar un mensaje al servicio de soporte para pedir más detalles sobre el contenido de una entrada.
También hay una forma programática de acceder a los detalles de la actividad de los usuarios, lo que te ofrece otra opción para incorporar comprobaciones en tu flujo de trabajo. Sin embargo, las comprobaciones manuales pueden detectar problemas que un agente de IA podría pasar por alto.
Las medidas de seguridad hacen que la autonomía de la IA sea segura de implementar
Las funciones de MyKinsta no están pensadas específicamente para la seguridad basada en IA. El staging, los registros de actividad de los usuarios, las copias de seguridad automáticas y los permisos evitan que los flujos de trabajo de los agentes provoquen problemas catastróficos. Además, puedes controlar el flujo de trabajo en cada paso, ya sea a través del panel de control de MyKinsta o de la API de Kinsta.
Hacer que tus agentes de IA sean más fiables significa darles el alcance adecuado e incorporar medidas de seguridad en el proceso. La intervención humana sigue siendo necesaria, incluso en las operaciones más automatizadas.
Si eliges el alojamiento para WordPress de alto rendimiento de Kinsta, tendrás a tu disposición las herramientas necesarias para garantizar un acceso seguro y protegido a tus agentes. Para las agencias, Kinsta ofrece la misma seguridad y soporte técnico de primer nivel a todos tus clientes.
