Acesso temporário à produção: concessões que terminam com a tarefa

O acesso à produção de um agente de programação de IA deve terminar porque o sistema de autorização determina seu fim, não porque alguém pretendia voltar ao assunto mais tarde. Uma finalidade, um prazo e uma verificação de encerramento transformam uma exceção arriscada em uma concessão delimitada que outro engenheiro pode inspecionar.

Já vi controles de acesso falharem da maneira mais banal: o incidente é resolvido, a tarefa é encerrada e a credencial continua útil. Nada dramático acontece naquele dia. Meses depois, a mesma credencial aparece em um script não relacionado, um processo antigo do agente é retomado ou alguém a usa por conveniência. A exceção original virou acesso permanente à produção por simples descuido.

O acesso temporário à produção precisa de três fatos que o ponto de aplicação consiga avaliar: por que o agente pode agir, o que ele pode acessar e quando precisa parar. A última parte é tão importante quanto as duas primeiras. Se você não consegue demonstrar uma negação depois do encerramento da tarefa, a tarefa ainda não terminou.

Um prazo deve negar solicitações, não apenas enfeitar um ticket

Um horário de término declarado só tem efeito quando o componente que executa ou autoriza a ação o verifica em cada solicitação. Um rastreador de projetos, uma entrada no calendário ou um lembrete no chat não impedem um processo antigo de chamar uma API às 02:00.

Essa diferença pega as equipes de surpresa porque o processo de mudança parece disciplinado. Elas exigem um ticket, um revisor e um status de encerramento. Depois entregam ao agente uma credencial que continua válida até que alguém a altere manualmente. O fluxo registra a intenção, enquanto a credencial mantém a autoridade.

Coloque a expiração no ponto em que a solicitação entra na produção. Dependendo do desenho, esse ponto pode ser um provedor de identidade que emite um token de curta duração, um gateway de acesso que verifica um banco de concessões, um validador de certificados SSH ou um broker que mantém a credencial e executa a ação. O serviço protegido precisa receber uma solicitação que possa rejeitar depois do prazo.

A NIST SP 800-207 faz uma observação útil ao descrever a arquitetura de confiança zero: as decisões de acesso devem ser avaliadas antes que uma sessão com um recurso corporativo seja estabelecida, e o acesso deve ser concedido por sessão. Isso não significa que cada aplicação precise copiar um produto completo de confiança zero. Significa que conceder uma sessão uma vez e presumir que ela continuará adequada para sempre contradiz esse modelo.

Para agentes, avalie pelo menos o início de cada ação. Trabalhos longos precisam de uma decisão separada: permitir que a operação já iniciada termine sob uma concessão limitada ou cancelá-la quando a concessão expirar. Decida esse comportamento antes de uma indisponibilidade, porque interromper uma correção de banco de dados no meio pode causar tanto dano quanto manter o acesso irrestrito.

O prazo deve usar um carimbo de data e hora em uma única base acordada, normalmente UTC. Não escreva «até o fim do dia» esperando que todos os sistemas entendam o mesmo dia. Armazene 2025-04-18T16:30:00Z, mostre o horário local para a pessoa que aprova e faça o caminho da solicitação comparar com o carimbo armazenado.

A finalidade precisa limitar a concessão

Uma finalidade só é útil quando limita o que o agente pode fazer. «Ajudar com a produção» e «investigar o alerta» descrevem uma intenção geral, não um limite de autorização.

Escreva a finalidade de modo que um engenheiro que não aprovou a concessão possa decidir se uma solicitação se encaixa nela. Uma declaração funcional identifica o item de trabalho que a gerou, o alvo, a operação permitida e a condição esperada de conclusão. Por exemplo:

Investigar o aumento de falhas no checkout no incidente INC-482. Ler os logs e o status de implantação do serviço de checkout. Reiniciar apenas o worker do checkout se o comandante do incidente aprovar o reinício. Encerrar o acesso quando o INC-482 for resolvido ou às 16:30 UTC, o que ocorrer primeiro.

Essa declaração cria critérios de decisão. Ler um banco de dados de faturamento não se encaixa. Enviar uma alteração não relacionada à aplicação também não. Reiniciar o worker exige uma condição de aprovação identificada. O agente continua útil sem receber um cheque em branco.

O escopo precisa de mais do que um rótulo de produção. Vincule a concessão a alvos concretos:

• hosts de API, repositórios ou hosts SSH identificados
• métodos ou comandos identificados, como GET /health ou uma consulta de status de implantação
• ambientes e identificadores de conta identificados
• uma quantidade máxima de ações ou uma taxa máxima de solicitações quando a tarefa puder exigir chamadas repetidas
• uma pessoa responsável que possa interromper o trabalho

Evite a recomendação popular de dar ao agente amplo acesso de leitura porque «somente leitura é seguro». O acesso de leitura costuma expor registros de clientes, configurações, topologia, histórico de implantações ou credenciais inseridas em logs antigos. Ele também permite que o agente colete muito mais contexto do que a finalidade exige. Dê a ele apenas os endpoints de observabilidade e o intervalo de consulta de logs necessários para a tarefa.

Há outro limite que as equipes confundem: a finalidade de uma tarefa não é o mesmo que um prompt. O prompt informa ao agente o que você pediu que ele tentasse fazer. A finalidade da autorização informa ao ponto de aplicação o que ele pode permitir mesmo que o prompt mude, o modelo faça uma inferência ruim ou a saída de uma ferramenta contenha instruções hostis. Trate os prompts como entrada não confiável para a decisão de acesso.

Credenciais e autoridade expiram de maneiras diferentes

Uma credencial prova que quem chama possui algo. A autorização decide se essa pessoa ou processo pode executar esta solicitação agora. As duas partes precisam terminar quando o trabalho terminar.

Um bearer token com uma declaração exp pode ser um bom limite de tempo se a API receptora validar a assinatura, o público e a expiração em cada solicitação. Ele não é uma solução universal. Alguns serviços armazenam a autenticação em cache, aceitam tokens opacos validados em outro lugar ou autorizam um token com base em um estado no servidor que continua ativo. Um token que expira em 15 minutos também não respeita o limite da tarefa se você o emitiu para uma tarefa que terminou em quatro minutos.

O mesmo problema aparece com SSH. O OpenSSH aceita certificados de usuário assinados com um intervalo de validade. O manual do ssh-keygen documenta -V como a opção do intervalo de validade. Um certificado de curta duração é muito melhor do que colocar uma chave privada de longa duração no espaço de trabalho do agente, mas sua expiração responde apenas à questão do tempo. Ainda é preciso restringir principals, hosts de destino e comportamento dos comandos.

Este comando mostra um certificado válido por 20 minutos:

ssh-keygen -s ./user_ca -I agent-run-7f3a \\
  -n deploy-readonly -V +20m ./agent-run-7f3a.pub

A saída normalmente identifica o arquivo da chave pública assinada, por exemplo:

Signed user key ./agent-run-7f3a-cert.pub: id "agent-run-7f3a" serial 0 for deploy-readonly valid from 2025-04-18T16:00:00 to 2025-04-18T16:21:00

Não confunda esse certificado com uma concessão completa de tarefa. Se a conta remota puder executar comandos arbitrários, o certificado continuará autorizando comandos arbitrários até 16:21. Use uma conta restrita, um comando forçado ou uma lista de permissões de comandos no host quando o trabalho exigir isso.

Revogação e expiração também são diferentes. A expiração é previsível e funciona mesmo quando um serviço central de revogação está indisponível. A revogação encerra a autoridade antecipadamente quando o incidente é resolvido, o agente se comporta de modo inesperado ou um aprovador retira o consentimento. Um bom desenho oferece os dois: vida útil máxima curta e revogação imediata.

O encerramento da tarefa precisa gerar um evento legível por máquina

Encerrar uma tarefa deve produzir um evento que um componente de acesso possa consumir. Uma pessoa alterar o status de um ticket sem um caminho de revogação conectado cria uma falsa sensação de conclusão.

Use duas condições de término. A primeira é um horário final rígido definido quando a concessão é criada. A segunda é um sinal de encerramento antecipado vindo do sistema de trabalho ou da pessoa responsável. O término efetivo é o que ocorrer primeiro. Um ticket reaberto não restaura silenciosamente a concessão antiga. Ele exige uma nova aprovação e um novo horário de término.

Isso protege contra uma falha conhecida. Um agente recebe acesso para um incidente. O agente informa que corrigiu o problema, então o operador encerra o incidente. Um segundo processo do agente ainda mantém uma conexão autenticada e continua coletando diagnósticos. Mais tarde, a equipe reabre o incidente, mas ninguém percebe que o processo antigo nunca parou. A decisão de acesso ficou vinculada à narrativa de um ticket, não ao ciclo de vida do processo real.

Vincule a autorização a um identificador de execução imutável, além do identificador da tarefa. Uma tarefa pode ter várias execuções ao longo de vários dias. Cada execução precisa de seu próprio início, término e responsável. Quando a execução termina, revogue a concessão. Quando a tarefa é encerrada, revogue todas as execuções ainda ativas vinculadas a ela.

O evento de encerramento precisa de um receptor idempotente. Os sistemas repetem webhooks e operadores pressionam botões duas vezes. Uma solicitação de revogação deve aceitar entregas repetidas e manter o primeiro horário efetivo, em vez de tratar uma duplicata como um erro que alguém ignora.

Registre a origem do encerramento. Uma alteração de status em um sistema de tickets, uma parada manual feita pelo comandante do incidente, o encerramento de um processo e uma expiração rígida têm significados diferentes durante uma investigação. O resultado para o acesso é o mesmo, mas o registro de auditoria deve preservar o motivo do término.

Não conceda uma extensão automática só porque um agente emite mais chamadas de ferramentas perto do prazo. Esse padrão recompensa um processo ocupado com mais autoridade. Exija que uma pessoa faça uma nova decisão, com uma finalidade revisada se o trabalho tiver mudado.

Um registro de concessão evita aprovações vagas

Um registro estruturado de concessão transforma a aprovação em algo que o sistema pode aplicar e um engenheiro pode revisar. Ele também revela decisões ausentes antes que o agente toque na produção.

O exemplo a seguir é propositalmente simples. É um formato de registro, não uma linguagem de políticas. Os campos impedem que uma execução de agente herde uma permissão vaga e reutilizável.

grant_id: grant_01JQ7P8V6R
agent_run_id: run_7f3a2c
purpose: "INC-482: inspect checkout worker failures"
owner: "on-call engineer"
created_at: "2025-04-18T16:00:00Z"
ends_at: "2025-04-18T16:30:00Z"
ends_on_task_close: "INC-482"
targets:
  - "https://ops.example.internal/checkout/status"
  - "ssh://checkout-worker-03.internal"
allowed_actions:
  - "GET /checkout/status"
  - "journalctl -u checkout-worker --since 20m"
closure_required: true
verification_action: "GET /checkout/status"

O registro não diz «acesso à produção: sim». Esse campo esconderia as escolhas importantes. Ele informa quem é responsável pela decisão, qual execução recebe a concessão e qual solicitação será usada para provar que ela desapareceu.

Mantenha o escopo legível o suficiente para que um aprovador possa rejeitá-lo. Uma lista enorme de caminhos curinga faz as pessoas aprovarem o acesso automaticamente porque não conseguem entendê-lo sob pressão. Se o agente precisa de vinte alvos sem relação entre si, divida o trabalho em concessões separadas ou reconheça que a finalidade é ampla demais.

Não coloque um segredo nesse registro. Um identificador de concessão e uma descrição do alvo bastam. O executor pode obter uma credencial protegida depois de verificar a concessão. Esse desenho também permite manter dados de auditoria úteis sem guardar o material que poderia recriar o acesso à produção.

O registro deve sobreviver a uma reinicialização e ser somente de acréscimo do ponto de vista da pessoa que executa o agente. Se o agente puder editar ends_at, alterar seus alvos ou apagar um sinal de encerramento, você delegou a decisão de segurança ao processo que pretendia restringir.

Faça escolhas explícitas para operações já em andamento. Uma consulta de logs pode terminar depois da expiração com pouco risco. Uma implantação, migração ou reinicialização pode exigir uma regra de cancelamento, um limite transacional ou um procedimento de transferência para uma pessoa. A pior opção é deixar esse comportamento indefinido e descobri-lo durante a recuperação.

Prove a expiração com uma solicitação negativa

Você prova que o acesso terminou enviando uma solicitação que agora deve falhar pelo mesmo caminho usado pelo agente. Um ticket encerrado, um crachá expirado em um console administrativo e uma linha revogada em um banco de dados são evidências de apoio. Eles não são a prova.

Agende a verificação imediatamente depois do que ocorrer primeiro entre o encerramento da tarefa e a expiração. Use um endpoint inofensivo que ainda exija a concessão, como uma solicitação de status do serviço. Não teste com uma verificação de saúde pública, porque um endpoint público terá sucesso independentemente de o acesso ter terminado.

Uma sequência de teste simples se parece com esta:

# This call succeeded while the grant was active.
agent-action --grant grant_01JQ7P8V6R \\
  GET https://ops.example.internal/checkout/status

# After task closure, repeat the exact protected operation.
agent-action --grant grant_01JQ7P8V6R \\
  GET https://ops.example.internal/checkout/status

O segundo comando deve produzir uma saída parecida com esta:

request_id=req_92a1
status=403
reason=grant_ended
ended_at=2025-04-18T16:12:09Z

Sua implementação pode retornar 401, 403 ou uma recusa de conexão. Escolha um significado e documente-o. A entrada de auditoria deve declarar que a camada de acesso rejeitou a solicitação porque a concessão terminou, e não porque o DNS falhou ou o alvo estava indisponível.

Teste os caminhos que as pessoas esquecem. Se um agente pode usar HTTPS e SSH, verifique os dois. Se o serviço emitir um cookie depois de uma troca de API, verifique se o cookie não sobrevive à concessão. Se um worker colocar ações em uma fila local, verifique se o executor valida a autorização quando envia a ação enfileirada, e não apenas quando aceita o trabalho.

Execute um teste de expiração agendado em um ambiente que não seja de produção antes de confiar no desenho em produção. Crie uma concessão com vida útil muito curta, faça uma solicitação permitida, espere a expiração e faça a mesma solicitação novamente. Depois revogue antecipadamente uma segunda concessão ativa e repita a solicitação. Essas duas verificações detectam defeitos diferentes: problemas com o relógio e falhas na revogação antecipada.

A disciplina do relógio merece atenção. O componente que avalia o prazo deve usar um relógio de sistema confiável e registrar o horário em que fez a avaliação. Se um laptop puder atrasar o relógio e, com isso, prolongar o acesso, o prazo não é aplicável. Um broker central reduz esse risco porque um único componente sempre ativo toma a decisão, mas ainda é preciso monitorar sua fonte de tempo.

Os processos dos agentes precisam de seu próprio limite

Uma tarefa pode continuar entre tentativas, terminais e turnos do modelo, mas um processo de agente continua sendo uma unidade prática de controle de acesso. Conceder autoridade por execução oferece um ponto claro para pedir aprovação, observar o comportamento e revogar imediatamente.

Não confunda uma conversa com um processo. Um usuário pode dizer a um agente «continue investigando» depois de uma reinicialização do modelo ou depois que uma ferramenta inicia um processo filho. Se o acesso acompanhar a conversa sem um novo evento de autorização, o operador perde o controle de qual executável possui a permissão.

Registre a identidade do processo que iniciou a execução. No macOS, a autoridade de assinatura de código oferece ao aprovador informações mais úteis do que um nome de processo fornecido pelo usuário. Um processo chamado agent quase não informa nada. Uma identidade de assinatura registrada, o caminho do executável, o processo pai e o horário de inicialização tornam a revisão posterior possível.

O Sallyport usa uma aprovação de sessão para um novo processo de agente por padrão, e seu cartão de aprovação apresenta primeiro a autoridade de assinatura de código do processo. Esse é um limite de processo sensato, mas a aprovação da sessão ainda deve ficar dentro de uma concessão de tarefa com um horário de término.

Encerre ou revogue no encerramento normal do processo, mas nunca dependa apenas disso. Processos travam, máquinas entram em suspensão e as relações entre pais e filhos ficam confusas. O prazo rígido e o evento de encerramento da tarefa continuam sendo as proteções de reserva. Se o processo sobreviver ao encerramento da tarefa, o caminho da solicitação deve negá-lo mesmo antes que o sistema operacional o elimine.

Separe o acesso ao terminal do operador humano do acesso do agente. É tentador deixar o agente herdar o shell autenticado do operador porque isso facilita a configuração. Também elimina a atribuição e pode dar ao agente todos os privilégios acumulados pelo operador naquele dia. Dê ao agente uma identidade distinta e faça com que ele solicite acesso por seu próprio caminho.

Avisos de aprovação não eliminam a necessidade de escopo

Uma pessoa que clica em aprovar pode detectar uma solicitação evidentemente errada, mas as aprovações ficam fracas quando chegam com frequência excessiva ou descrevem pouco. Um aviso que diz apenas «permitir chamada de API» obriga a pessoa a adivinhar suas consequências.

Mostre ao aprovador a finalidade, o alvo, o método ou comando, o horário de término da concessão e a identidade do agente. Se o sistema não consegue explicar a solicitação nesses termos, ainda não coletou informação suficiente para pedir aprovação com responsabilidade.

A aprovação por chamada tem lugar em operações com efeitos irreversíveis: apagar dados, alternar uma credencial, iniciar uma rodada de pagamentos ou implantar uma alteração não revisada. Ela não deve se tornar o controle normal de cada leitura de log. As pessoas aprovam avisos repetitivos por reflexo, especialmente durante um incidente.

Para uma chamada marcada com a opção de aprovação por chamada, o Sallyport pede aprovação a cada uso, mas essa configuração deve complementar, e não substituir, um horário de término. Uma pessoa pode aprovar uma solicitação válida às 16:29, enquanto o caminho de acesso ainda deve rejeitar qualquer solicitação posterior ao fim da concessão.

Mantenha uma parada de emergência rápida que não exija encontrar o aprovador original. O engenheiro de plantão precisa de uma forma de encerrar uma execução quando o agente entra em loop, interpreta uma saída de modo errado ou começa a acessar o alvo errado. Registre quem usou a parada e por quê. Um controle de emergência sem responsabilidade pode virar outro caminho de acesso não revisado.

Um rastro de auditoria precisa responder às perguntas difíceis

Depois de um evento em produção, as pessoas perguntam quando o acesso começou, quem o permitiu, qual processo o usou, quais solicitações tiveram sucesso e se ele realmente parou. Logs que registram apenas sucessos não conseguem responder à última pergunta.

Registre também as chamadas negadas, especialmente as negações depois da expiração ou revogação. Uma negação prova que o ponto de aplicação recebeu uma solicitação e aplicou o limite. Ela pode revelar um agente travado que continua tentando depois do encerramento da tarefa, algo que merece atenção mesmo quando o controle funcionou.

Mantenha a decisão de concessão e as ações individuais conectadas por identificadores. Um revisor deve conseguir partir de grant_01JQ7P8V6R até o responsável pela aprovação, a tarefa associada, a identidade da execução, o escopo permitido, a origem do encerramento e cada solicitação. Se esses registros estiverem em sistemas sem relação e sem um identificador compartilhado, a reconstrução vira um exercício de adivinhação.

A evidência contra adulteração importa porque os registros de acesso costumam se tornar importantes depois que alguém passa a ter interesse em editá-los. O Sallyport projeta seus diários de sessão e atividade a partir de um log de auditoria criptografado e encadeado por hash, e sp audit verify pode verificar essa cadeia offline sobre o texto cifrado. Essa propriedade não decide se uma solicitação era apropriada, mas torna mais difícil esconder uma alteração silenciosa na sequência registrada.

Não colete todos os prompts e pensamentos do modelo como substituto dos logs de ações. Esses registros criam problemas de privacidade e retenção e ainda podem não identificar a solicitação de rede real. Comece pela decisão de autorização e pelo resultado da ação. Adicione o contexto do prompt apenas quando suas regras operacionais e de privacidade justificarem isso.

Ofereça aos revisores um registro fixo de encerramento. Ele deve informar o identificador da concessão, o horário efetivo de término, a origem da terminação, a quantidade de ações bem-sucedidas, a quantidade de ações negadas depois do término e o resultado da solicitação de verificação. Esse registro transforma a afirmação vaga de «acesso removido» em algo que um revisor de mudanças pode contestar.

Construa o controle em uma sequência pequena e testável

Você não precisa de um mecanismo geral de políticas para aplicar o acesso temporário. Precisa de um mecanismo restrito pelo qual toda ação do agente deve passar e de um caminho de recusa que possa ser testado.

Comece listando as ações que os agentes realizam atualmente em produção. Separe operações de leitura, gravações reversíveis e ações que podem causar efeitos irreversíveis ou amplos. Para cada ação, identifique quem realmente possui a credencial e qual é o ponto de aplicação. Esse exercício costuma revelar credenciais em variáveis de ambiente, perfis de shell, logs de CI ou arquivos de configuração copiados.

Depois, construa o ciclo de vida mínimo:

1. Crie uma identidade de execução distinta e uma concessão estruturada com uma finalidade e um horário de término rígido.
2. Encaminhe cada ação HTTP ou SSH protegida por um executor que verifique a concessão antes do uso.
3. Aceite um encerramento antecipado ou um evento de revogação e registre seu horário efetivo.
4. Envie uma solicitação protegida e inofensiva depois da terminação e retenha o resultado da negação.
5. Revise regularmente as concessões expiradas e revogadas em busca de tentativas que continuaram depois do fim do acesso.

Não comece com regras elaboradas que classifiquem todos os comandos possíveis. As equipes passam semanas discutindo a sintaxe enquanto seus agentes continuam com credenciais de longa duração. Comece com alvos identificados, vidas úteis curtas, identidade por execução e prova de negação. Acrescente restrições mais específicas quando o histórico de ações mostrar que escopos amplos estão sendo solicitados.

O critério de qualidade é simples e exigente: quando a tarefa terminar, um processo antigo do agente precisa falhar no limite da produção, e você precisa conseguir mostrar por que falhou. Até que seja possível executar essa verificação, o acesso é temporário apenas no papel.