A identidade do host de extensões da IDE pode provar quem é um agente?

Um host de extensões de editor pode ter uma assinatura de código válida e ainda assim não permitir que você diga qual extensão solicitou uma ação sensível. Isso não é uma falha da assinatura de código. É o resultado previsível de pedir a um mecanismo de identidade do sistema operacional que responda a uma pergunta que existe dentro de um único processo.

Isso importa quando um agente de programação com IA roda por meio de uma IDE, na qual o host pode carregar várias extensões, aceitar comandos de um workspace e encaminhar o trabalho para um gateway com acesso a uma API ou a um destino SSH. Se o gateway aprovar o host uma vez e tratar essa aprovação como prova da intenção de uma extensão específica, ele concederá mais autoridade do que as evidências permitem.

Já vi esse erro aparecer disfarçado de um design de segurança organizado: verificar o editor assinado, mostrar o assinante em um prompt de aprovação e permitir a execução. Esse é um controle útil. Ele se torna perigoso quando o prompt sugere uma precisão que não tem. O host pode ser confiável, enquanto a solicitação que atravessou seu limite continua ambígua.

A assinatura do host identifica o contêiner, não quem está dentro dele

A assinatura de código prova fatos sobre uma imagem executável. No macOS, a Apple descreve a assinatura de código como uma forma de estabelecer a origem e a integridade do software. O sistema pode verificar se uma autoridade de assinatura confiável assinou o código e se o código carregado ainda corresponde ao material assinado. Essa é exatamente a evidência necessária quando uma decisão de segurança pergunta: “Qual processo de aplicativo está fazendo a solicitação?”

Ela não prova: “Qual função de extensão dentro desse processo fez a solicitação?” Um processo tem uma única identidade executável nesse limite. Se um editor inicia um host de extensões e o host carrega dez plugins, o kernel não cria dez identidades de assinatura de código separadas para o JavaScript, o bytecode, os callbacks ou as chamadas da API de extensão.

Essa distinção tem uma consequência prática. Um gateway pode manter um registro defensável como este:

caller executable: /Applications/Editor.app/.../extension-host
signing authority: Example Software Team ID ABC123
process id: 8421
parent process: Editor.app pid 8304

Ele não pode deduzir isto apenas da assinatura:

extension: publisher.cloud-deploy
command: deployCurrentProject
prompt source: chat request 18

O primeiro bloco contém evidências do sistema operacional. O segundo contém proveniência da aplicação. Ambos podem ser úteis, mas merecem tratamentos diferentes no log e na tela de aprovação.

As pessoas costumam chamar os dois de “identidade” e depois perdem a distinção durante a implementação. Não faça isso. O assinante informa quem produziu a caixa. Não informa qual passageiro alcançou os controles.

Hosts de extensões compartilhados juntam várias autoridades em uma só

Um host de extensões existe para que o editor possa carregar e coordenar extensões. Esse design é conveniente, mas transforma o host em um pacote de autoridades. Um plugin de autocompletar, um formatador, uma integração com controle de versão, um assistente de chat e uma extensão do workspace podem executar no mesmo processo do host.

Considere um gateway que permite uma chamada HTTPS depois de verificar a assinatura do editor. A Extensão A pede ao host que chame um endpoint de implantação. A Extensão B tem acesso a uma API de extensões capaz de induzir o mesmo host a realizar uma operação de saída, talvez diretamente, talvez por meio de um comando registrado pela Extensão A. No gateway, as duas solicitações chegam com o mesmo identificador de processo e a mesma autoridade de assinatura. O gateway não consegue separá-las inspecionando a assinatura do host.

A ambiguidade aumenta quando as extensões se comunicam por meio de serviços compartilhados do host. Um plugin pode registrar um comando. Outro plugin pode invocá-lo. Uma extensão de chat pode receber instruções de um arquivo do repositório, do corpo de uma issue ou de um resultado colado do terminal e então despachar um comando. A atribuição passa a ter várias camadas: o host assinado, a extensão que fez a chamada, a extensão que forneceu a entrada e a pessoa ou o conteúdo não confiável que influenciou a ação.

Nada disso torna as extensões de IDE inerentemente inseguras. Significa que a aprovação no nível do host é uma aprovação para a autoridade combinada do host. Se isso parecer amplo demais para uma operação, você precisa de um segundo controle que enxergue a própria operação.

O nome de uma extensão só é proveniência quando o host o vincula

Um identificador de extensão como publisher.name é um contexto útil, mas um gateway não deve confundir uma string fornecida pelo chamador com uma evidência. Qualquer código capaz de formar uma solicitação pode escrever publisher.name em um cabeçalho, corpo JSON, argumento de comando ou variável de ambiente. Isso informa apenas o que o código declarou.

Um host pode tornar essa declaração mais forte se obtiver o identificador de seu próprio registro de extensões, vinculá-lo ao contexto de execução ativo e enviá-lo por um canal local protegido que as extensões não possam falsificar. Mesmo assim, o resultado responde a uma pergunta mais restrita: qual contexto de extensão gerenciado pelo host iniciou esta solicitação. Isso talvez não identifique o prompt, o conteúdo do repositório ou a pessoa que influenciou o contexto.

O teste útil é simples. Pergunte de onde veio cada campo e quem poderia alterá-lo.

Por isso, “incluímos o nome da extensão no log de auditoria” não é uma declaração de segurança completa. Mantenha o nome. Marque-o como informado pelo host, a menos que a arquitetura dê ao gateway um motivo para considerá-lo verificado. Esse rótulo impede que futuros investigadores tratem metadados convenientes como prova.

A aprovação da sessão tem um limite útil e uma limitação importante

Vale a pena aprovar um processo de host recém-iniciado e verificado. Isso detecta um executável diferente, uma autoridade de assinatura alterada, uma nova duração de processo e um caminho de inicialização inesperado. Também dá à pessoa diante do teclado a chance de ver quem está prestes a receber acesso. Para trabalhos rotineiros com uma credencial de escopo restrito, essa interrupção pode ser uma boa troca.

O limite é que uma aprovação de sessão concede a todo o processo aprovado tudo o que a sessão puder fazer. Se o processo hospeda muitas extensões, ele não consegue distinguir uma solicitação da extensão esperada de uma solicitação criada por outra extensão carregada. Um cartão de aprovação claro pode comunicar o assinante e a identidade do processo do host, mas não deve prometer uma atribuição no nível do plugin que não consegue oferecer.

Há uma segunda falha que as equipes deixam passar. Elas aprovam um processo do editor pela manhã e depois instalam ou ativam uma extensão durante a mesma sessão longa. Se o host recarregar ou carregar código novo sem alterar a identidade externa verificada pelo gateway, a aprovação continuará mais ampla do que a pessoa se lembra. A resposta adequada depende do comportamento do host, mas o princípio permanece: mudanças dentro de um host aprovado não ficam automaticamente visíveis para um broker externo.

Use a aprovação da sessão para a pergunta que ela consegue responder: “Este processo de host assinado pode usar esta categoria de acesso enquanto existir?” Não a transforme em: “Esta extensão específica pode executar esta ação irreversível específica?”

A aprovação por uso compensa a ambiguidade no momento importante

Para credenciais sensíveis, peça aprovação quando a ação for formada, e não somente quando o host aparecer pela primeira vez. O prompt deve mostrar informações suficientes da ação proposta para que uma pessoa tome uma decisão significativa: destino, método ou destino SSH, rótulo da credencial e a parte da solicitação que produz consequências.

Suponha que um host envie esta solicitação para um gateway local de ações:

{
  "channel": "http",
  "credential": "production-deploy",
  "method": "POST",
  "url": "https://deploy.example.internal/releases",
  "body": {"service": "billing", "version": "a1b2c3d"}
}

Um cartão de aprovação adequado deve vincular a decisão ao método, destino, credencial e corpo exatos, ou a um resumo estável do corpo. Ele não deve dizer apenas: “O Editor quer usar production-deploy.” Essa formulação transforma a aprovação de uma ação em um cheque em branco para todas as chamadas que o host puder fazer antes que a decisão expire.

A aprovação por uso é impopular porque interrompe o fluxo. Essa objeção é justa para chamadas inofensivas. Ela é fraca quando se trata de uma gravação em produção, de uma credencial com escopo amplo ou de um comando SSH capaz de alterar uma máquina. A pessoa que aprova não precisa identificar com certeza a extensão culpada. Precisa ver a consequência que está prestes a sair da máquina e decidir se ela faz sentido.

Um bloqueio do cofre cria outro limite que a aprovação da sessão não consegue oferecer. Enquanto o cofre estiver bloqueado, negue todas as ações, inclusive chamadas de hosts aprovados anteriormente. O Sallyport aplica esse bloqueio absoluto antes da autorização da sessão, e uma credencial selecionada pode exigir aprovação a cada uso. Assim, o conjunto de controles permanece honesto: o assinante do host identifica o chamador, a decisão de sessão admite esse processo por um período limitado e a decisão por uso cobre a ação sensível.

Credenciais restritas reduzem o dano de uma aprovação correta

A aprovação não substitui o escopo da credencial. Uma pessoa pode aprovar o host correto e a solicitação correta e ainda descobrir que a credencial permite muito mais do que a operação pretendida. Isso é uma falha no design da credencial, não na aprovação.

Separe o acesso de acordo com as consequências. Um token que lê um repositório não deve administrar todos os projetos. Uma credencial de implantação não deve criar usuários nem recuperar segredos sem relação com a tarefa. Para SSH, use uma conta separada ou uma configuração de comando forçado quando o lado remoto oferecer esse suporte, em vez de entregar um shell geral a um fluxo que precisa apenas de uma tarefa de manutenção.

A recomendação popular de dar a um agente um único token amplo de desenvolvimento é atraente porque a configuração leva cinco minutos. Ela está errada quando o token atravessa ambientes ou tem autoridade de escrita. Um token amplo transforma toda ambiguidade dentro do host de extensões em uma ambiguidade ampla fora dele. Credenciais restritas tornam o prompt de aprovação mais fácil de ler porque o conjunto de ações disponíveis já tem limites claros.

Para ações HTTP, restrinja o destino no registro da credencial ou na configuração do gateway quando o design permitir. Um token bearer injetado em qualquer URL arbitrária pode ser exfiltrado por um host induzido a chamar um endpoint controlado por um invasor. Para ações SSH, registre o host, a conta e a classe de comando pretendida antes de decidir que uma aprovação de sessão é suficiente.

Uma falha conhecida começa com uma ação inofensiva da paleta de comandos

Um desenvolvedor instala uma extensão de assistente e uma extensão de implantação. Ambas rodam em um único host de extensões assinado. O desenvolvedor aprova o host quando o assistente pede para inspecionar uma API de staging, porque o cartão de aprovação mostra corretamente a autoridade de assinatura do editor.

Mais tarde, o desenvolvedor abre um repositório que contém um arquivo de tarefas com instruções para o assistente. O assistente analisa o arquivo e invoca um comando do host registrado pela extensão de implantação. O comando pede ao mesmo gateway que use uma credencial de produção. A solicitação tem a mesma identidade de processo assinado que a solicitação de staging. Um gateway que depende apenas da aprovação da sessão vê um chamador aprovado e prossegue.

Nada nessa sequência exige uma assinatura falsificada ou um sistema operacional comprometido. A falha vem de uma decisão de aprovação que cobriu o host e de uma credencial que cobria uma ação que o desenvolvedor não pretendia autorizar. Um registro de auditoria que diga apenas “o editor aprovado fez uma chamada HTTP” não informará à equipe se a extensão de implantação, o assistente ou um arquivo de tarefas iniciou a sequência.

Altere a configuração em três pontos. Exija aprovação explícita para a credencial de produção em cada uso. Mostre o destino e o payload da versão nessa aprovação. Registre a identidade do host separadamente do contexto da extensão informado pelo host e mantenha a ligação entre o evento de aprovação e a chamada. A solicitação ainda pode ser legítima, mas não poderá passar como trabalho rotineiro em segundo plano.

Os registros de auditoria precisam de uma coluna de evidências, não de uma história conveniente

Os logs se tornam enganosos quando misturam fatos verificados e contexto autodeclarado em uma única frase. “O Plugin X implantou o serviço Y” parece preciso, mas pode esconder um rótulo de plugin não verificado e uma cadeia causal desconhecida. Registre o evento bruto com sua fonte de verdade.

Uma estrutura de evento útil separa as declarações:

{
  "time": "2026-07-24T10:16:43Z",
  "caller": {
    "signing_authority": "Example Software Team ID ABC123",
    "pid": 8421,
    "started_at": "2026-07-24T09:58:03Z"
  },
  "host_reported_context": {
    "extension_id": "publisher.cloud-deploy",
    "workspace": "/work/payments"
  },
  "action": {
    "channel": "http",
    "method": "POST",
    "destination": "https://deploy.example.internal/releases",
    "credential": "production-deploy"
  },
  "authorization": {
    "session_approved": true,
    "per_use_approved": true
  }
}

A ideia não é produzir mais campos de log. É preservar o limite entre um fato verificado pelo sistema e uma declaração feita pelo host. Durante um incidente, essa diferença determina se os investigadores conseguem rastrear uma ação ou apenas repetir um rótulo.

A evidência contra adulteração também importa. Um diário local que um processo comprometido possa reescrever é uma evidência fraca sobre seu próprio comportamento. O Sallyport projeta as visões de sessões e atividades a partir de um log de auditoria criptografado e encadeado por hash, e sp audit verify pode verificar a cadeia offline sem uma chave do cofre. Isso não resolve a atribuição da extensão, mas impede que uma edição posterior melhore silenciosamente a história.

Isole a operação quando a atribuição precisar ser exata

Algumas ações exigem uma resposta mais forte do que um host compartilhado pode oferecer. Se uma credencial pode movimentar dinheiro, alterar o acesso à produção, apagar dados ou executar comandos remotos irrestritos, encaminhe a operação por um componente com identidade executável própria e uma interface restrita. Assim, o gateway pode verificar esse helper em vez de inferir a intenção a partir de um host de extensões cheio de componentes.

O helper deve aceitar um esquema de solicitação explícito, rejeitar parâmetros extras e manter sua própria autoridade pequena. Por exemplo, um helper de versões pode aceitar um nome de serviço de uma lista permitida e um resumo da versão, enquanto rejeita URLs arbitrárias e trechos de shell. O editor pai ainda pode iniciar o trabalho, mas não pode transformar o helper em um cliente de rede genérico.

A separação de processos não é mágica. Se o host puder enviar solicitações arbitrárias ao helper, você simplesmente terá movido a mesma ambiguidade para um processo novo. A interface precisa remover as escolhas que o host não deveria ter. Um helper assinado separado com uma solicitação ampla de “executar qualquer coisa” é teatro.

Quando o isolamento custar demais, recorra à aprovação específica da ação e a credenciais restritas. Essa combinação dá a uma pessoa a chance de perceber a consequência mesmo quando a origem dentro do editor continua incerta. Não alegue certeza no nível do plugin se o design não puder mostrar de onde ela vem.

Trate o texto da aprovação como parte do limite de acesso

Um prompt de aprovação muda o comportamento, então seu texto precisa receber o mesmo cuidado que o código responsável por aplicá-lo. Se disser “Permitir que o editor acesse a implantação”, os usuários aprenderão a aprovar uma categoria. Se disser “Permitir que este host de extensões assinado faça POST desta versão para este destino usando esta credencial”, os usuários poderão avaliar a ação que estão autorizando.

Mantenha o assinante do processo em destaque, porque isso ajuda a detectar o aplicativo errado. Mantenha o nome da extensão visível se o host o fornecer, porque ele ajuda a pessoa a reconhecer um trabalho esperado. Identifique-o como contexto informado quando o gateway não puder verificá-lo. As pessoas lidam melhor com a incerteza quando a interface a declara claramente do que quando um rótulo bem produzido sugere uma garantia.

Comece fazendo um inventário de todas as credenciais acessíveis a partir de um host de IDE. Para cada uma, registre a aprovação no nível do host que ela pode herdar com segurança, o formato de ação que exige uma nova decisão e a evidência exata preservada pelo registro de auditoria. Se a resposta para “qual extensão fez isso?” for um palpite, não conceda autoridade como se fosse um fato.