Agentes de IA gerenciados por contratados: encerre o acesso à produção com segurança

Um contratado pode fazer um excelente trabalho com um agente de IA para programação e ainda deixar seu ambiente de produção em uma situação pior do que encontrou. O problema geralmente não começa com um prompt malicioso. Começa quando todos presumem que outra pessoa é responsável pelo processo do agente, pelas aprovações e pela limpeza.

Trate um agente operado por um contratado como um operador temporário de produção. Dê a ele um patrocinador interno responsável, uma identidade de processo reconhecível, um caminho de autoridade restrito e um procedimento de remoção que alguém já tenha ensaiado. Se você não consegue indicar o funcionário que pode interrompê-lo hoje, não delegou um trabalho. Criou um processo órfão.

A identidade do contratado não pode ser proprietária de um agente de produção

A empresa proprietária do sistema de produção deve ser dona da autoridade do agente, mesmo quando um contratado inicia e supervisiona o processo. O vínculo empregatício do contratado, sua conta pessoal, seu laptop e seu convite de calendário terminam segundo condições que estão fora do seu controle direto. O acesso à produção não pode depender de nenhum deles.

As equipes costumam confundir duas perguntas:

• Quem opera o agente durante este contrato?
• Quem continua responsável por cada capacidade recebida pelo agente?

O contratado pode responder à primeira pergunta. Um funcionário interno deve responder à segunda. Esse funcionário precisa ter autoridade suficiente para pausar o trabalho, alterar seu escopo, consultar os registros e encerrar o acesso sem esperar uma resposta do contratado.

Já vi isso dar errado de uma forma muito comum. Um contratado recebe um convite para um repositório de código e um token de API de produção porque precisa diagnosticar um problema. Ele usa um agente em sua própria máquina para inspecionar o código, consultar a API e preparar uma correção. O contrato termina, a conta do contratado no repositório é desativada e todos consideram o assunto encerrado. Semanas depois, um perfil automatizado do terminal ainda tem o token. O antigo diretório de trabalho do agente ainda contém instruções que explicam como usar o token. A empresa removeu uma pessoa de um sistema, mas não removeu um caminho operacional da produção.

Não transforme a conta de usuário do contratado na identidade permanente do trabalho do agente. Crie um registro do contrato pertencente à empresa e vincule o acesso a esse registro. Ele deve identificar o patrocinador interno, o responsável técnico, o operador, os ambientes aprovados, a identidade do processo e a condição de encerramento. Uma pessoa pode mudar de emprego ou desaparecer durante um fim de semana. Um registro ainda pode mostrar ao próximo engenheiro de plantão o que existe e como desligá-lo.

Isso não é burocracia por si só. Evita a forma mais cara de ambiguidade: um incidente em que a equipe não consegue determinar se uma solicitação veio de um agente aprovado, de uma configuração antiga de contratado ou de um invasor reutilizando um acesso esquecido.

Coloque um funcionário no comando da decisão de delegar

Todo contrato com um prestador precisa de um patrocinador responsável pela decisão de permitir que um agente atue, e não apenas pela decisão de contratar o prestador. Em geral, esse patrocinador é o gerente de engenharia, o responsável pelo serviço ou o comandante do incidente com autoridade sobre a área de produção afetada.

Antes de o agente receber autoridade de produção, o patrocinador deve responder a quatro perguntas concretas. Que trabalho o agente fará? A quais ambientes ele poderá chegar? Quais ações fazem parte do trabalho? Quando a permissão termina?

Evite escopos vagos como «ajudar a manter o serviço» ou «auxiliar na implantação». Essas frases se tornam perigosas quando um agente pode interpretá-las por meio de ferramentas. Escreva o trabalho em termos observáveis: inspecionar as respostas de erro deste serviço, abrir uma pull request, executar este comando de diagnóstico aprovado ou enviar uma solicitação de alteração para um endpoint específico.

O patrocinador não precisa ficar ao lado do contratado o dia inteiro. Mas precisa ser responsável pelos limites. Se o contratado disser que o trabalho agora exige uma gravação no banco de dados, uma nova função de infraestrutura ou acesso a outro serviço, essa é uma nova decisão de delegação. Não permita que uma aprovação anterior se estenda silenciosamente para atender a uma nova solicitação.

A NIST Special Publication 800-207 destaca um ponto útil em sua orientação sobre zero trust: os sistemas não devem conceder confiança implícita apenas porque um agente está em determinada rede ou já acessou um recurso. Aplique essa lógica ao trabalho com agentes. O fato de um contratado estar no seu canal de chat, na sua VPN ou já ter sido aprovado para uma operação de leitura não autoriza outro processo a fazer uma gravação em produção.

É nesse ponto que as equipes costumam escolher a simplificação errada. Elas dão ao contratado um acesso amplo e permanente porque aprovações repetidas parecem lentas. As aprovações parecem lentas porque o trabalho não foi definido com clareza suficiente. Corrija primeiro o limite do trabalho. O acesso amplo e permanente transforma um problema de planejamento em um problema de resposta a incidentes.

Dê ao patrocinador um substituto explícito. Se ele sair, transfira o registro do contrato e reaprove a autoridade sob o novo patrocinador. Um processo sem patrocinador atual deve perder o acesso automaticamente ou ser desativado manualmente de imediato. Não há motivo legítimo para um contrato sem acompanhamento continuar com autoridade de produção.

A procedência do processo deve fazer parte de toda aprovação

Aprovar uma pessoa é diferente de aprovar um processo. Essa diferença costuma ser ignorada e cria aprovações que abrangem mais software do que o revisor pretendia.

Uma identidade humana informa quem se autenticou. Uma identidade de processo informa qual executável solicitou uma ação, onde ele foi executado e se corresponde ao processo esperado. Quando um agente de IA trabalha por meio de shells, extensões, servidores MCP, auxiliares em segundo plano e scripts, é o processo que efetivamente chega ao caminho da credencial.

Peça evidências de que um novo processo de agente é o processo aprovado. No macOS, a autoridade de assinatura de código oferece um ponto de partida útil ao revisor. Ela pode identificar a autoridade de assinatura apresentada por um executável. Não consegue estabelecer que uma solicitação de produção pertence a este contrato nem decidir se a ação solicitada é sensata. Use-a como evidência do processo, não como uma autorização geral.

Um cartão de aprovação prático deve mostrar mais do que o nome exibido do contratado. Deve identificar o processo ou inicializador, sua autoridade de assinatura de código quando disponível, o contrato ativo, o ambiente de destino e a capacidade solicitada. Se o revisor não consegue diferenciar um processo de agente conhecido de um script copiado, a aprovação é fraca demais.

Isso detecta uma falha comum. Um contratado inicia um agente de programação aprovado em um terminal. Mais tarde, um script de shell ou outro processo de agente herda variáveis de ambiente, lê um arquivo de configuração local e faz a mesma solicitação usando a mesma credencial. Uma aprovação baseada apenas na pessoa não consegue dizer que se trata de chamadores diferentes. O segundo processo pode ser inofensivo, mas ninguém estabeleceu isso.

A resposta correta não é exigir dos revisores uma certeza impossível. É reduzir o que uma única aprovação abrange. Vincule as aprovações a uma sessão ou execução de processo, identifique essa execução com clareza e faça a aprovação expirar quando a execução terminar. Um novo processo deve se apresentar novamente.

Mantenha um registro local do comando do processo, do diretório de trabalho, do horário de início, do patrocinador e da condição esperada de encerramento. Você não precisa coletar cada prompt privado ou cada arquivo lido pelo contratado. Precisa de evidências operacionais suficientes para responder a uma pergunta básica de incidente: qual processo aprovado executou esta ação, sob a autoridade de quem e ainda dentro do contrato atribuído?

A responsabilidade pela aprovação deve acompanhar o impacto potencial

A pessoa que aprova uma ação do agente deve corresponder à consequência dessa ação. Um contratado pode aprovar ações rotineiras dentro de uma tarefa delegada e restrita. Ele não deve se tornar silenciosamente a autoridade final para ações que possam alterar dados de produção, permissões, comunicações com clientes ou infraestrutura.

Divida a aprovação em duas camadas. O patrocinador autoriza a categoria do trabalho e sua duração. O aprovador da ação autoriza uma operação específica quando o impacto exigir uma decisão humana. Em uma equipe pequena, um mesmo funcionário pode desempenhar as duas funções. Ainda assim, mantenha as responsabilidades separadas no registro, pois elas respondem a perguntas diferentes mais tarde.

Use um modelo simples de responsabilidades:

• O patrocinador é responsável pelo objetivo, pelo escopo e pela expiração do contrato.
• O operador contratado é responsável pela qualidade da tarefa e solicita ações dentro do escopo.
• O aprovador da ação é responsável pela decisão de permitir uma chamada sensível.
• O responsável técnico é responsável pelo caminho da credencial e pelo procedimento de desligamento.
• A equipe de segurança ou operações verifica se a revogação foi concluída.

Não crie um ritual de aprovação para cada leitura inofensiva apenas para afirmar que existe controle humano. Os revisores vão clicar para passar por ele e depois deixar passar a solicitação que realmente merece atenção. Coloque atrito onde a ação altera um estado, amplia a autoridade, revela dados restritos ou chega a um novo destino de produção.

A aprovação por chamada funciona melhor para operações fáceis de reconhecer e difíceis de desfazer: uma gravação em um registro de cliente, uma implantação em produção, um comando SSH com efeito administrativo ou uma solicitação que altera permissões. A aprovação por sessão funciona para trabalhos de investigação delimitados, nos quais o processo precisa fazer várias leituras relacionadas. O registro deve indicar qual opção se aplica antes do início do trabalho.

A tela de aprovação também deve informar o destino. «Permitir que o agente use a API» quase não diz nada ao revisor. «Permitir que este processo aprovado envie uma solicitação POST ao endpoint de faturamento em produção» oferece uma decisão pela qual ele pode se responsabilizar. Um bom revisor ainda poderá rejeitá-la, pedir uma solicitação de alteração ou exigir que o contratado use o ambiente de homologação.

A fadiga de aprovação é uma falha de projeto, não um motivo para abandonar as aprovações. Se a fila virar ruído, restrinja as ferramentas, agrupe operações seguras em uma sessão curta ou leve a investigação para um ambiente que não seja de produção. Não resolva o problema tornando permanente a autoridade de produção.

Mantenha as credenciais fora do contexto do agente

Um agente deve solicitar uma ação, não guardar o segredo que a autoriza. Essa é a linha que torna possível o desligamento.

Se o agente de um contratado recebe um token de API em texto aberto, uma chave privada SSH ou um segredo copiado em um arquivo de configuração, você já perdeu o controle sobre onde essa credencial pode chegar. O token pode parar no histórico do terminal, na memória do agente, em logs, arquivos temporários, uma alteração de código ou um prompt enviado a outro serviço. A rotação pode limpar a credencial, mas não reconstitui o caminho que ela percorreu.

Use um gateway de ações que mantenha as credenciais no lado controlado pela empresa e execute ações HTTP ou SSH aprovadas em nome do agente. O agente recebe o resultado, não o segredo. Isso não torna segura uma ação insegura. Dá à equipe um lugar para aplicar a aprovação, registrar a chamada e revogar a autoridade sem procurar no sistema de arquivos do contratado.

O Sallyport segue esse modelo para chamadas de API HTTP e comandos SSH: os segredos permanecem em seu cofre criptografado e o agente solicita ações por meio de uma conexão MCP, em vez de receber as credenciais. A propriedade útil aqui é a separação, não a magia. Um agente comprometido ou descuidado ainda pode solicitar ações prejudiciais dentro do escopo concedido, por isso a responsabilidade e as aprovações continuam necessárias.

Trate cada caminho de credencial como um item de inventário. Registre o proprietário da credencial, o destino, o tipo de ação permitido, a referência do contrato e o método de desligamento. Não se contente com uma observação que diga «token de produção usado pelo contratado». Essa nota não informa ao responsável pelo incidente onde o token está, se foi copiado ou qual caminho precisa ser desativado.

O SSH exige cuidado especial porque as equipes costumam presumir que um login em um host é temporário quando o contratado é temporário. Verifique chaves autorizadas, certificados, encaminhamento do agente local, acesso por host de salto, perfis de shell, tarefas agendadas e cópias remotas de scripts de implantação. Remover uma chave pública não revoga uma chave privada que ainda possa alcançar outro salto confiável.

A mesma regra vale para credenciais HTTP. Remova ou desative o caminho de ação e depois verifique se o destino rejeita uma nova solicitação. Não considere o trabalho concluído porque uma tela de gerenciamento de acesso mostra um usuário desativado. O gateway de ações, a conta de serviço, a credencial da API e a rota de rede podem ter ciclos de vida separados.

Planeje a revogação antes de conceder o acesso

A equipe deve conseguir revogar um agente operado por um contratado sem pedir a colaboração do contratado. Se o procedimento exige o laptop, a senha do gerenciador de senhas ou a memória dele, isso não é um procedimento de revogação.

Escreva o caminho de desligamento antes da primeira ação em produção. Ele deve abranger o processo do agente, a sessão de aprovação, a rota da credencial, os acessos ao código-fonte e à infraestrutura, o trabalho agendado e a preservação da auditoria. Cada item precisa de um operador identificado e de uma forma de verificar sua conclusão.

A diferença entre desativar e revogar importa. Desativar interrompe o uso futuro de uma conta ou credencial específica. Revogar encerra a relação de autoridade ativa e remove os caminhos que poderiam restaurá-la. A conta de um contratado pode ser desativada enquanto um processo já em execução mantém uma sessão ativa. Um token pode ser revogado enquanto uma conexão SSH permanece aberta. Cuide dos dois estados.

Use esta sequência quando um contrato terminar ou precisar ser interrompido imediatamente:

1. Bloqueie novas ações do agente no gateway de credenciais ou no ponto de autorização e revogue as sessões ativas vinculadas ao contrato.
2. Pare os processos conhecidos do agente, locais e remotos, incluindo multiplexadores de terminal, launch agents, tarefas de CI e tarefas agendadas.
3. Desative ou faça a rotação das credenciais da empresa atribuídas ao contrato e remova os acessos ao repositório, à nuvem, à VPN, ao bastion e ao sistema de tickets.
4. Procure no inventário do contrato por configurações copiadas, scripts gerados, chaves de implantação e contas de serviço temporárias e remova esses itens.
5. Verifique a rejeição tentando uma checagem inofensiva pelo caminho autorizado e preserve os registros das ações antes de fechar o contrato.

A ordem importa. Se você começar apagando registros ou desativando a conta do contratado, pode perder as informações necessárias para encontrar sessões ativas. Interrompa primeiro os caminhos de ação, preserve as evidências e só então limpe os acessos.

Não declare sucesso porque todos os itens têm um responsável. Teste o procedimento durante o contrato. Peça ao responsável técnico que revogue uma sessão de homologação enquanto o contratado estiver presente. Confirme que o agente não consegue fazer outra chamada, que o contratado entende o que foi interrompido e que o registro de atividade mostra a negativa. A primeira vez que sua equipe descobrir um caminho de desligamento ausente não deve ser durante um incidente de segurança ou uma disputa contratual.

Um registro curto do contrato revela decisões que faltam

Um registro pequeno e revisável detecta mais problemas reais do que uma política extensa de acesso que ninguém lê. Armazene-o junto ao ticket de trabalho ou em um repositório operacional controlado, não em uma conversa privada de chat.

Este exemplo é deliberadamente simples. Substitua os valores de exemplo pelos seus próprios identificadores, mas não omita campos porque o contrato parece temporário.

engagement: contractor-search-repair-2025-04
sponsor: employee-ops-owner
technical_custodian: employee-platform-owner
contractor_operator: external-developer
purpose: diagnose production search indexing failures
agent_process:
  approved_launcher: signed-local-agent-process
  allowed_workstation: managed-mac-asset-184
  expires_at: 2025-04-30T17:00:00Z
scope:
  environments: [staging, production-read]
  permitted_actions:
    - GET search-service health endpoint
    - GET indexing queue depth endpoint
  prohibited_actions:
    - production writes
    - credential administration
approval:
  session_owner: employee-ops-owner
  per_call_owner: employee-platform-owner
credential_routes:
  - search-api-read-route
  - bastion-diagnostic-route
revocation_owner: employee-platform-owner
verification_owner: employee-security-owner

O registro separa coisas que as pessoas costumam juntar em um único rótulo. contractor_operator não é sponsor. session_owner não é necessariamente per_call_owner. revocation_owner não é a pessoa que decidiu que o trabalho era necessário. Essa separação impede que o contratado aprove, na prática, a própria ampliação de autoridade e evita que um gerente ausente se torne a única pessoa capaz de interromper o acesso.

O campo permitted_actions deve usar verbos e destinos. «Somente leitura» é amplo demais quando um serviço tem endpoints que iniciam exportações, revelam dados pessoais ou consomem capacidade. «Leitura em produção» também precisa ser interpretado com cuidado. Uma leitura ainda pode expor dados regulados ou detalhes operacionais que facilitam um ataque.

Defina uma expiração mesmo que o contrato não tenha uma data exata de término. Prolongue-o por meio de uma nova decisão quando o trabalho continuar. Uma renovação explícita força o patrocinador a verificar se o trabalho ainda precisa de acesso à produção e se o processo original continua sendo o processo usado.

Os registros de auditoria devem responder a perguntas operacionais

Uma trilha de auditoria do trabalho com agentes deve informar quem autorizou a ação, qual processo a solicitou, qual destino alcançou, se teve sucesso e quando alguém revogou a autoridade. Uma transcrição de chat não responde a tudo isso de forma confiável.

Mantenha duas visões sempre que possível. Uma acompanha a execução ou sessão do agente, para que o investigador possa ver o ciclo de vida da autorização e interromper uma execução ativa. A outra acompanha ações individuais, para que um operador possa inspecionar uma chamada de API ou um comando SSH específico. Vincule as duas visões ao mesmo registro de evento subjacente, em vez de manter histórias separadas manualmente.

Proteja o log de auditoria contra o processo que ele registra. Um processo capaz de alterar o próprio histórico pode esconder as evidências mais relevantes. Armazenamento somente para acréscimo, acesso restrito de gravação e encadeamento criptográfico ajudam, mas cada mecanismo tem uma função. Uma cadeia pode revelar que registros foram alterados ou removidos. Ela não consegue dizer se a solicitação original era uma boa ideia.

O Sallyport mantém diários de sessões e atividades projetados a partir de um log de auditoria criptografado e encadeado por hash. O comando sp audit verify pode verificar a cadeia offline sobre o texto cifrado, o que é útil quando a máquina que contém o cofre está bloqueada ou quando um investigador não deve ler os segredos.

Para cada contrato, decida quem revisa os registros e quando. Uma gravação sensível em produção pode exigir revisão antes de o contratado continuar. Uma tarefa curta de diagnóstico pode exigir apenas uma revisão no encerramento. Ainda assim, a equipe deve saber como localizar os eventos durante um incidente.

Preserve também as negativas. Uma ação negada pode revelar que o agente tentou ultrapassar o escopo, que um contratado entendeu a tarefa de forma errada ou que um processo antigo continua ativo depois do desligamento. Se você guardar apenas as chamadas bem-sucedidas, descartará justamente as evidências que muitas vezes explicam o incidente seguinte.

A linguagem do contrato deve corresponder ao desenho do acesso

Um contrato não consegue revogar um token de API, mas pode remover a ambiguidade que leva as equipes a deixar acessos para trás. Escreva as obrigações operacionais de modo que correspondam aos controles realmente usados pela equipe.

Declare que a empresa é proprietária das credenciais, dos registros de processos, dos registros de auditoria e de toda configuração de acesso criada para o contrato. Declare que o contratado deve usar caminhos aprovados e controlados pela empresa para ações em produção e não pode copiar credenciais para arquivos locais, prompts, repositórios ou serviços de terceiros. Se o trabalho precisar de uma exceção, exija aprovação por escrito do patrocinador antes que ela ocorra.

Inclua uma obrigação de devolver e excluir os materiais de trabalho, mas não dependa de uma declaração como único controle. Contratados podem agir de boa-fé e ainda assim esquecer um arquivo de histórico do shell, uma variável de ambiente em cache ou um backup. A revogação técnica lida com o que você consegue controlar. Os termos contratuais cobrem as obrigações que permanecem fora dos seus sistemas.

Defina o fim do contrato operacionalmente: o patrocinador encerra o trabalho, o responsável técnico desativa os caminhos de ação, o responsável pela verificação confirma o teste de negativa e a equipe mantém o registro de auditoria segundo suas regras normais de retenção. Se o contratado precisar de acesso de suporte mais tarde, abra um novo contrato em vez de reativar o antigo.

Evite cláusulas que digam que o contratado é «responsável pela segurança» sem indicar decisões e controles. Essa formulação parece firme, mas deixa as perguntas difíceis sem resposta quando alguém solicita uma alteração em produção às seis da tarde. Escreva quem pode aprovar a alteração, quem a executa e quem pode interrompê-la.

O primeiro documento a preparar não é uma política ampla de IA. É o registro do contrato para o próximo prestador que precisar de um agente perto da produção. Preencha-o com o patrocinador e o responsável técnico na mesma sala. Qualquer campo vazio aponta diretamente para o trabalho que sua equipe ainda precisa fazer antes de conceder o acesso.