Pontos principais
- A superfície de automação é local: uma interface na própria máquina do operador, não um endpoint hospedado até o qual uma requisição viaja.
- Duas formas atendem a trabalhos diferentes — CDP para inspeção e controle direto do navegador, REST para operações de Perfil e de ciclo de vida.
- A unidade de isolamento é o Perfil, não o navegador: um agente, um Perfil, com estado de navegador e atribuição de rede próprios.
- A localidade deixa explícita a fronteira da conexão. Ela não autoriza uma ferramenta, não protege seu código nem garante que um endpoint exista em todo lançamento.
- O que é exposto é o que está documentado para a versão instalada — nada implícito além disso.
O que a superfície de automação realmente é
Ao ouvir “API de automação”, as pessoas costumam imaginar um serviço hospedado em algum lugar na nuvem que um script chama pela internet. Não é disso que se trata aqui. A Agilelogin expõe a automação do navegador localmente: controle por software de um navegador ou de um Perfil através de uma interface exposta no próprio dispositivo do operador, não um endpoint remoto. Nada nessa conexão passa por um servidor de terceiros — a ferramenta e o navegador rodam na mesma máquina.
Essa superfície local tem duas formas documentadas. O acesso ao Chrome DevTools Protocol (CDP) pode oferecer suporte à inspeção e interação direta com o navegador quando o kernel instalado o expõe — a camada a usar quando um fluxo realmente precisa de controle no nível do navegador, observando ou controlando uma página como um operador humano faria. Ao lado disso, endpoints REST documentados podem expor operações de Perfil e ciclo de vida selecionadas para um determinado lançamento, sem exigir controle total no nível do navegador para cada tarefa. Na prática, os dois atendem a trabalhos diferentes: CDP para inspeção e controle direto do navegador, REST para as operações de aplicação que o produto escolhe suportar. Um agente que só precisa iniciar um Perfil ou verificar seu estado não precisa do peso de uma sessão CDP completa; um fluxo que precisa ler o que está realmente renderizado em uma página precisa.
A palavra importante em ambos os casos é documentado. A localidade deixa explícita a fronteira da conexão — um agente está falando com sua própria máquina, não com uma API hospedada que precisa confiar cegamente — mas isso, por si só, não autoriza uma ferramenta, não protege seu código, nem garante que um determinado endpoint exista em todo lançamento. O que é exposto é exatamente o que está documentado para a versão instalada, nem mais nem menos.
Por que o Perfil é a unidade, não o navegador
A fronteira sobre a qual um agente deve raciocinar não é o navegador — é o Perfil. Um Perfil de navegador isolado para um agente de IA é um contexto de navegador local persistente atribuído a um fluxo automatizado aprovado: seu estado de navegador e sua atribuição de rede permanecem identificáveis como pertencentes a esse Perfil, enquanto o fluxo o acessa pela interface local CDP ou REST descrita acima. O Perfil cria uma fronteira de controle; por si só, ele não concede ao agente permissão além das contas e sistemas que o operador já autorizou.
É essa fronteira que impede o trabalho de um agente de vazar para a sessão de outra conta. Cookies, armazenamento e suposições de rede permanecem vinculados a um Perfil específico, então, quando um fluxo recorrente precisa de estado de sessão autorizado, dar a ele um Perfil dedicado torna a propriedade do estado e as suposições de rede muito mais fáceis de verificar do que se vários fluxos compartilhassem um navegador. A regra prática que se segue é simples: dê ao fluxo um Perfil reconhecível próprio, em vez de reutilizar uma sessão não relacionada de uma pessoa ou de outro agente. Um fluxo aprovado pode direcionar-se a esse Perfil dedicado, o que deixa mais claro qual processo é dono do estado atual do navegador e quando essa posse termina.
Compartilhar um Perfil entre vários agentes costuma ser o padrão errado. Quando agentes rodam simultaneamente, ou precisam de estados separados, um Perfil por fluxo aprovado torna cookies, armazenamento, suposições de rede e a responsabilidade por falhas muito mais fáceis de entender do que uma sessão compartilhada. Se dois agentes realmente precisarem compartilhar um Perfil, isso deve ser uma decisão deliberada e testada, não algo que acontece porque ninguém configurou um segundo.
O que uma interface local não dá a você
É tentador tratar “local” como sinônimo de “seguro”, mas essa não é a leitura correta. O acesso local é uma fronteira, não uma decisão de confiança. O fato de a interface estar na mesma máquina que o agente diz onde a conexão termina; não diz nada sobre se o código que a chama deve ser confiável, e a Agilelogin não amplia a autoridade de um agente além do que o operador já concedeu. Um agente ou script conectado recebe apenas a autoridade que o operador lhe dá.
Duas disciplinas decorrem diretamente disso. Primeiro, restrinja o acesso a dispositivo e rede: confirme o suporte de versão da interface e restrinja quem e o que pode alcançá-la localmente, em vez de deixar uma superfície de controle acessível a qualquer coisa em execução na máquina. Restringir quem pode rodar software no dispositivo, revisar as ferramentas que se conectam e proteger segredos é responsabilidade do operador, não algo que a simples presença de um endpoint local faz automaticamente. Segundo, use apenas ferramentas aprovadas e documentadas: revise o código, as permissões, os prompts, o tratamento de segredos e o caminho de atualização de um agente do mesmo jeito que faria com qualquer outro software com acesso a contas, já que credenciais, prompts, logs, dependências e o comportamento do site de destino são todos riscos separados que uma fronteira local não elimina.
A terceira disciplina é verificar o comportamento em relação ao lançamento realmente instalado. Nenhuma declaração de prontidão para produção está publicada hoje para a superfície de automação. A suposição mais segura é que as interfaces são específicas de cada lançamento até que documentação versionada de comportamento de autenticação, erros e detalhes de compatibilidade esteja disponível para a versão que você está executando — confirme isso antes de deixar um fluxo depender da existência de um endpoint específico.
Onde isso está hoje
Nada disso descreve um produto que você já pode baixar. O aplicativo desktop ainda não teve seu primeiro lançamento público, então não há nada aqui para instalar, e nada neste texto deve ser lido como uma afirmação em contrário. O que está documentado é a forma das superfícies locais CDP e REST às quais uma ferramenta aprovada vai se conectar quando um lançamento sair, e as fronteiras ao redor delas: o Perfil como unidade de isolamento, a máquina local como fronteira de confiança, e o operador como fonte de qualquer autoridade que um agente tenha.
Isso também significa que os detalhes específicos — quais endpoints existem, o que eles aceitam, como os erros são reportados — ainda não estão fixados, e nenhuma declaração de prontidão para produção está publicada hoje para a superfície de automação. Trate o que está escrito aqui, e na documentação de recursos da qual isso parte, como a direção em que a interface está sendo construída, não como uma referência congelada. Quando um lançamento realmente sair, o primeiro passo correto para quem conectar um agente a ele é o mesmo descrito acima: confirmar a versão, ler o que está de fato documentado para essa build, e conceder ao agente não mais autoridade do que o fluxo precisa.