Acesso sudo para agentes de IA: controle cada elevação

Dar sudo a um agente de IA só porque ele já consegue abrir um shell remoto é um erro de categoria. A execução remota responde a «ele consegue chegar a esta máquina?». A elevação responde a «esta solicitação pode alterar um estado protegido?». Essas decisões precisam de evidências, controles e registros diferentes.

Já vi equipes juntar tudo em um único recurso de conveniência: um agente se conecta por SSH, executa sudo e deixa uma transcrição da conversa. Parece organizado até que um comando errado reinicia o serviço incorreto, substitui um arquivo de configuração ou segue uma instrução escondida em um repositório. Então ninguém consegue dizer qual processo tinha autoridade, quem aprovou a ação ou por que o acesso root pareceu necessário.

Acesso sudo para agentes de IA deve significar uma exceção restrita e atribuível para uma operação específica. Nunca deve significar que o agente adquiriu o poder permanente de um administrador durante o restante da tarefa.

Um shell remoto e o sudo respondem a perguntas diferentes

Uma sessão SSH prova que algum cliente se autenticou em uma conta remota. Ela não estabelece que todo comando digitado ou gerado nessa sessão merece autoridade de root. Mantenha a conta comum útil para descoberta, builds, testes, leitura de logs e preparação de implantações. Coloque o pequeno conjunto de alterações protegidas atrás de um caminho de elevação separado.

Essa distinção se perde porque o shell faz a elevação de privilégios parecer um detalhe de sintaxe:

ssh deploy@api-02 'sudo systemctl restart payment-worker'

Essa única linha esconde pelo menos cinco decisões: qual processo do agente a emitiu, qual host foi o alvo, se o nome do serviço está correto, por que o reinício é necessário e se alguém aceitou a consequência. O SSH pode autenticar a conexão. O sudo pode trocar o usuário efetivo. Nenhuma dessas ferramentas, sozinha, registra o motivo ou oferece um ponto de decisão adequado ao trabalho autônomo.

Os comandos remotos comuns devem continuar sendo comuns. Um agente pode executar systemctl status, consultar um log de serviço que já tem permissão para ler, comparar uma configuração renderizada ou executar uma verificação de integridade sem pedir root. Essa separação traz uma vantagem prática: o agente pode reunir evidências antes de pedir a aprovação de uma alteração.

Não exagere na correção colocando todo comando de shell atrás de uma confirmação humana. Isso gera fadiga de aprovação, e as pessoas começam a clicar em cartões que já não leem. Coloque a fricção onde a ação ultrapassa uma fronteira protegida: gerenciamento de serviços, alterações em pacotes do sistema, gravações em arquivos privilegiados, mudanças de contas, regras de rede, material secreto, configurações de inicialização e operações com dados de produção.

A forma de escrever um comando não determina seu risco. sudo cat /var/log/... pode expor conteúdo sensível. sudo systemctl restart ... pode interromper um serviço voltado para clientes. Um sudo install aparentemente inofensivo pode substituir um executável. Classifique o efeito, o alvo e a possibilidade de os argumentos escaparem para um comportamento root arbitrário.

As regras do sudoers são listas de permissão, não um argumento de segurança

O manual do sudoers diz que o sudo determina se um usuário pode executar um comando com base no caminho do comando e, quando configurado, nos argumentos da linha de comando. Esse mecanismo é útil, mas não transforma uma lista de permissões ampla em delegação segura.

Uma regra como esta delega muito mais do que muitas pessoas pretendem:

autobot ALL=(root) NOPASSWD: /usr/bin/systemctl *

Ela permite que a conta inicie, pare, reinicie, habilite, desabilite, mascare e inspecione qualquer unidade compatível com o systemctl local. Um agente que consiga influenciar um arquivo de unidade, um arquivo de ambiente ou o executável de um serviço pode transformar um reinício permitido em execução de código como root. A regra também não registra o motivo da alteração nem tem validade.

Restrições de argumentos só ajudam quando o programa permitido tem uma interface pequena e estável, e não pode interpretar entradas controladas por um invasor como caminho, expressão de shell, plugin, editor, paginador ou fonte de configuração. Administradores costumam não perceber isso porque o comando parece familiar. Um comando não se torna restrito apenas porque o caminho do binário é absoluto.

Prefira um wrapper criado para uma finalidade específica, com uma operação fixa e validação explícita. Por exemplo, um wrapper de reinício pode aceitar um nome de serviço predefinido em vez de argumentos arbitrários do systemctl:

#!/bin/sh
set -eu

case "${1:-}" in
  payment-worker|report-worker) ;;
  *) echo "unsupported service" >&2; exit 64 ;;
esac

exec /usr/bin/systemctl restart "$1"

Depois, restrinja o sudo a esse wrapper e aos argumentos exatos, quando a plataforma oferecer esse suporte:

autobot ALL=(root) /usr/local/sbin/restart-approved-service payment-worker, \\
                    /usr/local/sbin/restart-approved-service report-worker

Isso impede a expansão de subcomandos do systemctl. Não responde se o reinício faz sentido naquele momento. O wrapper também precisa pertencer ao root, ter diretórios pai não graváveis e estar protegido contra variáveis de ambiente controladas pelo agente. Se o agente puder editar o wrapper ou substituir algo que ele executa, a regra falhou.

Evite a recomendação popular de «basta usar NOPASSWD para automação». As pessoas gostam dela porque os jobs autônomos deixam de falhar em prompts de senha. O prompt de senha nunca foi um controle significativo para um agente autônomo. Substituí-lo por uma elevação irrestrita apenas remove a última pausa visível. Substitua-o por uma autorização específica e um registro responsável, não por conveniência vazia.

Uma solicitação de elevação precisa de um motivo que o revisor possa avaliar

O motivo faz parte da decisão de autorização, não é uma frase decorativa copiada em um ticket depois do fato. O agente deve criar a solicitação antes da elevação, e a tela de aprovação deve mostrar a operação proposta junto com esse motivo.

Exija que a solicitação reúna estes campos:

• O alvo exato, como api-02 e payment-worker.
• A operação privilegiada solicitada, incluindo argumentos fixos.
• O motivo, relacionado a um incidente, implantação, tarefa de manutenção ou condição observada.
• O efeito esperado e uma ação de reversão.
• Uma validade curta o suficiente para que uma solicitação abandonada não se torne uma autoridade permanente.

O motivo deve conter evidências que uma pessoa possa avaliar. «Preciso de sudo para corrigir o build» significa que o agente ainda não fez diagnóstico suficiente. «Substituir /etc/acme/client.conf pela configuração de release revisada depois que a renovação atual do certificado informar um erro de análise; restaurar a versão anterior se a validação falhar» identifica um arquivo, uma condição e um caminho de recuperação.

Mantenha a solicitação estruturada, mesmo que também preserve uma explicação em texto livre. Campos estruturados dificultam que um agente mude discretamente o alvo entre o planejamento e a execução. Eles também permitem uma revisão posterior sem obrigar alguém a reconstruir uma decisão a partir de várias janelas de conversa.

Use um identificador de solicitação imutável. A aprovação deve autorizar esse identificador, o alvo especificado e a operação especificada. Não aprove uma instrução em linguagem natural como «resolva a interrupção» e deixe o agente decidir depois quais comandos root fazem parte dela. Isso transforma uma aprovação humana em um cheque em branco ilimitado.

Um registro de solicitação útil pode ter esta aparência:

{
  "request_id": "elev-7f4c2",
  "agent_session": "run-91b0",
  "host": "api-02",
  "operation": "/usr/local/sbin/restart-approved-service payment-worker",
  "reason": "Deployment 482 left payment-worker unhealthy; status shows repeated configuration parse errors.",
  "expected_effect": "Service restarts with the reviewed configuration.",
  "rollback": "Restore the previous configuration revision and restart the service.",
  "expires_at": "2025-03-08T14:25:00Z"
}

O registro de execução deve levar request_id consigo. Sem essa vinculação, um aprovador pode ter aceitado uma operação enquanto o agente executou outra.

O processo do agente precisa ter sua própria identidade

Uma conta deploy compartilhada faz todos os atores parecerem iguais depois que o dano acontece. Dê à execução do agente uma identidade que registre qual executável a iniciou, qual pessoa ou serviço a acionou, qual repositório e tarefa ela recebeu e quando sua autoridade termina.

A identidade humana e a identidade do processo são fatos separados. Um desenvolvedor pode iniciar um agente, mas o processo do agente emite o comando horas depois, após ler arquivos, resultados de ferramentas e respostas da rede. A trilha de auditoria deve preservar os dois fatos. «Jamie iniciou a execução 91b0» e «o processo de agente assinado 91b0 solicitou a elevação» permitem que o investigador diferencie patrocínio de execução.

A assinatura de código pode ajudar a identificar o executável local que pediu acesso. Ela não prova que a instrução do modelo era segura e não torna confiável um repositório comprometido. Trate a identidade do processo como um limite sobre quem pode solicitar, não como prova de que a solicitação é sensata.

Não deixe o agente receber uma senha root reutilizável, uma credencial SSH privada que chegue diretamente a uma conta de administrador ou um registro de tempo do sudo de longa duração que ele possa renovar indefinidamente. Cada uma dessas opções transforma uma solicitação restrita em uma capacidade portátil. Quando o agente pode copiar essa capacidade para um workspace, log, artefato de build ou processo filho, você perde o controle sobre sua propagação.

Credenciais de curta duração reduzem a exposição, mas não tornam bom um comando ruim. Use validade junto com uma operação definida, um processo vinculado e um motivo. Se qualquer um desses elementos faltar, você tem um token de acesso com um rótulo mais simpático.

Um shell root dá ao agente espaço demais para reinterpretar instruções

Nunca aprove sudo -i, sudo su, sudo sh ou um sudo bash irrestrito para uma sessão de agente. Um shell root autoriza todos os comandos seguintes, inclusive comandos montados a partir de resultados de ferramentas que não existiam quando alguém aprovou o primeiro comando.

O mesmo alerta vale para formas de comando que disfarçam um interpretador arbitrário:

sudo python3 -c "$AGENT_TEXT"
sudo env CONFIG="$AGENT_TEXT" /usr/local/sbin/apply-config
sudo tee /etc/some-file.conf

Cada exemplo parece limitado até que você examine seu canal de entrada. O Python executa código arbitrário. env pode alterar o comportamento de um programa de maneiras que o chamador não previu. tee dá autoridade para escrever em um caminho arbitrário pertencente ao root se o caminho permanecer sem restrições. Uma política de comandos que ignora argumentos e ambiente é apenas uma política de nomes de arquivos.

Um design melhor separa diagnóstico de execução. O agente pode examinar os fatos sem privilégios, gerar uma alteração proposta e enviá-la para revisão. Um helper privilegiado e restrito recebe apenas as entradas aprovadas. O helper também precisa validar essas entradas novamente, porque a validação no momento da revisão e a validação no momento da execução protegem contra falhas diferentes.

Considere um agente de implantação que detecta uma falha de serviço. Com sudo amplo, ele pode editar uma substituição de unidade, recarregar o gerenciador e reiniciar o serviço. Uma string maliciosa em uma configuração controlada pelo repositório pode se tornar uma linha ExecStart, e o reinício a executará com autoridade root. Em um design restrito, o agente pode ler o status e preparar a configuração revisada, mas um helper de implantação privilegiado aceita apenas um resumo criptográfico de conteúdo vindo de um local aprovado para artefatos. Ele rejeita arquivos de unidade, caminhos arbitrários e substituições não gerenciadas.

Isso dá mais trabalho do que entregar um shell. Também é a diferença entre uma operação conhecida e um interpretador capaz de inventar novas operações depois da aprovação.

A aprovação deve acompanhar o risco da operação

Uma aprovação para toda a sessão pode fazer sentido para ações remotas rotineiras e limitadas. Ela não faz sentido para todo uso de uma capacidade administrativa. Trate a autorização da sessão e a autorização por chamada como controles distintos.

A autorização da sessão responde: «Este processo de agente identificado pode usar canais remotos comuns durante esta execução?». Ela impede que um processo local desconhecido se passe silenciosamente por um agente conhecido. Deve terminar quando o processo sair, e um operador deve poder revogá-la imediatamente.

A autorização por chamada responde: «Esta ação específica pode ser executada agora?». Use-a para operações com grande impacto potencial, credenciais escassas, impacto em produção ou efeitos irreversíveis. O cartão de aprovação deve começar pela identidade do processo e depois mostrar o alvo, a operação, o motivo, a validade e o efeito esperado. Esconder a identidade em meio a um bloco de texto derrota o objetivo.

Não obrigue o operador a analisar cem linhas de shell gerado. Dê ao agente um vocabulário de operações nomeadas com detalhes renderizados. «Reiniciar o worker de pagamentos em api-02» pode ser revisado. Um bloco de shell com aspas aninhadas faz a pessoa aprovar sem entender.

O fluxo de aprovação também precisa de um caminho de recusa que ajude o agente a se recuperar. Retorne uma negativa clara e, quando apropriado, uma instrução como «é necessário um registro de alteração da implantação» ou «esta operação não está disponível em produção». Não deixe o agente tentar novamente com pequenas mudanças de redação até que uma pessoa cansada aceite. A recusa deve encerrar a solicitação, a menos que uma pessoa crie uma nova com informações materialmente diferentes.

Em uma emergência, mantenha a mesma disciplina. Um engenheiro de plantão pode aprovar uma solicitação restrita com validade curta e referência ao incidente. A urgência pode justificar uma revisão mais rápida, mas não justifica apagar o registro nem conceder um shell root interativo.

Os registros de auditoria devem sobreviver ao agente que criou a solicitação

Uma transcrição de terminal ajuda na depuração, mas não pode carregar sozinha o peso de um registro de auditoria. O agente pode omiti-la, alterar arquivos locais ou executar comandos por um caminho que a transcrição não capturou. Registre a autorização e a execução em um armazenamento que o agente não possa reescrever.

Registre a decisão separadamente da ação. O registro de aprovação deve mostrar quem aprovou, quando aprovou, a identidade do processo, o conteúdo exato da solicitação e a validade. O registro de execução deve mostrar se o helper foi executado, qual host alcançou, o que retornou, quando terminou e o identificador da solicitação que o autorizou.

Inclua um resumo limitado da saída ou um resumo criptográfico do resultado em vez de despejar dados sensíveis em um diário amplamente visível. A pessoa que investiga precisa de evidências suficientes para ver que payment-worker foi reiniciado e ficou saudável. Ela não precisa de uma senha de banco copiada por acaso para o stderr.

A evidência de adulteração importa porque os logs de auditoria se tornam interessantes depois de um incidente. Uma cadeia de hashes vincula cada registro ao anterior. Se alguém alterar ou remover uma entrada, a verificação detecta a ruptura. Mantenha a verificação independente do agente e, se possível, independente das credenciais usadas para executar as ações. Um log que precisa da credencial de administrador comprometida para ser verificado é menos útil justamente quando você mais precisa dele.

Por exemplo, um verificador offline deve informar uma sequência como esta:

$ sp audit verify --file agent-audit.enc
verified records: 184
chain start: 8c1a...e72d
chain end: 4bf0...193a
status: valid

A propriedade importante não está no nome do comando. Está no fato de que o verificador consegue detectar um registro cifrado alterado sem pedir ao agente que se explique. Mantenha cópias fora da máquina onde o agente trabalha, porque um invasor que controle essa máquina pode apagar o diário inteiro.

O Sallyport mantém essa separação ao deixar as credenciais fora do agente e projetar diários de sessão e de ações individuais a partir de um registro de auditoria criptografado, encadeado por hashes e sem permissão de escrita. Esse modelo é útil quando os agentes precisam executar ações HTTP ou SSH, mas nunca devem possuir as credenciais que as autorizam.

Helpers privilegiados precisam de interfaces restritas e testes com entradas hostis

Um helper é um código sensível à segurança mesmo que tenha vinte linhas. Teste-o como se cada argumento, variável de ambiente, diretório de trabalho e arquivo referenciado viesse de um invasor, porque um agente de IA pode ser induzido a enviar material hostil sem intenção de causar dano.

Comece com um inventário de operações. Registre cada efeito privilegiado de que o agente realmente precisa, como reiniciar um serviço específico ou instalar um artefato de release assinado. Se você não consegue descrever um efeito sem dizer «executar comando arbitrário», a operação ainda não foi projetada.

Para cada helper, responda a estas perguntas antes de colocá-lo no sudoers:

1. Quais entradas exatas o chamador pode fornecer e como o helper valida cada uma?
2. Quais caminhos do sistema de arquivos, executáveis, arquivos de configuração e variáveis de ambiente influenciam seu comportamento?
3. Alguma entrada aceita pode acionar um shell, interpretador, paginador, editor, carregador de plugins ou busca na rede?
4. O helper verifica propriedade, permissões e identidade do conteúdo antes de agir?
5. Qual registro ele emite quando a validação falha e quando a execução tem sucesso?

Execute testes negativos, não apenas o caminho esperado. Passe ../ para testar travessia de diretórios, metacaracteres de shell, um nome de serviço vazio, uma entrada grande demais, Unicode inesperado e um nome válido que aponte para um estado inseguro. Tente substituir um arquivo referenciado entre a validação e o uso. Verifique se um diretório de logs, diretório temporário ou diretório pai gravável permite que o agente redirecione a saída do root.

Também examine as dependências após as atualizações. Um helper que era seguro contra uma versão de um comando pode se tornar inseguro quando uma nova opção aceita um caminho de configuração ou carrega uma extensão. Interfaces restritas reduzem esse trabalho de manutenção, mas não o eliminam.

Implante a elevação como uma exceção controlada

Comece removendo as formas mais perigosas de privilégio permanente: contas de administrador compartilhadas, NOPASSWD irrestrito, segredos root reutilizáveis na configuração do agente e shells root. Você não precisa interromper toda a automação para fazer essa mudança. Preserve primeiro o diagnóstico somente leitura e depois mova uma operação protegida por vez para um helper e um fluxo de aprovação explícitos.

Escolha uma operação frequente o bastante para testar o processo, mas com reversão limitada, como reiniciar um worker nomeado depois de uma implantação revisada. Exija que o agente envie o host, o motivo, o efeito, a reversão e a validade. Faça o aprovador rejeitar solicitações vagas. Essa fricção ensina ao fluxo do agente quais evidências ele precisa reunir antes de pedir poder.

Revise as solicitações negadas com a mesma seriedade das bem-sucedidas. Um conjunto de solicitações para gravações arbitrárias de arquivos pode mostrar que a interface de implantação não oferece uma operação necessária. Também pode mostrar que o agente continua tentando contornar uma fronteira. São problemas diferentes, e uma trilha de auditoria permite distingui-los.

Depois, pratique a revogação. Encerre uma sessão enquanto o agente estiver trabalhando, negue uma solicitação já emitida depois que ela expirar e verifique se um identificador de solicitação copiado não pode autorizar uma segunda ação. As equipes costumam testar as telas de aprovação e deixar essa parte de lado. A revogação é o controle de que você precisa quando o agente começa a se comportar de maneira diferente no meio da execução.

Não meça a maturidade pelo número de comandos que um agente consegue executar como root. Meça-a pelo fato de cada elevação continuar restrita, atribuível, limitada no tempo, revisável e recuperável quando o agente ou suas entradas derem errado.