Como uma execução é isolada, como as credenciais são mantidas longe dos agentes, o que é armazenado e por quanto tempo, e como relatar um problema. Esta página descreve o serviço hospedado em ephemer.al. Uma instalação auto-hospedada executa o mesmo motor na sua própria infraestrutura, então a retenção e os provedores são escolha sua; veja auto-hospedagem.
Isolamento
| Limite | Como funciona |
|---|---|
| Uma máquina por execução | Cada execução inicia sua própria microVM a partir de uma imagem de worker fixa. Quando a execução termina, a máquina é destruída, e o registro da execução mostra quando isso foi confirmado. |
| Duração | A máquina existe, no máximo, pelo timeout da execução mais um minuto (o timeout vai de 1 a 3.600 segundos). Cancelar a execução ou atingir o timeout a destrói. |
| Rede | Um worker não tem acesso direto à internet. Tudo o que sai passa por uma conexão ou, se a execução tiver, pelo acesso à web, ambos verificados pelo Ephemeral. |
| Shell | Ativado por padrão. Com shell definido como false, o agente só pode ler seus arquivos e usar as ferramentas que você conceder. Ativado, ele pode executar comandos e gravar arquivos em seu diretório de trabalho, dentro de uma máquina sem rede e sem nenhuma das suas credenciais. |
| Nada é herdado | O diretório de trabalho desaparece com a máquina. Os arquivos que você monta são somente leitura. Nenhuma máquina, arquivo ou processo é compartilhado entre execuções nem entre organizações. |
Credenciais
- Nenhuma credencial entra na máquina. As chamadas ao modelo e as requisições de conexão passam pelo Ephemeral com um token que vale só para aquela execução, e só enquanto ela está em andamento. O worker fica sabendo o nome, o tipo, as ferramentas e as instruções de cada conexão, nunca a URL nem os segredos.
- Métodos e ferramentas permitidos. O Ephemeral confere cada chamada com a concessão da execução:
allowed_methodsnas conexões HTTP eallowed_toolsnos servidores MCP. Uma execução pode restringir uma conexão salva, mas nunca ampliá-la. - Removidas das respostas. O Ephemeral remove os valores exatos das credenciais das conexões da execução das respostas, dos eventos e da saída antes que cheguem ao agente ou ao registro. Isso pega os valores em si, não cópias transformadas deles.
- Criptografadas em repouso. As definições de execução, com as credenciais inline, e as configurações de conexão salvas, com os tokens OAuth, são criptografadas antes de serem armazenadas. As chaves de API e os tokens de sessão são armazenados apenas como hashes.
- Aplicativos que você autoriza. Um aplicativo que entra com OAuth recebe, para uma organização, um token de acesso de uma hora e um token de atualização rotativo, nunca a sua senha. Os dois são guardados apenas como hashes, e você pode ver e revogar cada aplicativo autorizado na página da sua conta.
Acesso à web
- Desativado, a menos que a execução peça. As requisições são enviadas pelo Ephemeral, não pela máquina, como EphemeralBot, com um ID de requisição e endereços publicados para que os donos dos sites possam reconhecê-lo e bloqueá-lo; ele segue as regras do robots.txt dirigidas a ele.
- Só são alcançáveis endereços públicos. Endereços privados e reservados são recusados, os redirecionamentos são verificados de novo e uma lista de permissões limita a execução aos sites que você indicar.
- Cada requisição é verificada quanto a ataques, spam e dados sendo levados para fora, e toda execução tem um limite de requisições. Veja acesso à web para todas as regras.
Orçamentos são um limite rígido
Antes de uma execução começar, o Ephemeral reserva todo o orçamento dela a partir dos seus créditos. Uma chamada ao modelo ou uma requisição web que possa levar a execução além do orçamento é recusada antes de ser enviada, e a reserva não utilizada é liberada depois. Uma execução não pode gastar mais que o seu max_cost_micros. Veja orçamentos e faturamento.
O que é armazenado e por quanto tempo
| Dados | Retenção |
|---|---|
| Execuções: definição, saída, eventos | 30 dias após o fim da execução; depois são excluídos. Ficam por mais tempo apenas enquanto o faturamento, a entrega do callback ou a limpeza da máquina ainda estiverem pendentes. |
| Execuções com retenção zero de dados | ID da execução, organização, status, carimbos de data e hora, custo e uso, e uma categoria de erro genérica. Os eventos são excluídos poucos minutos após o fim da execução. A saída é devolvida uma vez e excluída depois de, no máximo, uma hora. A definição não é mantida. |
| Arquivos enviados | Até você excluí-los. Um arquivo excluído ou substituído pode levar até 30 dias para ser removido do armazenamento. |
| Backups | 30 dias. Uma execução excluída do serviço pode permanecer nos backups por até 30 dias a mais. Eventos e saídas com retenção zero de dados nunca estão em um backup. |
| Registros da conta e de faturamento | Conforme descrito na Política de Privacidade. Cadastros que nunca confirmam o endereço de e-mail são excluídos após sete dias. |
A retenção zero de dados é uma configuração de uma execução ou de um fluxo de trabalho: zero_data_retention: true. No serviço hospedado, essas execuções custam 10% a mais, o que conta para o orçamento. Veja execuções.
Os dados são armazenados no Japão e criptografados em trânsito e em repouso.
Provedores de modelos
As chamadas ao modelo são enviadas, com o conteúdo que o agente incluir nelas, ao provedor que atende o modelo que você escolher.
- Uma execução com retenção zero de dados usa apenas endpoints que não guardam nem usam a requisição para treinamento. Se um modelo não tiver nenhum, a execução é recusada com
400antes de qualquer reserva. As verificações de segurança da web e as pesquisas de toda execução usam endpoints que não coletam dados. - As demais execuções ficam sob a política de dados do próprio provedor do modelo. Use a retenção zero de dados para trabalho sensível.
Usamos um pequeno número de prestadores de serviço para hospedar e proteger o serviço, receber pagamentos (Stripe), enviar e-mails e executar modelos. Cada um recebe apenas o que sua função exige. A Política de Privacidade os descreve.
Nosso acesso
A equipe do Ephemeral acessa os registros dos clientes apenas para dar suporte, manter o serviço seguro e cuidar do faturamento. O acesso da equipe exige autenticação forte e é registrado, e as execuções com retenção zero de dados não deixam conteúdo para consultar.
Segurança da conta
| Área | Como funciona |
|---|---|
| Verificação de e-mail | Uma conta só entra depois que você abre o link enviado por e-mail. |
| Bots e tentativas de adivinhação | O cadastro e a recuperação de senha são protegidos por captcha, logins que falham repetidamente exigem um, e as requisições de autenticação têm limite de taxa. |
| Senhas | Pelo menos 12 caracteres, armazenadas apenas como hashes. Os links de redefinição funcionam uma vez e expiram em 30 minutos. Redefinir a senha encerra todas as sessões; alterá-la encerra as demais. |
| Sessões | Mantidas em um cookie seguro e HttpOnly. Sair encerra a sessão imediatamente. |
| Chaves de API | Exibidas uma vez, revogáveis na hora, com o papel member ou admin. Uma chave admin não pode gerenciar membros, chaves nem faturamento. Veja funções e chaves. |
Relatar um problema
Relate uma vulnerabilidade pelo Suporte no painel: abra uma solicitação e escreva "Security" no assunto. Descreva como reproduzi-la e não inclua segredos nem dados de outros clientes. Para relatar abuso do EphemeralBot, use o formulário da página do EphemeralBot; você não precisa de uma conta.