Cómo se aísla una ejecución, cómo se mantienen las credenciales lejos de los agentes, qué se guarda y durante cuánto tiempo, y cómo informar de un problema. Esta página describe el servicio alojado en ephemer.al. Una instalación autoalojada ejecuta el mismo motor en tu propia infraestructura, así que la retención y los proveedores los eliges tú; consulta autoalojamiento.
Aislamiento
| Límite | Cómo funciona |
|---|---|
| Una máquina por ejecución | Cada ejecución inicia su propia microVM a partir de una imagen de worker fija. Cuando la ejecución termina, la máquina se destruye, y el registro de la ejecución muestra cuándo se confirmó. |
| Duración | La máquina vive como máximo el timeout de la ejecución más un minuto (el timeout es de 1 a 3.600 segundos). Cancelar la ejecución o que alcance su timeout la destruye. |
| Red | Un worker no tiene acceso directo a internet. Todo lo que sale pasa por una conexión o, si la ejecución lo tiene, por el acceso web, y Ephemeral comprueba ambos. |
| Shell | Activada por defecto. Con shell en false, el agente solo puede leer sus archivos y usar las herramientas que le concedas. Si está activada, puede ejecutar comandos y escribir archivos en su directorio de trabajo, dentro de una máquina sin red y sin ninguna de tus credenciales. |
| Nada se arrastra | El directorio de trabajo desaparece con la máquina. Los archivos que montas son de solo lectura. Ninguna máquina, archivo o proceso se comparte entre ejecuciones ni entre organizaciones. |
Credenciales
- Ninguna credencial entra en la máquina. Las llamadas al modelo y las solicitudes de conexión pasan por Ephemeral con un token que solo sirve para esa ejecución, y solo mientras está en marcha. Al worker se le indica el nombre, el tipo, las herramientas y las instrucciones de cada conexión, nunca su URL ni sus secretos.
- Métodos y herramientas permitidos. Ephemeral comprueba cada llamada con lo concedido a la ejecución:
allowed_methodsen las conexiones HTTP yallowed_toolsen los servidores MCP. Una ejecución puede restringir una conexión guardada, pero nunca ampliarla. - Eliminadas de las respuestas. Ephemeral elimina los valores exactos de las credenciales de las conexiones de la ejecución de las respuestas, los eventos y la salida antes de que lleguen al agente o al registro. Esto detecta los valores en sí, no copias transformadas de ellos.
- Cifradas en reposo. Las definiciones de ejecución, con sus credenciales en línea, y los ajustes de conexión guardados, con sus tokens de OAuth, se cifran antes de almacenarse. Las claves de API y los tokens de sesión se guardan solo como hashes.
- Aplicaciones que autorizas. Una aplicación que inicia sesión con OAuth recibe un token de acceso de una hora y un token de actualización rotativo para una organización, nunca tu contraseña. Ambos se guardan solo como hashes, y puedes revisar y revocar cada aplicación autorizada en la página de tu cuenta.
Acceso web
- Desactivado salvo que la ejecución lo pida. Las solicitudes las envía Ephemeral, no la máquina, como EphemeralBot, con un ID de solicitud y direcciones publicadas para que los propietarios de los sitios puedan reconocerlo y bloquearlo; además respeta las reglas de robots.txt dirigidas a él.
- Solo se alcanzan direcciones públicas. Las direcciones privadas y reservadas se rechazan, las redirecciones se vuelven a comprobar y una lista de permitidos limita la ejecución a los sitios que indiques.
- Cada solicitud se comprueba para detectar ataques, spam y datos que se intenten sacar a escondidas, y toda ejecución tiene un límite de solicitudes. Consulta acceso web para ver todas las reglas.
Los presupuestos son un límite estricto
Antes de que empiece una ejecución, Ephemeral reserva todo su presupuesto de tus créditos. Una llamada al modelo o una solicitud web que pudiera llevar la ejecución más allá del presupuesto se rechaza antes de enviarse, y la reserva no utilizada se libera después. Una ejecución no puede gastar más que su max_cost_micros. Consulta presupuestos y facturación.
Qué se guarda y durante cuánto tiempo
| Datos | Conservación |
|---|---|
| Ejecuciones: definición, salida, eventos | 30 días después de que termine la ejecución; luego se eliminan. Se conservan más tiempo solo mientras su facturación, la entrega del callback o la limpieza de la máquina sigan pendientes. |
| Ejecuciones con retención cero de datos | ID de la ejecución, organización, estado, marcas de tiempo, coste y uso, y una categoría de error genérica. Los eventos se eliminan unos minutos después de que termine la ejecución. La salida se devuelve una vez y se elimina como máximo después de una hora. La definición no se conserva. |
| Archivos subidos | Hasta que los elimines. Un archivo eliminado o reemplazado puede tardar hasta 30 días en desaparecer del almacenamiento. |
| Copias de seguridad | 30 días. Una ejecución eliminada del servicio puede permanecer en las copias hasta 30 días más. Los eventos y salidas con retención cero de datos nunca están en una copia. |
| Registros de la cuenta y de facturación | Como describe la Política de privacidad. Los registros que nunca confirman su dirección de correo se eliminan a los siete días. |
La retención cero de datos es un ajuste de una ejecución o de un flujo de trabajo: zero_data_retention: true. En el servicio alojado, estas ejecuciones cuestan un 10 % más, lo que cuenta para el presupuesto. Consulta ejecuciones.
Los datos se almacenan en Japón y están cifrados en tránsito y en reposo.
Proveedores de modelos
Las llamadas al modelo se envían, con el contenido que el agente incluya en ellas, al proveedor que sirve el modelo que elijas.
- Una ejecución con retención cero de datos usa solo endpoints que ni conservan ni entrenan con la solicitud. Si un modelo no tiene ninguno, la ejecución se rechaza con
400antes de reservar nada. Las comprobaciones de seguridad web y las búsquedas de toda ejecución usan endpoints que no recopilan datos. - Las demás ejecuciones quedan bajo la política de datos del proveedor del modelo. Usa la retención cero de datos para el trabajo sensible.
Usamos un número reducido de proveedores de servicios para alojar y proteger el servicio, cobrar pagos (Stripe), enviar correo y ejecutar modelos. Cada uno recibe solo lo que necesita para su función. La Política de privacidad los describe.
Nuestro acceso
El personal de Ephemeral accede a los registros de los clientes solo para dar soporte, mantener la seguridad del servicio y gestionar la facturación. El acceso del personal exige una autenticación robusta y queda registrado, y las ejecuciones con retención cero de datos no dejan contenido que consultar.
Seguridad de la cuenta
| Aspecto | Cómo funciona |
|---|---|
| Verificación del correo | Una cuenta solo inicia sesión después de que abras el enlace que se te envió por correo. |
| Bots y adivinación | El registro y la recuperación de contraseña están protegidos por un captcha, los inicios de sesión fallidos repetidos exigen uno, y las solicitudes de autenticación tienen límite de frecuencia. |
| Contraseñas | Al menos 12 caracteres, guardadas solo como hashes. Los enlaces de restablecimiento funcionan una vez y caducan a los 30 minutos. Restablecer la contraseña cierra todas las sesiones; cambiarla cierra las demás. |
| Sesiones | Se guardan en una cookie segura y HttpOnly. Cerrar sesión la termina al instante. |
| Claves de API | Se muestran una vez, se pueden revocar al instante y tienen el rol member o admin. Una clave admin no puede gestionar miembros, claves ni facturación. Consulta roles y claves. |
Informar de un problema
Informa de una vulnerabilidad a través de Soporte en el panel: abre una solicitud y escribe "Security" en el asunto. Describe cómo reproducirla y no incluyas secretos ni datos de otros clientes. Para informar de un abuso de EphemeralBot, usa el formulario de la página de EphemeralBot; no necesitas una cuenta.