Como o bloqueio do cofre e da tela muda um teste de agente

Uma tela bloqueada e um cofre bloqueado são controles diferentes. Tratar os dois como se fossem o mesmo controle produz um teste que quase não informa nada. O bloqueio da tela do macOS limita o acesso interativo a uma sessão de usuário. O bloqueio do cofre precisa interromper as ações protegidas no ponto em que as credenciais seriam usadas, inclusive quando a ação é solicitada por um processo aprovado antes de você se afastar.

Essa distinção é mais importante com agentes de programação autônomos. Um agente pode manter um processo ativo, conservar o contexto, agendar tarefas e tentar novamente uma solicitação que falhou. Um teste que apenas confirma que uma pessoa não consegue digitar na área de trabalho não mostra se esse processo ainda pode chamar uma API ou abrir uma conexão SSH. Teste os dois estados de forma independente e depois teste a combinação deles.

Já vi equipes chamarem isso de teste de «computador bloqueado», tirarem uma captura de tela da tela de bloqueio e declararem o trabalho concluído. Isso é evidência de uma tela de bloqueio. Não é evidência de um limite absoluto que impeça o uso das credenciais.

Uma tela bloqueada não decide se um processo pode agir

O bloqueio da tela do macOS protege a sessão do console contra uma pessoa com acesso físico ao teclado e ao monitor. Por si só, ele não descreve todos os processos que já estão em execução nessa sessão, todas as conexões de rede que eles possuem nem todos os armazenamentos de credenciais que um aplicativo pode usar.

A documentação Platform Security da Apple separa a autenticação do usuário e a proteção da sessão da proteção de segredos, como itens do keychain. Essa separação é útil aqui, mesmo que sua implantação exata tenha menos componentes do que a documentação da Apple aborda. Perguntar «a tela estava bloqueada?» e perguntar «o agente poderia usar uma credencial?» são questões diferentes, com evidências diferentes.

Um agente pode ser inofensivo enquanto a tela está desbloqueada e ainda assim se tornar perigoso depois de receber um token de acesso no próprio ambiente. Da mesma forma, um agente pode ser executado durante uma sessão bloqueada e continuar sem conseguir fazer uma solicitação protegida porque a credencial nunca entrou na memória dele e o gateway de ações a recusa. O estado da tela não revela qual desses projetos você tem.

Use esta definição prática durante a revisão:

• O bloqueio da tela controla o uso interativo do Mac.
• O bloqueio do cofre controla se a ação protegida pode ser executada.
• A autorização da sessão controla se aquele processo específico do agente pode solicitar ações protegidas durante seu ciclo de vida.
• Uma chave por chamada controla se uma pessoa precisa aprovar aquele uso específico da credencial.

Esses controles podem se alinhar em uma demonstração agradável. Em produção, eles não devem depender de permanecerem alinhados.

A barreira do cofre precisa de um teste de negação absoluta

Uma barreira absoluta do cofre significa que um cofre bloqueado nega toda ação que usaria uma credencial armazenada. A negação deve ocorrer antes da injeção da credencial HTTP e antes que o auxiliar SSH faça a autenticação. Ela deve valer para um processo que já teve sucesso, não apenas para um processo novo que nunca foi confiável.

O Sallyport torna esse limite explícito: enquanto o cofre está bloqueado, toda ação é negada. Em hardware compatível com o macOS, a barreira do cofre é controlada por hardware com Secure Enclave e Touch ID. Isso é mais forte e mais claro do que uma convenção como «o agente não deve chamar esta ferramenta enquanto estou longe».

O teste mais revelador começa com uma ação bem-sucedida. Configure um endpoint de baixo impacto que você controle, como um endpoint HTTP que registre apenas o método da solicitação e um identificador opaco, ou um host SSH com um comando que imprima uma palavra fixa. Não comece por um endpoint de produção. Você precisa de um alvo cujos logs possam ser inspecionados sem expor um segredo ativo ou alterar algo importante.

Depois, mantenha o processo do agente em execução, bloqueie o cofre pelo aplicativo e solicite a mesma ação novamente. Um resultado correto tem três partes:

1. O chamador recebe uma negação clara, não um timeout nem uma falha de rede genérica.
2. O diário de Activity registra a tentativa como negada, com contexto suficiente para identificar a sessão e o caminho da credencial sem revelar a credencial.
3. Seu endpoint controlado ou host SSH não recebe uma nova solicitação nem um novo comando.

A terceira parte detecta a falha que interfaces bem-polidas escondem. Um gateway pode mostrar uma negação depois de já ter enviado uma solicitação autenticada porque colocou a verificação na camada errada. O log remoto é a testemunha que importa.

Para SSH, evite um teste como ssh host true se o host de teste aceitar outras identidades do seu ambiente normal. Use o canal que o agente usaria, direcione a conexão para uma conta isolada e dê a ela um comando cuja aparição nos logs do servidor seja inequívoca. Se não puder provar qual identidade fez a conexão, você está testando a configuração do seu shell, não o limite do cofre.

Uma aprovação anterior não pode sobreviver à barreira

A autorização por sessão responde a uma pergunta mais específica do que a barreira do cofre: este processo de agente pode usar ações protegidas durante esta execução? Ela não é uma concessão permanente e não pode substituir um cofre bloqueado.

É aqui que as equipes costumam confundir conveniência com autoridade. Elas aprovam um agente, veem várias chamadas serem concluídas, bloqueiam o cofre e depois o desbloqueiam. Quando o processo retoma o trabalho, presumem que a aprovação anterior deve continuar válida ou desaparecer, conforme aquilo que parece mais conveniente. Defina esse comportamento a partir do modelo real de controle e teste-o. A sequência de decisão documentada pelo aplicativo coloca a barreira do cofre em primeiro lugar. Uma barreira fechada prevalece.

Execute esta sequência sem reiniciar o agente:

1. Inicie um processo de agente novo e faça uma chamada protegida. Aprove a sessão quando solicitado.
2. Faça uma segunda chamada protegida usando a mesma credencial comum. Confirme que ela é concluída sem outro cartão de sessão.
3. Bloqueie o cofre enquanto o processo continua em execução. Repita a chamada e confirme a negação antes que o alvo remoto a receba.
4. Desbloqueie o cofre pela interação local exigida. Repita a chamada e registre se a sessão estabelecida retoma a atividade de acordo com as regras documentadas.
5. Encerre o processo do agente, inicie outro processo novo e faça a mesma chamada. Confirme que a nova execução recebe seu próprio cartão de autorização.

O quarto passo não é um detalhe cosmético. Ele mostra se o produto tratou acidentalmente «o cofre foi aberto» como «todo código em execução voltou a ser confiável». O quinto mostra se um identificador de processo, um terminal pai ou um rótulo de cliente genérico se tornou uma concessão não intencional de longa duração.

O cartão de aprovação deve começar pela autoridade de assinatura de código do processo. Um nome de processo é fácil de copiar. Um caminho pode induzir ao erro. A autoridade de assinatura de código oferece ao operador algo mais estável para avaliar quando o processo do agente solicita o uso de um segredo. Registre o que o cartão mostrou durante o teste, incluindo o que você teria visto se uma cópia não confiável do cliente fizesse a mesma solicitação.

O teste de bloqueio da tela tem outra finalidade

Teste o bloqueio da tela do macOS depois de estabelecer o comportamento do cofre, pois a finalidade dele é responder a uma questão operacional diferente: o que pode continuar enquanto ninguém está no console e como você recupera o controle?

Primeiro, deixe o cofre no estado disponível previsto e inicie uma sessão que já tenha sido autorizada. Acione uma ação protegida inofensiva, bloqueie a tela do macOS, espere tempo suficiente para representar sua preocupação normal com trabalho sem supervisão e depois verifique se a ação pôde continuar. Não presuma a resposta. As configurações de energia do Mac, o estado da rede, o ciclo de vida do processo e a própria barreira do aplicativo influenciam o resultado.

Em seguida, faça o mesmo experimento com o cofre explicitamente bloqueado antes de bloquear a tela. O resultado deve ser mais simples: as tentativas de ações protegidas são negadas. Se um agente continuar gerando texto ou editando arquivos locais, isso fica fora desta afirmação específica. A afirmação é que ele não consegue transformar uma chave de API ou SSH armazenada em uma ação externa.

Esse par de testes separa uma escolha de política desconfortável, mas legítima, de um erro de segurança. Alguns desenvolvedores permitem intencionalmente que um agente já aprovado continue tarefas de baixo risco enquanto a tela está bloqueada. Outros exigem que toda ausência bloqueie o cofre. Essas são escolhas operacionais. Permitir que um agente use credenciais depois que o cofre foi bloqueado é uma falha de limite de segurança.

Não faça esse teste observando uma tela bloqueada do outro lado da sala. Registre os horários da solicitação do agente, do endpoint controlado e do diário de Activity. Uma solicitação iniciada antes do bloqueio da tela pode ser concluída depois dele. Isso não prova que ela começou depois do bloqueio. A sequência importa.

A aprovação por chamada serve para ações que você se arrependeria de aprovar em lote

Uma chave por chamada exige aprovação humana a cada uso da credencial. Ela deve ficar acima de uma sessão aprovada, sem substituir a verificação da sessão nem enfraquecer a barreira do cofre.

Inclua uma credencial desse tipo no plano de testes, mesmo que a maioria das chaves use a aprovação comum por sessão. Escolha uma ação-alvo com efeito visível e reversível, como um endpoint de teste que incremente um contador descartável ou um comando SSH que crie um arquivo em um diretório temporário. O objetivo é provar que o aplicativo solicita uma nova aprovação no segundo uso e que rejeitar o pedido impede a ação externa.

Execute o teste a seguir com a tela desbloqueada, para separar o comportamento do pedido do estado da sessão:

• Inicie um processo de agente novo e aprove a sessão.
• Use a credencial por chamada e aprove essa chamada. Verifique um evento remoto.
• Use a mesma credencial novamente e rejeite a aprovação. Verifique que não houve um segundo evento remoto.
• Bloqueie o cofre e use-a mais uma vez. A negação do cofre deve ocorrer sem apresentar uma opção significativa para aprovar uma ação que a barreira não pode permitir.

A recomendação popular de configurar todas as credenciais para aprovação por chamada parece prudente porque transforma toda ação em uma decisão visível. Na prática, ela treina as pessoas a aprovar cartões repetidos sem lê-los. Reserve esse recurso para credenciais cujo uso individual altera dinheiro, acesso, estado de publicação ou outra consequência que você precise acompanhar. Para chamadas rotineiras, uma aprovação de sessão clara, combinada com um cofre que pode ser bloqueado, oferece ao operador menos decisões e decisões mais claras.

Um log remoto detecta a negação que um teste local não identifica

Uma mensagem de erro local prova apenas que o chamador recebeu um erro. Ela não prova que uma solicitação autenticada não saiu da máquina e não diz nada sobre novas tentativas que chegaram depois.

Crie um alvo de teste que informe um identificador curto escolhido por você. A ação do agente pode enviar um cabeçalho inofensivo ou um campo no corpo da solicitação, como test_run=screen-vault-01, desde que o caminho de credenciais configurado no gateway permita esse formato de solicitação. No receptor, registre o horário de chegada, o método, as informações de origem que você normalmente possui e esse identificador. Mantenha o alvo isolado dos dados de produção.

Seu registro de teste deve conter uma tabela pequena como esta:

A palavra «depende» na linha C é intencional. Não esconda uma decisão de política em uma coluna de aprovado ou reprovado. Declare se um processo aprovado pode continuar trabalhando enquanto a tela está bloqueada no seu ambiente e faça o resultado esperado corresponder a essa decisão.

Para HTTP, inspecione os logs da aplicação, não apenas os logs de acesso, caso um proxy reverso possa rejeitar ou repetir solicitações antes que a aplicação as veja. Para SSH, inspecione os registros de autenticação do servidor e dos comandos executados pela conta isolada. Dê a cada tentativa de teste um identificador novo. Reutilizar um único rótulo cria uma discussão sobre entrega atrasada justamente quando você precisa de um resultado limpo.

O registro de auditoria deve explicar a mudança de estado

Um bom histórico de auditoria permite que um revisor reconstrua quem executou o agente, quais ações ele tentou realizar e se o gateway as negou ou executou. O revisor não deveria precisar adivinhar se a ausência de um evento remoto veio de um bloqueio do cofre, de uma conexão de rede perdida ou de um agente que nunca fez a solicitação.

O aplicativo mantém um diário de Sessions para as execuções do agente e um diário de Activity para as chamadas individuais. Ambos vêm de um único log de auditoria criptografado, encadeado por hash e protegido contra escrita, portanto são duas visões do mesmo registro subjacente, não logs concorrentes com histórias diferentes. Quando um teste revelar uma divergência entre os diários, trate-a como uma falha de teste até conseguir explicá-la.

Depois de cada execução de teste, preserve as seguintes observações nas suas anotações:

• A identidade da sessão mostrada durante a autorização e o horário em que você a aprovou ou rejeitou.
• O horário exato em que você alterou o estado do cofre e da tela.
• O resultado de sucesso ou negação informado ao chamador para cada ação tentada.
• As entradas correspondentes nos diários de Activity e Sessions.
• A evidência do alvo controlado de que recebeu ou não recebeu a ação.

Depois, verifique a cadeia offline com:

sp audit verify

Uma execução bem-sucedida deve informar que a verificação foi aprovada, embora o texto exato possa variar conforme a versão. O aspecto útil é que a verificação funciona sobre o texto cifrado e não exige abrir o cofre. Assim, é possível entregar um artefato de auditoria protegido a um revisor que precisa verificar se houve adulteração, sem dar a ele as credenciais nem a capacidade de executar ações.

Não exagere no que esse comando prova. Uma cadeia de hash válida informa que a sequência registrada tem integridade de acordo com o modelo do verificador. Ela não prova que você escolheu o log remoto correto, que o relógio está certo ou que um alvo de teste não tinha outra rota de acesso. Combine-a com as evidências remotas.

O ciclo de vida do processo é o limite que as pessoas ignoram

Uma autorização de sessão deve terminar quando o processo do agente é encerrado. Teste isso explicitamente, pois «abri um terminal novo» não significa o mesmo que «o processo anterior terminou», e um supervisor em segundo plano pode manter um processo filho ativo depois que a interface desaparece.

Comece com uma base limpa. Encerre o processo do agente, confirme pelo seu método normal de inspeção de processos que ele desapareceu e depois inicie outro processo pelo mesmo caminho do cliente. A primeira chamada protegida deve criar uma sessão nova e solicitar autorização. Se o processo herdar a aprovação silenciosamente, descubra qual identidade carregou essa concessão. Pode ser um recurso intencional, mas é uma autoridade muito mais ampla do que a autorização por sessão sugere.

Teste também uma inicialização malsucedida e um cliente copiado. Se um processo do cliente iniciar, solicitar aprovação, terminar antes de chamar uma ação e um processo substituto puder usar essa aprovação, você encontrou uma falha de ciclo de vida. Se um processo assinado de outra forma apresentar o mesmo nome amigável, a interface de aprovação deve fornecer informações de autoridade suficientes para que o operador consiga distingui-lo.

Isso não é uma questão hipotética de organização. As ferramentas de agentes evoluem rapidamente, e os wrappers iniciam auxiliares, reconectam transportes e se recuperam de falhas. O processo que faz a chamada protegida é o objeto que você precisa autorizar. O nome de um projeto ou uma transcrição de conversa não é uma identidade de execução.

Trate repouso, reinicialização e perda de rede como experimentos separados

O bloqueio da tela costuma ser testado em um laptop ativo. Depois, as pessoas presumem que o resultado também vale para repouso, reinicialização e queda de rede. Não vale. Cada evento altera partes diferentes do sistema.

Para o repouso, registre se o processo do agente continua ativo, se o Mac permite o caminho de rede que você usa e se o estado do cofre muda. Para a reinicialização, trate cada execução do agente como nova e exija um novo desbloqueio local antes do uso protegido. Para a perda de rede, verifique se uma chamada malsucedida não provoca uma nova tentativa insegura depois que o cofre é bloqueado ou depois que o processo original termina.

Mantenha esses experimentos pequenos. Um teste útil de novas tentativas usa um identificador de solicitação e um receptor capaz de informar se recebeu zero, uma ou várias chegadas. Inicie a solicitação, remova o caminho de rede em um momento controlado, bloqueie o cofre, restaure o caminho de rede e observe se houve entrega atrasada. Se a solicitação tiver efeitos colaterais, use um receptor descartável. Repetir uma leitura comum é diferente de repetir uma operação que altera o estado.

Não transforme isso em um mecanismo geral de políticas no documento de teste. A pergunta é mais específica: a sequência fixa de decisões continua produzindo o estado de negação esperado quando eventos normais do computador interrompem um agente? Evidências claras valem mais do que uma matriz enorme de regras imaginadas.

O plano de testes concluído deve deixar uma afirmação inequívoca

Seu plano concluído deve permitir que você diga, com evidências, que uma tela do macOS bloqueada e um cofre bloqueado foram testados de forma independente. Ele também deve mostrar se um processo aprovado poderia agir sem supervisão, se a aprovação por chamada bloqueou um segundo uso e se uma chamada negada permaneceu fora do sistema remoto.

Escreva a afirmação final em linguagem simples: «Quando o cofre estava bloqueado, o agente não conseguia usar a credencial HTTP ou SSH configurada, independentemente de a tela do macOS estar bloqueada ou desbloqueada.» Anexe o registro do alvo remoto e o resultado da verificação de auditoria. Depois, acrescente sua decisão operacional separada sobre o que um agente aprovado pode fazer quando apenas a tela está bloqueada.

Essa última frase evita a confusão comum durante uma revisão de incidente. Alguém pode discordar da sua política de trabalho sem supervisão. Essa pessoa não deve conseguir confundi-la com uma prova de que a barreira do cofre funcionou.