Tus agentes de IA actúan. Tú mantienes el control.

Los agentes de IA ya no solo escriben código o responden correos: escalan un despliegue, reinician un servicio, llaman a una API de facturación. Y para que puedan hacerlo, hoy casi siempre se les da lo mismo que a una persona de confianza: un kubeconfig, una API key o un token de servicio.

El problema es que un agente con la credencial es un agente con las llaves. Puede hacer todo lo que esa credencial permita, en cualquier recurso, y basta un prompt injection bien colocado para que lo haga. Nadie decide antes; te enteras después, si te enteras. Y cuando alguien pregunta qué modelo lo pidió, por qué y qué contestó el sistema, no queda nada que enseñar.

Por eso hemos construido Ploybot Agentes IA.

Una capa de autoridad entre el agente y el sistema

Ploybot se pone en medio. El agente ya no lleva la credencial: lleva su identidad. Cuando quiere hacer algo, lo pide, y la petición recorre siempre el mismo camino:

1. Identidad. Quién pide: el agente con su token, una identidad de workload o la sesión de una persona.
2. Capability. Qué pide, del catálogo que tú has definido: escalar, desplegar, invocar una operación, leer logs.
3. Política. Reglas declarativas, evaluadas por orden. La primera que se cumple decide.
4. Aprobación, si hace falta. Una persona recibe un aviso en el móvil con el cambio delante, el motivo del agente y el riesgo, y decide. En lo crítico, firma con su passkey.
5. Autorización. Acotada a esa operación exacta: cinco minutos y un solo uso. Si cambia una réplica, ya no vale.
6. Gateway. El único que ve la credencial. Puede vivir con nosotros o dentro de tu propia red.
7. Evidencia. Cada paso queda registrado, encadenado por hash y verificable.

El flujo es el mismo si al otro lado hay un clúster de Kubernetes, una API REST, un servicio SOAP, un servicio gRPC o un servidor MCP de terceros.

Lo rutinario lo resuelve la política; lo sensible, una persona

No queremos que nadie tenga que aprobar cada lectura de logs. La política vive junto a cada capability y se escribe una vez: en desarrollo, que el agente trabaje; en producción, que decida una persona. Una errata en una regla se rechaza al darla de alta, no el día que debería haber denegado algo.

Cuando hace falta decidir, el aviso llega al móvil de quien tiene que hacerlo. Se puede aprobar esta vez o durante un rato, y el agente reintenta solo. Lo que no se puede es reutilizar una aprobación para otra operación distinta.

Evidencia que un auditor puede comprobar

Cada acción deja su expediente: qué agente y qué modelo la pidieron, con qué motivo, qué llegó al destino y qué contestó. Los eventos se encadenan por hash y la base de datos rechaza modificarlos, así que si alguien toca uno, la cadena deja de cuadrar. No es una promesa: es algo que se comprueba.

Se conecta pegando una URL

Ploybot habla MCP, el protocolo que ya usan Cursor, Claude Code, Claude Desktop, Codex, OpenCode o GitHub Copilot. Conectar un agente es pegar la URL de su MCP y entrar con tu cuenta: sin tokens guardados en ficheros. A partir de ahí, el agente ve exactamente las tools que le has asignado, y nada más.

Si ya tienes una API documentada, puedes importar su OpenAPI, su WSDL o su definición gRPC: Ploybot propone las operaciones y tú eliges cuáles publicar.

En Europa y en tu idioma

El servicio se aloja en la Unión Europea, la consola y los correos están en español e inglés, y puedes darte de alta, probar y contratar sin hablar con nadie. Si te vas, exportas tu configuración; los secretos nunca salen.

Pruébalo

La prueba dura 14 días y no pide tarjeta: da para montar el primer agente y ver una aprobación de punta a punta. Después, el plan Developer cuesta 49 € y el Team 199 €, impuestos incluidos, cada 30 días.

Tienes todos los detalles en agents.ploybot.com, y la oferta y las condiciones en la consola. Si prefieres que te lo enseñemos, escríbenos desde el formulario de contacto.