O OpenClaw representa uma grande mudança na forma como as pessoas usam a IA. Em vez de um chatbot hospedado na nuvem, o OpenClaw é executado localmente – em seu laptop ou estação de trabalho – com a capacidade de escrever código, gerenciar arquivos, invocar ferramentas e agir de forma autônoma em seu nome.
Esse poder é exatamente o que aumenta os riscos.
O OpenClaw está em desenvolvimento ativo e acelerado, com novos recursos sendo adicionados rapidamente. Essa velocidade é um ponto forte, mas também significa que áreas fundamentais, como autenticação, autorização e auditabilidade, ainda estão evoluindo. À medida que os agentes do OpenClaw se tornam mais autônomos e mais amplamente utilizados, essas lacunas passam de compensações em estágio inicial para riscos reais à segurança.
Este artigo examina o modelo de autenticação atual do OpenClaw, seus aprimoramentos recentes (incluindo o modo de proxy confiável), o que ainda está faltando e por que integrá-lo ao ZTNA corporativo, como o Aryaka AI>Secure, é a solução mais limpa e dimensionável.
Autenticação nativa do OpenClaw: Acesso baseado em token
Atualmente, o OpenClaw se baseia principalmente em um modelo de token secreto compartilhado.
Durante a configuração, o OpenClaw gera um token de gateway – umacadeia de caracteres secreta longa e aleatória – armazenado localmente (por exemplo, no diretório inicial do usuário nos arquivos de configuração do OpenClaw). Esse token funciona como a credencial necessária para acessar o agente OpenClaw por meio de sua interface HTTP local.
Quando um usuário abre a interface de controle baseada em navegador do OpenClaw, ele é solicitado a fornecer esse token. Uma vez fornecido, o navegador pode se comunicar com o agente sem repetidas solicitações de autenticação.
As versões recentes adicionaram a aprovação manual no terminal quando uma nova sessão do navegador tenta se conectar. Essa é uma melhoria significativa na segurança, mas não altera o modelo de confiança central:
Qualquer pessoa que possua o token tem acesso total ao agente.
Ainda não há identidade de usuário, MFA, separação de funções ou avaliação contextual.
Persistência do navegador: Conveniência com risco
Para fins de usabilidade, a interface do usuário do navegador normalmente persiste o token localmente (por exemplo, no armazenamento do navegador). Isso evita solicitações repetidas, mas apresenta riscos previsíveis:
- O token se torna uma credencial de longa duração
- Malware ou extensões de navegador mal-intencionadas podem extraí-lo
- Não há expiração de sessão ou validação contextual
Do ponto de vista da segurança, o token se comporta mais como uma chave de API do que como um login de usuário.
Riscos em cenários de usuário único e multiusuário
Mesmo em configurações de usuário único, a exfiltração de tokens por meio de malware ou comprometimento do navegador leva ao controle total do agente.
Em ambientes compartilhados ou de equipe, a situação piora:
- Nenhuma identidade de usuário
- Sem funções ou permissões
- Não há como atribuir ações a indivíduos
- Não há revogação de granularidade fina
- Sem trilha de auditoria de nível empresarial
Isso é fundamentalmente incompatível com o uso empresarial, regulamentado ou de produção.
Modo Trusted-Proxy: A direção arquitetônica correta
Para resolver essas limitações, o OpenClaw introduziu o modo de proxy confiável, que é uma etapa arquitetônica significativa e positiva.
No modo de proxy confiável:
- O OpenClaw aceita solicitações somente de um proxy upstream designado
- O token de gateway permanece confinado a esse proxy
- Os usuários finais nunca interagem diretamente com o agente
Esse design reconhece explicitamente um princípio fundamental: a identidade e o controle de acesso devem estar fora do agente.
Integração do ZTNA: Injeção de identidade feita com segurança
É nesse ponto que o ZTNA se integra de forma limpa e intencional ao design de proxy confiável do OpenClaw.
Uma plataforma ZTNA, como a Aryaka AI>Secure, fica na frente do OpenClaw e executa autenticação, autorização e contabilidade (AAA) completas antes que o tráfego chegue ao agente.
Depois de autenticar os usuários por meio de IdPs corporativos (Okta, Azure AD, Google Workspace), aplicar a MFA e validar a postura do dispositivo, a ZTNA encaminha solicitações ao OpenClaw com o contexto de identidade verificada injetado, normalmente usando cabeçalhos como:
- Usuário X-Forwarded
- X-Forwarded-Groups
O modo de proxy confiável do OpenClaw foi projetado para confiar nesses cabeçalhos somente a partir do proxy configurado.
Requisito crítico de segurança: Sem encaminhamento de cabeçalho cego
Um ponto deve ser explicitado:
O ZTNA nunca deve encaminhar cegamente os cabeçalhos de identidade da conexão do cliente para o agente.
Se cabeçalhos como X-Forwarded-User forem copiados diretamente da solicitação do cliente, um invasor poderá falsificar trivialmente os cabeçalhos de identidade e ignorar os controles de segurança na camada de agente do OpenClaw.
Uma integração correta do ZTNA segue regras rígidas:
- Todos os cabeçalhos de identidade fornecidos pelo cliente são removidos
- Os cabeçalhos de identidade são reconstruídos pela ZTNA após a autenticação do JWT
- Os cabeçalhos são criptografados ou logicamente confiáveis porque:
- Eles se originam apenas do proxy da ZTNA
- O OpenClaw os aceita apenas no modo de proxy confiável
- Nenhuma entrada controlada pelo cliente é reutilizada como contexto de identidade
Essa separação é o que torna o modelo OpenClaw + ZTNA seguro por design e não por convenção.
Autorização e capacidade de auditoria sem alterações no agente
Mesmo que o OpenClaw ainda não tenha usuários ou funções nativos:
- A ZTNA controla quem pode acessar o agente
- As políticas podem ser aplicadas por usuário, grupo, dispositivo e contexto de rede
- Cada solicitação é registrada com uma identidade humana verificada
- As empresas obtêm uma trilha de auditoria limpa para conformidade e análise forense
O OpenClaw continua focado no comportamento do agente.
Conclusão: A ZTNA ainda é importante – mesmo que a OpenClaw evolua
O OpenClaw está evoluindo rapidamente e na direção certa. O modo de proxy confiável é um forte sinal arquitetônico de que o projeto entende a importância da confiança externalizada.
Mesmo que o OpenClaw implemente posteriormente a autenticação nativa de usuários ou funções, o ZTNA continua sendo valioso – e muitas vezes essencial – para as empresas.
Por quê?
Porque as empresas precisam de um controle de segurança uniforme em todos os aplicativos :
- SaaS
- Aplicativos internos da Web
- APIs
- Ferramentas para desenvolvedores
- E agora, os agentes de IA
A ZTNA oferece: Política centralizada
- MFA consistente e postura de dispositivo
- Registros de auditoria unificados
- Uma única camada de aplicação em sistemas heterogêneos
O OpenClaw não precisa se tornar uma plataforma IAM completa para ser seguro.
Quando o modo de proxy confiável do OpenClaw é combinado com uma camada ZTNA implementada adequadamente, as empresas obtêm o melhor dos dois mundos:
- Agentes de IA potentes e de rápida movimentação
- Segurança Zero Trust de nível empresarial