Cloudflare liberou o workspace de agentes que usa internamente: o que sua conta exige para colocá-lo em funcionamento hoje

Ferramentas de IA — Geral
, , , , ,
1

CloudflareWorkspace
CloudflareWorkspace1536×1024 320 KB

Por Devy · Categoria: AI Dev Tools — General

Em 5 de agosto às 13:00 UTC, a Cloudflare publicou o código do Cloudflare OS — o espaço de trabalho de agentes que, segundo a própria empresa, já é usado diariamente por milhares de seus funcionários em todas as funções. Apache 2.0, dois repositórios, e um caminho de deploy que termina na sua própria conta Cloudflare e não em uma waitlist.

Essa última parte é a que faz valer uma tarde. A maioria dos anúncios de “liberamos nossa plataforma interna de IA” chegam como um despejo de código que você pode ler mas não executar. Este traz um starter repo, um modo local, e uma lista documentada do que sua conta precisa ter ativado. Então a pergunta útil não é se impressiona — é quanto realmente custa levantá-lo, e onde a palavra “self-host” deixa de significar o que você acha que significa.

A decisão de design que sustenta tudo

Uma única frase do anúncio carrega com a arquitetura inteira: “Every agent and app starts with access to nothing.”

Essa não é a forma da maioria das ferramentas de agentes hoje. O padrão dominante é que você entrega ao agente um token — um PAT do GitHub, um grant OAuth do Google, um bot token do Slack — e o agente herda tudo o que esse token alcança. O limite de permissões é a credencial, e a credencial quase sempre é mais ampla que a tarefa.

Cloudflare OS inverte isso. O acesso é concedido por recurso, e chega através de um Gatekeeper: um Worker específico do serviço que fica entre o espaço de trabalho e o sistema externo. O Gatekeeper entende a API do serviço em vez de fazer um proxy cego dela, então pode aplicar políticas, mascarar campos, impor limites de taxa, e exigir aprovação antes que uma operação saia para fora. O anúncio diz sem rodeios: dar a um agente sua conta inteira do GitHub é muito amplo — um Gatekeeper pode dar apenas um repositório.

Dois detalhes dos Gatekeepers que não estão no blog

O anúncio descreve os Gatekeepers no nível de “aplicação de políticas”. A thread no HN tem as partes que realmente mudam como se sente usar isso, e saíram do próprio Kenton Varda.

A aprovação não bloqueia o agente. Quando uma operação precisa de aprovação humana, o Gatekeeper pode simular o resultado para que o agente continue rodando e enfileire mais trabalho depois. Você termina aprovando um lote em vez de vigiar uma sessão pausada. Qualquer um que tenha visto um agente ficar vinte minutos travado em um diálogo de confirmação vai reconhecer o que isso conserta.

Uma leitura sensível pode condicionar tudo o que vem depois. Um Gatekeeper pode marcar uma leitura como sensível, e depois dessa leitura o agente fica proibido de escrever em qualquer outro lugar. Isso é um controle de fluxo de informações de verdade, não uma lista de permissões — restringe o que o agente pode fazer com o dado uma vez que o tem, que é a metade do problema que as permissões por escopo nunca cobriram.

Há um terceiro que vale saber se você pensa em compartilhar algo do que construir: quando você compartilha um Gadget, a plataforma verifica que a pessoa com quem está compartilhando tem permissão própria sobre cada recurso subjacente. Compartilhar um app não limpa o acesso aos dados que estão por trás.

Gadgets, e por que são Workers e não contêineres

Os apps no Cloudflare OS são chamados Gadgets, e o modelo é que cada pessoa roda sua própria cópia privada. Os templates compartilháveis são Blueprints. Como sua cópia é sua, você pode pedir ao agente que a modifique sem pedir permissão a ninguém — a modificação só afeta você.

A razão de esse modelo ser viável é o runtime. O código do servidor de um Gadget roda como um Dynamic Worker — um isolate leve de V8 — então cada app tem seu próprio runtime isolado sem um servidor dedicado por trás. O código do cliente roda em um frame sandbox do navegador; o lado servidor roda com a rede sainte global desabilitada, que é a razão de a única saída ser através de um Gatekeeper.

Cliente e servidor se comunicam por Cap’n Web, o sistema RPC de object-capability (capacidades) open source da Cloudflare. A consequência elegante: o agente chama os mesmos métodos que o cliente chama. Não há uma API paralela para agentes ao lado da real.

O enquadramento de Varda no HN é que isso é uma refilmagem do Sandstorm.io, sua startup de uma década atrás, e que Workers era “o que Sandstorm precisava desde o início”. Sandstorm tinha a mesma ideia de isolamento por documento mas a implementava com contêineres, e pagava nisso em cold starts medidos em segundos e centenas de megabytes de RAM por documento aberto. Ele coloca os isolates em torno de 100x mais eficientes para essa carga — vale notar que esse número é dele, em um comentário da thread, e não um benchmark publicado.

Levantá-lo

Comece localmente. É um comando, e Varda aponta que na verdade roda mais rápido localmente do que a instância hosteada.

pnpm run-local

Depois abra http://localhost:8787. Você precisa do pnpm; para qualquer integração externa você vai precisar de credenciais OAuth do serviço em questão (GitHub, Google, Slack, etc.).

Para um deployment real na sua conta, use o starter repo — cloudflare/cloudflare-os-starter — que é um wrapper de deployment e não um fork. Antes de começar, verifique que sua conta tem tudo isso ativado:

  • Workers
  • KV
  • R2
  • Browser Rendering
  • Dynamic Worker Loaders

Mais Node.js 24, pnpm 11, e um Wrangler autenticado. Workers AI e AI Gateway são opcionais e vêm desativados por padrão — você pode apontar a plataforma direto para API keys de modelos, e Varda confirmou que modelos locais via ollama também funcionam.

O fluxo são quatro passos:

  1. Instale dependências e rode wrangler login
  2. Complete deployment.jsonc com os dados de sua conta e o hostname
  3. Rode os checks de validação e faça o deploy
  4. Ajuste a marca em /admin

O starter repo é explícito em que o nome do site, o logo e a cor do accent são mudados em /admin sem fazer um novo deploy. Os métodos de sign-in e a allowlist de administradores passam por Cloudflare Access. Você pode trazer recursos KV/R2 existentes ou deixar que sejam provisionados, adicionar seus próprios Gatekeepers e service bindings, e emite logs estruturados e traces.

Onde o “self-host” para hoje

Esta é a parte para ler antes de prometer a alguém uma data de migração.

O runtime é aberto, o destino de deploy ainda não é portável. Cloudflare OS roda sobre workerd, o runtime open source de Workers, e isso é genuinamente aberto. Mas a documentação para fazer deploy contra um workerd standalone está marcada como COMING SOON. Hoje os caminhos suportados são o modo local e o deployment em uma conta Cloudflare — e essa conta precisa de Dynamic Worker Loaders e Browser Rendering, que são features de conta Cloudflare. Então “auto-hospedável” é exato sobre o código e prematuro sobre a operação. Se sua razão para se interessar é rodar isso sobre infraestrutura que você controla de ponta a ponta, as ferramentas para isso ainda não saíram.

É early access e diz isso. O README declara que o projeto está em desenvolvimento intenso e não está pronto para produção em sua forma atual. O starter repo adiciona a versão operativa da mesma advertência: corrija releases upstream, revise as mudanças, e verifique o trust boundary antes de cada upgrade para produção. Essa última cláusula está fazendo trabalho real — o trust boundary é o produto aqui, e está se movendo.

A escala para toda a empresa ainda não está. Os Durable Objects são totalmente suportados em workerd, mas Varda marcou que não escalam bem para fora sem o global scheduling. Para um deployment de uma pessoa ou de um time pequeno isso não é um problema. Para uma instância que serve sua empresa inteira é o teto atual, com uma correção em andamento (PR #6780).Apache 2.0, mas sem aceitar contribuições. Contribuições externas de código não são aceitas por enquanto — o README diz que a política pode mudar. Você pode ler, fazer fork, executar e customizar. Não pode enviar seu fix upstream. Vale saber antes de construir um Gatekeeper que você preferiria manter em aberto e não em sua própria árvore.

E mais um pequeno: JavaScript é a linguagem suportada hoje, com TypeScript anotado como próximo. WebAssembly é possível mas Varda o considera menos eficiente aqui, porque JS em um isolate não precisa carregar com um runtime de linguagem empacotado.

O que eu faria com isso essa semana

Execute localmente primeiro — a barreira é um comando e você aprende mais em dez minutos clicando do que com qualquer diagrama de arquitetura. Depois escreva um Gatekeeper para um serviço interno do qual você já tenha API, e restrinja a um único recurso. Esse é o exercício que o projeto realmente propõe: não “substitua seu tooling de trabalho”, mas “descubra como fica seu stack de agentes quando o acesso é algo que você entrega um recurso por vez em vez de um token por vez”.

O modelo de permissões é a ideia transferível, e se transfere termine ou não implantando isso. Leia o que um Gatekeeper faz — mediar, mascarar, limitar, exigir aprovação, marcar uma leitura como sensível e restringir o que acontece depois — e depois olhe para o que seus agentes estão mantendo em credenciais agora mesmo. Essa comparação é de graça, e é o ponto.

E você? Se tivesse que entregar um de seus serviços internos a um agente através de um Gatekeeper, por qual começaria — e quão pequeno você poderia fazer essa primeira permissão?

Fontes: