Localhost não é identidade: controles para APIs locais de agentes

Uma API que escuta apenas na máquina local reduziu seu alcance de rede. Ela não autenticou o processo que chama, a página aberta no navegador, a extensão instalada ou o agente executando dentro de um sandbox. loopback é uma propriedade de roteamento; identidade e autoridade são propriedades de segurança diferentes.

Este Evidence Brief compara dois disclosures recentes para derivar um contrato defensivo de API local. Ele não publica passos ofensivos, não compara a segurança geral dos produtos e não transforma vulnerabilidade em incidente. Estado: aprovado para publicação em 11/09/2026 às 09h BRT. Nenhum controle aqui é declarado como implantado, ensaiado ou operando na Trustyu Forge.

Escopo factual

Em 08/09/2026, a OX Security publicou o disclosure da CVE-2026-82533 no DeepSeek Harness. Segundo a pesquisa, versões até 0.1.1-rc.2 expunham uma API local sem autenticação e usavam informação fornecida pelo cliente como sinal de confiança. Em configuração padrão, um comando do agente executado dentro do sandbox alcançou a interface local e alterou a política da própria sessão. A OX informa correção na linha 0.1.2-alpha.1 e reteste em 30/08.

O GHSA-96p9-rh4f-92cf descreve outra composição no winml-cli: versões anteriores a 0.4.0 expunham comandos por HTTP local sem autenticação e permitiam origens web amplas. A pré-condição registrada é a pessoa manter o serviço ativo e visitar uma página controlada por terceiro. O advisory indica 0.4.0 como versão corrigida.

Os casos têm superfícies, classificações e pré-condições distintas. O denominador é dois disclosures, não uma amostra de mercado. A menção a mais de 215 mil estrelas no GitHub, presente no texto da OX, mede atenção ao repositório naquele corte; não mede instalações, usuários, ambientes vulneráveis ou vítimas.

Não foi localizada, até 09/09/2026, evidência pública de exploração ativa, quantidade de vítimas, vazamento confirmado ou perda financeira nos dois casos. Corrigir a versão reduz o risco descrito; não prova auditoria total nem ausência de outras falhas.

Modelo de confiança

origem/processo ── autenticação ── autorização por capacidade ── efeito
       │                  │                    │                    │
       └──── contexto ────┴──── política ──────┴──── receipt ──────┘

O endereço local participa apenas do contexto de alcance. O servidor precisa estabelecer as demais propriedades antes do efeito:

1. Origem efetiva: navegador, extensão, processo, container, sandbox ou operador.
2. Identidade: principal verificável ligado à sessão e ao canal correto.
3. Capacidade: ação tipada, alvo delimitado e consequência conhecida.
4. Política: teto de autoridade independente do input do cliente e do workspace.
5. Evidência: decisão, versão, identidade, escopo e resultado reconstruíveis.

Invariante 1 — transporte não autentica o chamador

127.0.0.1, socket local ou bind de interface restringem caminhos possíveis. Não distinguem todos os processos que compartilham a máquina nem provam que a chamada veio da interface esperada. Host, Origin, nome de processo e campos enviados pelo próprio cliente são contexto; usados sozinhos, viram afirmações autocertificadas.

Um contrato defensivo exige:

• identidade de sessão gerada pelo servidor e ligada ao canal correto;
• credencial efêmera, restrita à audiência e não reutilizável por origem arbitrária;
• verificação do peer e do transporte como sinais adicionais, não identidade completa;
• falha fechada quando identidade, canal ou sessão não correspondem;
• rotação e invalidação quando a interface reinicia ou a política muda.

Testes negativos

• cabeçalhos que alegam origem local não transformam cliente desconhecido em confiável;
• outra página, extensão ou processo não reutiliza a sessão autorizada;
• chamadas internas ao sandbox não herdam a identidade do operador;
• uma sessão expirada ou de outra instância falha antes de executar ação.

Invariante 2 — CORS não substitui autenticação

CORS orienta o navegador sobre quais origens podem ler respostas e, em certos casos, enviar chamadas. Ele não autentica clientes fora do navegador e não autoriza uma ação privilegiada. Uma allowlist de origens pode reduzir superfície web; ainda precisa ser combinada com identidade, proteção de sessão, validação de conteúdo e autorização no servidor.

Testes negativos

• origem não permitida é recusada sem refletir arbitrariamente o valor recebido;
• origem permitida sem sessão válida também é recusada;
• clientes não sujeitos a CORS continuam passando pelos mesmos gates de identidade e autorização;
• preflight, redirect e erros não revelam dados ou capacidades adicionais.

Invariante 3 — a API de controle não pertence ao mesmo plano do agente

Quando o sandbox consegue alcançar a interface que altera sua própria política, dados e controle dividem a mesma fronteira. O plano que executa entrada não confiável não deveria possuir a capacidade de ampliar seu confinamento.

agent data plane ── pedido tipado ── policy mediator ── control plane
        │                                  │                  │
        └──────── sem credencial ──────────┘      autoridade humana/serviço

O mediador precisa impedir que uma identidade de execução:

• aumente permissões da própria sessão;
• desative aprovações ou auditoria;
• leia conversas, segredos ou sessões de outro principal;
• emita credenciais com autoridade superior;
• altere a política que avaliará a próxima ação.

A política efetiva deve permanecer source-bound e aplicada no ponto do efeito. O harness pode separar identidade transitória, capabilities e mediação de runtime, mas essa propriedade precisa ser demonstrada por contrato e evidência, não inferida da arquitetura declarada. [HARNESS31-C2]

Invariante 4 — autorização acompanha consequência e alvo

Uma rota administrativa não deve ser protegida apenas porque a interface gráfica normalmente pede confirmação. Toda forma de provocar o mesmo efeito precisa atravessar o mesmo gate no servidor.

Um pedido privilegiado deveria carregar:

{
  "principal": "ephemeral-session",
  "capability": "typed-action",
  "target": "bounded-resource",
  "policy_digest": "sha256:...",
  "approval_ref": "immutable-or-null",
  "expires_at": "rfc3339",
  "request_nonce": "single-use"
}

O exemplo descreve campos, não uma implementação completa. O approval_ref precisa ligar a identidade humana ou de serviço, consequência, alvo e validade. Nonce e expiração reduzem replay; não substituem autenticação do canal nem verificação da política.

Testes negativos

• ação equivalente por CLI, UI e API recebe a mesma decisão;
• aprovação para leitura não autoriza execução nem mudança de política;
• alvo, capability ou policy digest diferentes invalidam a aprovação;
• replay e uso concorrente do mesmo pedido são recusados;
• resposta de erro não inclui token, conversa, caminho sensível ou política integral.

Invariante 5 — sandbox inclui rede e plano de controle

Confinar apenas filesystem deixa outras autoridades disponíveis. O threat model deve decidir explicitamente sobre loopback, DNS, rede externa, sockets, IPC, serviços de metadata, proxies e interfaces de controle no host.

O desenho mínimo para tarefa não confiável é:

1. namespace ou política de rede dedicada quando suportado;
2. egress default-deny, liberado por destino e finalidade;
3. interface de controle inacessível ao principal do agente;
4. credenciais ausentes por padrão e, quando indispensáveis, efêmeras e task-scoped;
5. limites de tempo, volume, processo e armazenamento;
6. evidence receipt produzido fora da autoridade do agente.

Uma interface local pode permanecer necessária para experiência de desenvolvimento. Nesse caso, o controle precisa sobreviver ao fato de navegador, extensão e agente compartilharem o host.

Evidence Packet mínimo

{
  "service_version": "immutable-ref",
  "transport": "local-interface",
  "authenticated_principal": "opaque-id",
  "origin_context": "browser|process|sandbox|operator",
  "requested_capability": "typed-action",
  "effective_scope": "bounded-scope",
  "policy_digest": "sha256:...",
  "decision": "allowed|blocked|failed|inconclusive",
  "effect_receipt": "immutable-ref"
}

O receipt não deve persistir segredo, PII desnecessária, payload ofensivo ou conteúdo integral da sessão. Ele precisa permitir reconstruir qual versão, principal, política, capacidade e resultado participaram da decisão.

Gate de release

1. Endereço local é tratado apenas como restrição de alcance?
2. Cada cliente apresenta identidade verificável e ligada à sessão?
3. CORS está restrito e continua separado de autenticação e autorização?
4. O agente não alcança nem credencia o plano que amplia seu próprio confinamento?
5. Capacidades privilegiadas são tipadas, delimitadas e avaliadas no servidor?
6. UI, CLI e API atravessam o mesmo gate por consequência?
7. Sandbox inclui rede, loopback, sockets e interfaces do host no threat model?
8. Tokens são efêmeros, audience-bound, não exportáveis e invalidados na mudança de política?
9. Testes negativos cobrem navegador, extensão, processo e agente dentro do sandbox?
10. O Evidence Packet diferencia bloqueio, falha operacional, inconclusão e sucesso?

Passar nesse gate demonstra apenas o recorte testado. Não prova segurança total, ausência de vulnerabilidades, prontidão de produção ou operação contínua.

Limitações e conflito de interesse

• A OX vende segurança de aplicações e publicou a pesquisa que realizou. Execução comparada e reteste fortalecem o disclosure, mas não são corroboração independente.
• O segundo caso está em advisory público do projeto Microsoft e possui classificação própria. Sua severidade baixa não deve ser comparada diretamente ao CVSS 9,4 atribuído pela OX ao outro produto.
• Este brief generaliza propriedades arquiteturais a partir de dois casos; não estima prevalência.
• O texto omite portas, comandos, payloads, URLs de exploração e sequência ofensiva.
• Nenhum caso autoriza acusação de negligência, intenção, exploração ativa ou dano confirmado.
• Nenhum controle proposto é declarado como implantado ou operando na Trustyu Forge.

Fontes diretas

1. OX Research — CVE-2026-82533.
2. Microsoft/GitHub — GHSA-96p9-rh4f-92cf.
3. DeepSeek Harness — releases oficiais.
4. winml-cli — releases oficiais.

Nota editorial e de responsabilidade

Fatos sobre produtos e versões são atribuídos às fontes acima. Os invariantes, o contrato e os testes negativos são análise profissional do autor, não fatos universais nem alegação de controles já operando. Este conteúdo é informativo e não substitui avaliação técnica, jurídica ou de segurança. Trustyu e Tech Human atuam comercialmente em temas relacionados. Pesquisa, estrutura e redação tiveram assistência de IA; revisão factual, autoral e aprovação final foram confirmadas por Fernando Parreiras em 09/09/2026. Não houve revisão humana independente adicional.