Isolamento do Runtime

Como o runtime prova quem é, o que ele consegue enxergar da plataforma, e por que uma máquina comprometida não vira uma porta de entrada para outros clientes.

O modelo: um componente crítico, tratado com o rigor que isso exige

O runtime é quem de fato executa os agentes: ele carrega credenciais reais, opera navegadores e sistemas em nome da sua empresa, e roda numa máquina que é sua, seja um notebook, um servidor compartilhado ou um contêiner. Dada essa criticidade, o executável distribuído foi desenhado para não carregar nenhum segredo de longo prazo: tudo que ele precisa para operar é obtido em tempo de execução, validado a cada ativação, e escopado ao mínimo necessário. Isso limita o que está em jogo mesmo num cenário extremo, como uma máquina de runtime comprometida ou uma cópia do executável extraviada.

Ativação por chave: como o runtime prova quem é

Ao iniciar, o runtime lê o agent.config.json local e envia dois valores ao Router da plataforma:

• user_token: identifica a conta dona do ambiente
• key_activation: a chave gerada especificamente para aquele ambiente, em Meus Ambientes

O Router não aceita a chave sozinha, nem o token sozinho: ele exige que a combinação bata com um ambiente específico cadastrado sob aquela conta. Uma chave copiada de outro ambiente, ou um token de outro usuário, faz a ativação falhar (veja os erros comuns em Ambientes Runtime).

Sem credencial mestra no executável

Validada a ativação, o Router não devolve uma senha nem uma credencial de administrador. Ele emite um custom token do Firebase, de curta duração, com uma claim (bmToken) que escopa tudo que aquele runtime pode fazer ao próprio user_token. O runtime usa esse token para autenticar via SDK cliente do Firebase, exatamente como um app comum autenticaria um usuário final, nunca com uma service account ou uma credencial de administrador embarcada no binário.

Na prática, isso significa que descompilar ou extrair o executável distribuído não expõe uma chave-mestra da plataforma: o pior cenário é obter acesso ao escopo de uma conta, e só depois de uma ativação válida, ou seja, o mesmo acesso que o próprio dono do ambiente já tem.

Isolamento entre execuções: cada job no seu Worker

Um mesmo runtime pode receber várias execuções ao mesmo tempo, de processos diferentes, ou até do mesmo processo disparado em paralelo. Cada uma delas roda isolada das demais: o processo principal do runtime nunca executa o agente diretamente, ele só recebe o job e sobe uma Worker thread nova e dedicada para aquela execução específica.

• Memória própria por execução: cada Worker tem sua própria instância de V8, sem memória compartilhada com o processo principal nem com outras execuções em andamento. Uma variável, um estado ou um dado de uma execução não vaza para outra.
• Payload individual, não um estado global: o runtime entrega a cada Worker só os dados daquele job específico (a definição do processo, o token de quem está executando, o ID da instância) via passagem de mensagem, não uma referência a um estado compartilhado que outras execuções também enxergam.
• Falha contida: se uma execução trava, lança uma exceção não tratada ou consome memória demais, isso derruba aquele Worker, não o processo principal nem as demais execuções em andamento na mesma máquina.

Comunicação em tempo real (socket)

Além da ativação (HTTP, via Router), o runtime mantém uma conexão de socket persistente com a plataforma para três finalidades:

• Transmitir tela e logs durante o Debug: quando alguém acompanha uma execução ao vivo pelo Agent Builder
• Receber comandos de controle: pausar, retomar ou parar uma execução em Debug
• Gravação assistida (Copilot): abrir e fechar o navegador isolado usado no mapeamento

O acesso a esse fluxo em tempo real é de posse, não de sessão: o identificador da instância (instanceID) é um UUID gerado pelo servidor e só é entregue a quem já passou pela autorização normal da plataforma (sessão de usuário + permissão sobre o processo) para abrir aquela tela de Debug. Ninguém adivinha um instanceID válido de fora, e o socket em si nunca expõe dados de execução por padrão, só quando alguém entra explicitamente na sala daquela instância.

O que fica de fora do isolamento

Isolamento de credenciais não é isolamento de rede ou de sistema operacional, e vale ser direto sobre os limites:

• A máquina do runtime continua sendo sua responsabilidade. Se o sistema operacional, o usuário do SO ou a rede local estiverem comprometidos, isso está fora do que a ativação por chave protege. Veja Pré-requisitos técnicos para o que trafega de/para a máquina.
• O agent.config.json em si é um segredo. Ele contém a chave e o token válidos para aquele ambiente, então trate-o como uma senha (já coberto em Ativação do runtime).
• Scripts customizados (Node/Python) rodam com os privilégios do usuário do SO que executa o runtime. O sandboxing é do runtime em relação à plataforma, não do script em relação à máquina local.

Boas práticas

• Uma chave de ativação por ambiente, sem exceção. Nunca reaproveite o mesmo agent.config.json em duas máquinas: cadastre um ambiente novo e gere uma chave nova.
• Revogue rápido. Ao desligar um servidor ou desconfiar de exposição, apague o ambiente em Meus Ambientes e a chave para de validar imediatamente.
• Trate o token de usuário com o mesmo cuidado que uma senha. Ele é reutilizado por todos os ambientes daquela conta, então girar o token de API (em Chaves de API) afeta todos eles.
• Restrinja quem tem acesso físico/remoto às máquinas de runtime: o isolamento protege a plataforma de uma máquina comprometida, mas não protege os dados que trafegam por essa máquina localmente.