Assinatura de código para agentes de IA: aprove sessões com evidências

Um aviso de aprovação que diz apenas «o agente de IA solicita acesso» pede que uma pessoa autorize um mistério. Em uma máquina de desenvolvimento compartilhada, é assim que alguém aprova um script copiado, um terminal esquecido ou um processo iniciado pela pessoa errada. A pergunta útil é mais específica: qual processo executável está solicitando acesso, quem o assinou, como ele chegou aqui e o que pode fazer durante esta execução?

A assinatura de código fornece evidências para essa decisão. Ela pode associar um programa em execução a uma autoridade de assinatura e mostrar se o conteúdo assinado foi alterado. Não pode dizer se um agente recebeu um prompt malicioso, se um editor confiável distribuiu uma versão problemática ou se a ação de produção solicitada faz sentido. As equipes têm problemas quando confundem uma assinatura com uma garantia de comportamento.

Em um Mac compartilhado, use a autoridade de assinatura para reconhecer clientes de agente conhecidos, rejeitar surpresas e fazer cada aprovação expirar junto com o processo que a justificou. Combine isso com um limite claro entre contas, credenciais com escopo limitado e registros que permitam reconstruir tanto a aprovação quanto a chamada que veio depois.

Uma assinatura identifica o código, não a intenção por trás dele

Uma assinatura de código pode estabelecer quem assinou um trecho específico de código e se o macOS ainda consegue verificar o conteúdo assinado. Ela não estabelece que o código merece acesso aos seus sistemas. Essa distinção precisa permanecer visível em todo fluxo de aprovação.

A documentação de assinatura de código da Apple, a Technical Note TN2206, descreve assinaturas como uma forma de validar código e expressar um requisito designado, que o macOS pode usar para reconhecer o mesmo código mais tarde. O requisito designado é importante porque é mais preciso do que um nome de arquivo. Um executável chamado agent pode ser copiado para qualquer lugar e renomeado. Sua identidade assinada mantém uma continuidade mais forte se a cadeia de assinatura e o requisito continuarem válidos.

Essa continuidade responde a uma pergunta prática: «Este é o cliente que concordamos em permitir?» Ela não responde a estas perguntas igualmente práticas:

• O agente recebeu instruções que nunca deveriam chegar à produção?
• Um usuário iniciou esse processo deliberadamente, a partir do diretório de projeto esperado?
• O processo contém uma extensão, um plug-in ou uma configuração que altera seu comportamento?
• A chamada de API solicitada pertence a esta tarefa?
• A credencial usada na chamada tem mais acesso do que a tarefa exige?

As pessoas costumam recorrer ao nome de um editor como se ele fosse um veredito. Não é. Uma autoridade de assinatura informa quem controlava a credencial de assinatura usada naquele artefato. Um grande editor pode assinar muitos programas. Uma pequena equipe interna pode assinar uma compilação perfeitamente adequada. Sua decisão de aprovação deve comparar a identidade observada com uma lista de permissões que sua equipe consiga explicar, não com a impressão vaga de que o emissor parece familiar.

Há também um limite fácil de ignorar: a assinatura verifica o código que foi assinado. Ela não cobre automaticamente tudo que um processo lê depois. Arquivos de configuração, arquivos de prompt, variáveis de ambiente, dados do repositório, extensões baixadas e respostas remotas podem mudar o que um programa corretamente assinado faz. Se você aprova um agente porque o binário parece familiar, ainda precisa controlar suas ações.

Leia um cartão de aprovação como um registro de atribuição

Um cartão de aprovação deve fornecer ao operador informações suficientes para atribuir uma solicitação a um processo real antes de aprová-la. A autoridade de assinatura deve aparecer no topo porque é mais difícil de falsificar do que um rótulo de processo, mas precisa estar ao lado do caminho do processo e dos detalhes da sessão.

Para um processo que solicita acesso em uma máquina compartilhada, quero ver estes fatos em um só lugar:

• A identidade do executável ou aplicativo e seu caminho local completo.
• A autoridade de assinatura ou o requisito designado usado para reconhecê-lo.
• O ID do processo e o processo pai, para mostrar o que o iniciou.
• A conta de usuário do macOS que é proprietária do processo.
• O canal e o destino da ação, como um host de API ou host SSH.

Os três primeiros fatos identificam falhas diferentes. Um nome de exibição familiar com um caminho inesperado costuma indicar um binário copiado ou um wrapper. Um caminho familiar com uma autoridade desconhecida costuma indicar que alguém recompilou ou substituiu o programa, ou apontou um link simbólico para outro local. Um executável familiar iniciado por um processo pai inesperado pode indicar que outra ferramenta de automação o iniciou, e não o desenvolvedor que está olhando para o aviso.

Em um Mac compartilhado, a conta de usuário não é um detalhe decorativo. Se dois engenheiros compartilham um único login, uma aprovação diz muito pouco sobre qual pessoa iniciou o agente. A máquina ainda pode informar qual processo fez a chamada, mas sua equipe perdeu um limite humano claro antes mesmo de o fluxo de aprovação começar. Contas separadas no macOS custam menos do que discutir o histórico do terminal depois de um incidente.

Não ensine as pessoas a aprovar com base em um logotipo, em um nome curto de comando ou apenas em uma sequência de autoridade. Ensine-as a reconhecer uma combinação completa e esperada: cliente de agente aprovado, autoridade de assinatura esperada, localização local esperada, sua própria conta e um destino relacionado à tarefa. Um cartão que omite a maior parte dessas evidências transforma uma aprovação de um clique em um palpite.

Inspecione o executável antes de transformá-lo em uma identidade aprovada

Inspecione o aplicativo ou executável exato que sua equipe pretende aprovar antes de alguém depender da autoridade de assinatura em um fluxo real. Faça isso durante a configuração, registre o resultado esperado no manual interno e repita a verificação quando atualizar o cliente de propósito.

No macOS, codesign pode exibir detalhes da assinatura. A saída detalhada vai para o erro padrão, portanto redirecione-a se quiser salvar um registro da análise:

codesign -dv --verbose=4 /Applications/ApprovedAgent.app 2\u003e\u00261

O formato da saída normalmente inclui campos como estes:

Executable=/Applications/ApprovedAgent.app/Contents/MacOS/ApprovedAgent
Identifier=com.example.approved-agent
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=...
Authority=Developer ID Application: Example Developer (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
TeamIdentifier=ABCDE12345
Sealed Resources version=2 rules=13 files=...

Mantenha Identifier, a Authority da folha e TeamIdentifier juntos. O Team ID sozinho é uma regra de aprovação fraca porque uma organização pode assinar vários aplicativos. O identificador sozinho é mais fraco porque alguém pode criar um programa sem assinatura com o mesmo identificador de pacote. É a cadeia que torna a afirmação útil.

Depois, verifique o conteúdo assinado:

codesign --verify --deep --strict --verbose=2 /Applications/ApprovedAgent.app

Um resultado bem-sucedido costuma não exibir nada. Uma falha identifica um componente aninhado alterado ou outro problema de assinatura. --deep pede ao codesign que percorra o código aninhado. É útil como auxílio de inspeção, mas não trate isso como prova de que todos os componentes incluídos atendem à política de segurança. A Apple documenta que a verificação profunda se aplica recursivamente e pode ocultar o fato de que o desenho interno de assinatura de um pacote merece uma análise direta.

Para um aplicativo obtido fora do seu canal de software gerenciado, peça também ao Gatekeeper uma avaliação:

spctl --assess --type execute --verbose=4 /Applications/ApprovedAgent.app

spctl e codesign respondem a perguntas relacionadas, mas diferentes. codesign verifica as assinaturas em relação ao artefato. spctl pergunta se a política de avaliação do sistema o aceita. Uma avaliação aprovada é um sinal útil de procedência. Ela não significa que os comandos, scripts ou comportamentos remotos do aplicativo sejam seguros para a produção.

Registre o caminho analisado. Se alguém mais tarde aprovar /Users/alex/bin/agent porque o rótulo se parece com o aplicativo analisado em /Applications, essa pessoa não repetiu a verificação. O caminho faz parte da evidência.

A assinatura de um interpretador não autoriza o script que ele executa

Um terminal, runtime ou shell assinado não pode garantir um script arbitrário entregue a ele no momento da inicialização. Essa é a lacuna por trás de muitas aprovações que parecem razoáveis em uma conversa, mas falham na prática.

Considere um desenvolvedor que inicia um agente com um comando como este:

/usr/bin/python3 /Users/dev/work/demo/tools/agent_runner.py

O Python do sistema pode ter uma assinatura conhecida. Esse fato informa algo sobre o binário do interpretador. Não diz nada sobre agent_runner.py, os arquivos que ele importa do repositório, o arquivo .env que lê ou as instruções passadas pela entrada padrão. Se a interface de aprovação identifica apenas python3, um invasor precisa alterar o script ou o estado do projeto, não o interpretador.

O mesmo problema aparece com node, shells, extensões de editores e executores genéricos de automação. Uma regra ampla como «aprovar processos assinados por este editor do runtime» facilita a aprovação de muitos comportamentos que ninguém analisou. Ela é popular porque reduz o atrito das aprovações. Está errada para qualquer canal que possa alcançar credenciais importantes.

Use um de dois modelos e deixe claro qual sua equipe escolheu. O modelo mais forte aprova um cliente de agente assinado e criado para essa finalidade, cujo processo de sessão é o programa que solicita acesso. O modelo mais flexível permite interpretadores, mas trata cada execução de script como uma sessão distinta e exibe o caminho do script, o diretório do projeto, os argumentos e o processo pai junto da autoridade do interpretador.

Você pode inspecionar o contexto básico de um processo em execução com ferramentas padrão:

ps -p 4821 -o pid=,ppid=,user=,command=
ps -p 4812 -o pid=,ppid=,user=,command=

O primeiro comando pode mostrar o processo do agente e o segundo, seu processo pai. Compare a linha de comando com o trabalho do desenvolvedor. Se o filho veio de um terminal no projeto esperado, as evidências fazem sentido. Se veio de um agendador sem supervisão, de um auxiliar do navegador ou de outro agente, pare de tratar a solicitação como uma aprovação rotineira de desenvolvedor.

Para um cliente baseado em script, inclua o resumo criptográfico do script no registro de aprovação. Uma verificação local simples basta para tornar as alterações visíveis:

shasum -a 256 /Users/dev/work/demo/tools/agent_runner.py

Um resumo não torna um script confiável. Ele dá à equipe uma resposta concreta quando alguém pergunta se o script aprovado mudou entre as execuções. Armazene o resumo esperado apenas para uma versão analisada ou para um estado controlado do projeto. Não transforme em ritual a cópia de hashes de mensagens de chat.

Máquinas compartilhadas precisam de limites entre contas antes das regras de aprovação

Um Mac de desenvolvimento compartilhado é administrável quando cada pessoa usa uma conta separada e cada execução de agente tem um responsável claro. Se todos usam o mesmo login, a autoridade de assinatura não consegue corrigir a falta de atribuição.

Crie contas separadas no macOS para cada desenvolvedor e evite um login de administrador compartilhado no trabalho diário. O processo do agente deve ser executado pela pessoa que o iniciou. Assim, os arquivos do projeto, o histórico do terminal, as variáveis de ambiente e as decisões de aprovação passam a ter um responsável real. Repositórios compartilhados não exigem contas compartilhadas no sistema operacional.

Uma configuração funcional também separa destinos sensíveis. Dê às credenciais de desenvolvimento, staging e produção entradas distintas e rótulos que deixem clara a intenção para o operador. Uma aprovação para inventory-staging não deve selecionar silenciosamente a credencial de produção só porque ambas apontam para o mesmo cliente de API. Se os nomes das credenciais escondem o ambiente, a pessoa não consegue fazer uma escolha segura no momento decisivo.

O acesso físico também importa. Uma pessoa diante de um Mac compartilhado desbloqueado pode iniciar um processo na conta ativa e esperar que o proprietário clique em um aviso de aprovação. Bloqueie a tela ao sair, exija um novo login depois do repouso e evite deixar um terminal privilegiado aberto em um espaço comum. São controles simples, por isso as equipes os ignoram até precisarem limpar uma confusão evitável.

Não tente resolver o risco de uma máquina compartilhada publicando uma lista enorme de autoridades de assinatura aprovadas. Essa lista tende a crescer até incluir editores, runtimes, gerenciadores de pacotes, ferramentas de compilação e aplicativos auxiliares. Nesse ponto, ela apenas informa que a máquina é usada para desenvolvimento. Mantenha restrito o conjunto aprovado de agentes que podem solicitar ações externas e documente por que cada identidade está incluída.

A aprovação de uma sessão deve vincular um processo, não uma pessoa para sempre

Uma aprovação de sessão deve autorizar um processo de agente observado durante a existência desse processo e expirar quando ele for encerrado. É um bom equilíbrio entre exigir uma decisão para cada solicitação inofensiva e conceder uma permissão permanente que sobreviva ao trabalho.

O limite do processo importa mais do que um prazo de calendário. Um agente que encerra e reinicia é um novo contexto de execução. Ele pode ter um diretório de trabalho diferente, um binário modificado, extensões diferentes, outro processo pai ou outra pessoa no teclado. Exigir uma nova autorização no reinício dá ao operador outra oportunidade de perceber essas mudanças.

É aqui que a assinatura de código mostra seu valor. O fluxo de aprovação pode destacar a autoridade porque ela ajuda o operador a reconhecer um cliente esperado, enquanto o vínculo com a sessão impede que esse reconhecimento se transforme em uma concessão indefinida. Se o processo do agente terminar, a aprovação deve desaparecer com ele. Se o operador notar um comportamento suspeito, precisa de uma forma imediata de revogar a sessão antes de investigar a assinatura em detalhes.

Mantenha autorização e autenticação separadas. Touch ID ou uma senha podem provar que o usuário atual do macOS aprovou algo. Não identificam o processo. A assinatura de código pode ajudar a identificar o processo. Nenhuma das duas decide se o destino e a ação são apropriados. Um bom cartão de aprovação apresenta os três tipos de evidência, sem fingir que são intercambiáveis.

Para o trabalho comum em repositórios, uma decisão de sessão pode abranger operações de leitura repetidas em uma API de desenvolvimento. Para uma operação que altere uma configuração de implantação, faça a rotação de credenciais, remova registros ou abra uma conexão SSH com um host de produção, exija uma nova decisão para aquela chamada. O atrito deve aparecer quando a consequência muda, não aleatoriamente quando um temporizador expira.

A autoridade de assinatura não impede as falhas que as pessoas esperam que ela impeça

Uma cadeia de assinatura válida não consegue impedir que um cliente confiável receba uma entrada maliciosa, que uma conta de desenvolvedor comprometida assine código malicioso ou que um processo aprovado faça uma solicitação imprudente. Trate esses casos como caminhos de falha distintos e coloque o controle correto diante de cada um.

O primeiro caminho é um ataque por prompt ou instrução do repositório. Um assistente de código lê um comentário malicioso que manda exfiltrar um arquivo de configuração por uma solicitação HTTP. O executável pode ser exatamente o cliente aprovado e corretamente assinado. A aprovação precisa mostrar o destino e o canal solicitado, porque a assinatura não fornece nenhuma evidência sobre a instrução seguida.

O segundo caminho é uma atualização legítima que sua equipe ainda não analisou. Um editor pode assinar uma nova versão usando a mesma autoridade. Se você aprova qualquer versão futura dessa autoridade sem verificar sua identidade e a origem da versão, transformou a propriedade do editor em toda a sua política. Isso pode ser aceitável para ferramentas locais de baixo risco. Não basta para um agente que pode usar credenciais de produção.

O terceiro caminho é a manipulação de processos locais. Um aplicativo assinado pode carregar um plug-in, herdar uma variável de ambiente ou ser executado com um processo pai que fornece argumentos inesperados. As proteções do macOS reduzem algumas formas de adulteração, mas um sistema de aprovação ainda precisa mostrar o contexto real do processo. Quando as evidências entram em conflito, negue a solicitação e inspecione a máquina. Não invente uma explicação benigna porque a sequência de autoridade parece familiar.

O quarto caminho é o excesso de privilégios. Um cliente corretamente identificado pode usar uma credencial com permissão para fazer muito mais do que a tarefa exige. Limite as credenciais à API, ao host, ao repositório e ao ambiente de que o agente precisa. A assinatura de código pode informar qual cliente usou uma credencial, mas não consegue reduzir a autoridade dessa credencial depois do fato.

Por isso, «assinado é igual a seguro» é uma recomendação prejudicial. Ela parece simples e produz menos avisos. Também incentiva aprovações sem destino, resumo da ação ou limite de sessão. Um sinal de assinatura ajuda uma pessoa a distinguir código conhecido de código desconhecido. Nunca deve apagar o restante da decisão.

A aprovação por chamada pertence a credenciais irreversíveis ou de alto impacto

Exija uma decisão humana para cada uso de uma credencial quando uma única solicitação puder causar uma consequência que uma aprovação de sessão não deve permitir silenciosamente. O limite é o impacto da ação, não o fato de o executável do agente parecer confiável.

Use aprovação por chamada para credenciais que possam gravar ou excluir dados de produção, alterar identidades ou permissões, criar compromissos externos, publicar software ou entrar em um ambiente SSH sensível. O operador deve ver o rótulo da credencial e o destino no momento do uso. Uma mensagem genérica como «usar segredo» exige que ele se lembre de informações demais sob pressão.

Mantenha o trabalho de baixo impacto utilizável. Um desenvolvedor que precisa aprovar cada leitura de uma API de teste aprenderá a clicar sem ler. Esse comportamento destrói o controle e torna mais fácil ignorar avisos importantes. A aprovação de sessão funciona bem quando o agente executa um trabalho repetitivo e limitado em um destino de desenvolvimento, e a identidade do processo é esperada.

A sequência de decisões deve ser simples o bastante para que as pessoas consigam explicá-la depois de uma semana difícil. Primeiro, um cofre bloqueado nega todas as ações. Depois, um novo processo de agente precisa de autorização de sessão. Por fim, determinadas credenciais exigem aprovação a cada uso. Não esconda essas decisões em uma linguagem de políticas personalizada que apenas uma pessoa consiga interpretar. Exceções ocultas são o ponto em que as regras de máquinas compartilhadas se deterioram.

O Sallyport aplica diretamente esse modelo de três controles: um cofre bloqueado nega ações, um novo processo de agente solicita autorização de sessão por padrão e uma credencial selecionada pode exigir aprovação a cada uso. O cartão de aprovação começa mostrando a autoridade de assinatura de código do processo, que é o ponto certo para começar quando vários usuários compartilham um Mac.

Audite a aprovação e a chamada como eventos separados

Você precisa de registros separados para sessões de agentes e ações individuais porque nenhum dos dois consegue responder sozinho a todas as perguntas de um incidente. Um registro de sessão explica qual processo recebeu autorização e quando ela terminou. Um registro de ação explica o que o processo tentou fazer depois da aprovação, em qual canal ou destino e qual resultado recebeu.

Uma sequência útil de investigação é:

1. Encontre o registro de sessão do processo que solicitou acesso.
2. Verifique a conta de usuário, o caminho do executável, a autoridade de assinatura, o processo pai e o horário da aprovação.
3. Encontre as chamadas realizadas durante essa sessão e compare os destinos com a tarefa atribuída.
4. Revogue a sessão se ela ainda estiver ativa. Depois, desative ou faça a rotação da credencial afetada se as chamadas mostrarem uso indevido.
5. Preserve os registros antes de alterar arquivos do projeto ou reinstalar o cliente.

A ordem importa. As equipes costumam começar lendo o código e acabam perdendo as evidências do que realmente aconteceu. Primeiro estabeleça a sequência de autorização e ação. Depois inspecione o executável, o estado do repositório, o histórico do shell e a configuração relevante.

A evidência contra adulteração tem valor nesse caso. Um registro de auditoria que um processo local pode reescrever oferece pouco conforto quando esse processo faz parte do evento analisado. O encadeamento de hashes dá ao verificador uma forma de detectar alterações ou remoções na sequência registrada, embora não prove que todos os eventos possíveis foram capturados. Seja preciso sobre esse limite. Evidência contra adulteração não é onisciência.

O Sallyport projeta os registros de sessões e atividades a partir de um único log de auditoria criptografado e encadeado por hashes, e sp audit verify verifica a cadeia offline sem precisar de uma credencial do cofre. Isso torna prática a verificação de rotina depois de um incidente ou antes de entregar os registros a outro revisor.

Torne as decisões de aprovação reproduzíveis, não pessoais

Uma equipe deve conseguir explicar por que uma sessão de agente recebeu aprovação sem depender da memória da pessoa que clicou. Escreva um perfil curto de aprovação para cada cliente de agente permitido e mantenha-o junto das instruções operacionais do repositório.

O perfil deve indicar o caminho esperado do aplicativo ou executável, o identificador, a autoridade de assinatura, o processo pai normal, as contas de usuário pretendidas, os ambientes permitidos e as credenciais que exigem uma decisão a cada chamada. Isso não é burocracia por si só. Dá a um novo engenheiro um padrão observável e oferece à pessoa de plantão uma forma de rejeitar uma solicitação estranha sem discutir preferências.

Revise o perfil quando qualquer um destes itens mudar: o cliente do agente for atualizado, a equipe adotar um novo wrapper de runtime, uma credencial receber uma permissão mais forte ou um fluxo antes local passar a acessar um serviço compartilhado. Se a identidade de assinatura mudar, pare e verifique a alteração por meio da fonte de software em que sua equipe confia. Não normalize uma autoridade inesperada clicando uma vez e planejando investigar depois.

Faça um teste deliberado de falha no Mac compartilhado. Inicie o cliente aprovado pela conta esperada e confirme a autoridade exibida e o comportamento da sessão. Depois, inicie um script não aprovado por meio de um interpretador assinado, execute o cliente por outra conta e solicite uma credencial marcada para aprovação por chamada. O comportamento correto deve ser óbvio para o operador em cada caso. Se os avisos parecerem muito semelhantes, melhore as informações exibidas antes que as pessoas enfrentem um erro real.

A assinatura de código é útil porque substitui um nome de processo vago por uma evidência que pode ser verificada. Mantenha esse papel restrito. Aprove o processo conhecido para o trabalho diante de você, mantenha o escopo da credencial pequeno e torne fácil revogar uma sessão suspeita enquanto as evidências ainda estão intactas.