Uma tabela de evidências SOC 2 pode comprovar as ações dos agentes?

A atividade de agentes cria um problema de auditoria que os registros comuns de aplicações não resolvem. Um registro de conta de serviço pode informar que uma credencial chamou um endpoint. Em geral, ele não consegue dizer se um processo de agente específico tinha autoridade naquele momento, se uma pessoa aprovou a ação, se a autoridade foi retirada depois ou se o registro entregue ao auditor é o mesmo produzido na ocasião.

Um pacote de evidências SOC 2 útil precisa reconstruir uma decisão, não apenas exibir uma linha do tempo. Para cada ação relevante, o auditor deve conseguir passar do agente e da autorização à chamada, ao resultado e à integridade do registro retido. Se alguma conexão depender da memória de um administrador ou de uma planilha editada manualmente, o controle é mais fraco do que parece.

O Sallyport foi criado em torno dessa cadeia: o agente recebe os resultados das ações, enquanto as credenciais permanecem no cofre local criptografado e o aplicativo registra a execução do agente e cada chamada individual. Esse projeto só é útil quando seus registros se transformam em evidências testáveis, em vez de serem tratados como um adereço de conformidade.

Um controle precisa representar uma decisão que possa ser reconstruída

Os Trust Services Criteria da AICPA de 2017 são critérios, não um menu de capturas de tela. Os critérios comuns de segurança pedem que a administração estabeleça e opere controles que restrinjam o acesso lógico, monitorem a operação do sistema, respondam a problemas identificados e gerenciem mudanças. O auditor testa o controle descrito, sua população e se ele funcionou durante o período do exame.

Essa distinção importa para ações de agentes. «O agente precisava de aprovação» descreve um comportamento do produto. «Cada processo de agente recém-iniciado precisava de uma autorização atribuível antes de usar um canal de ação protegido, e a empresa reteve registros que conectam a autorização às chamadas resultantes» é uma declaração de controle que pode ser testada.

Escreva o risco antes de redigir o pedido de evidências. Uma declaração prática de risco seria:

Um processo de agente não aprovado ou que já teve sua aprovação retirada poderia chamar uma API externa ou executar um comando SSH usando credenciais da organização, causando acesso não autorizado ou uma alteração operacional não autorizada.

O controle deve responder ao risco em linguagem simples. As evidências devem responder a cinco perguntas mais específicas:

1. Qual processo tentou realizar a ação?
2. Que autoridade ele tinha naquele momento?
3. Quem, se alguém, concedeu essa autoridade?
4. Qual ação externa exata ocorreu depois?
5. É possível detectar uma tentativa de reescrever o histórico?

As equipes costumam misturar essas perguntas. Chamam uma lista de permissões de destinos de controle de aprovação, uma resposta de API bem-sucedida de registro de autorização ou uma exportação de registros de imutável porque a exportação é somente leitura. Cada afirmação descreve uma coisa diferente.

Uma restrição de destino limita onde um processo pode agir. Os registros de autorização mostram quem permitiu que ele agisse. Os registros de chamadas estabelecem o que ele tentou fazer e o que aconteceu. A verificação de integridade trata da possibilidade de a sequência retida ter sido alterada. Mantenha essas afirmações separadas na descrição do sistema e na tabela de evidências. Os auditores não precisam de linguagem da moda. Precisam de um responsável pelo controle que consiga fazer uma afirmação delimitada e apresentar o registro correspondente.

A tabela de evidências SOC 2 que os auditores podem testar

Use uma tabela de evidências como acordo de trabalho entre engenharia, segurança e auditoria. Não a transforme em uma lista de recursos do produto. Cada linha deve indicar o risco, a atividade de controle, a população de origem, o método de teste e o sinal de falha.

As referências aos critérios são pontos de partida, não uma promessa de cobertura. A descrição do serviço, a avaliação de riscos, os limites do sistema e o julgamento do auditor determinam o mapeamento final. Em especial, não force todos os registros de agentes para CC8.1. Os exemplos e orientações da AICPA tratam o gerenciamento de mudanças como controle sobre alterações em programas de aplicação e tecnologias relacionadas. Uma chamada que edita a conta de um cliente, envia uma resposta de suporte ou reinicia um processo remoto é uma ação operacional. Ela só se torna evidência de gerenciamento de mudanças quando faz parte de uma alteração aprovada e testada no próprio sistema.

A tabela também evita uma falha comum na semana da auditoria: coletar um artefato perfeito de apenas um dia. Um exame Tipo 2 pergunta se os controles declarados funcionaram efetivamente durante todo o período. A coluna da população não é burocracia. Ela informa qual universo completo você precisa conseguir produzir antes que alguém faça a amostragem.

A aprovação de sessão comprova a autoridade do processo, não a governança de identidades

A aprovação por sessão é uma evidência de que uma execução específica de agente recebeu permissão para usar o gateway de ações. Ela não comprova que a empresa administrou corretamente o acesso de funcionários, provisionou corretamente uma conta no provedor de identidades ou revisou uma função de administrador na nuvem. Esses pontos exigem controles e registros próprios.

A afirmação útil é mais restrita. A primeira chamada protegida de um processo novo recebe uma decisão de aprovação antes que a sessão possa agir. O registro deve preservar um identificador de sessão, a identidade do processo, a autoridade de assinatura de código quando disponível, o horário da decisão, a identidade do aprovador e o estado de término. No Sallyport, o cartão de aprovação destaca primeiro a autoridade de assinatura de código do processo. Assim, a decisão humana se refere ao executável que realmente solicitou acesso, e não a um rótulo vago fornecido pelo agente.

Essa é uma distinção importante. Um agente pode se chamar como quiser em um prompt, no título de um terminal ou em um argumento de processo. Um controle que aprova um nome declarado pelo próprio agente permite um desvio simples. Um controle que mostra a autoridade de assinatura de código oferece ao revisor um atributo estável para avaliar. Isso não elimina a necessidade de confiar no software assinado, mas deixa claro o limite dessa confiança.

Para testar uma aprovação de sessão, peça ao auditor que selecione uma amostra da população de sessões e rastreie cada registro nas duas direções:

• Comece pela aprovação da sessão e encontre a primeira chamada protegida que veio depois.
• Comece por uma entrada de atividade e encontre a sessão que a autorizou.
• Confirme que o horário da chamada é posterior à aprovação e anterior à saída ou revogação da sessão.
• Confirme que sessões negadas não têm chamadas protegidas bem-sucedidas.
• Confirme que o registro da sessão identifica o processo com força suficiente para o controle declarado.

Não dependa de uma captura de tela da caixa de diálogo de aprovação. Capturas de tela ajudam a documentar o desenho do controle, mas não são evidências da população. Um registro precisa sobreviver ao fechamento da caixa de diálogo, permitir consultas por identificador e se conectar ao registro de atividade sem que alguém escolha manualmente qual linha parece correta.

Também evite afirmar que a aprovação de sessão representa privilégio mínimo quando isso não é verdade. Uma decisão de sessão pode controlar se um processo pode agir. O privilégio mínimo depende das credenciais, do escopo de destinos, das operações e das permissões disponíveis depois da aprovação. Se um agente aprovado puder usar uma credencial com direitos irrestritos de produção, a aprovação é uma barreira, não uma redução de escopo. Descreva-a dessa forma.

A aprovação por chamada é para ações que não podem ser agrupadas com segurança

Um controle de aprovação por chamada oferece uma garantia diferente da aprovação de sessão. Ele exige uma nova decisão humana no momento em que o uso de uma credencial específica está prestes a ocorrer. Use-o para ações em que o risco está na invocação individual, e não apenas em permitir que um processo de agente comece a trabalhar.

Boas candidatas incluem uma credencial de produção capaz de alterar direitos de acesso, excluir dados, modificar informações de cobrança, publicar uma implantação ou executar comandos em um host especialmente sensível. O objetivo não é tornar tediosa toda ação do agente. É colocar a revisão no limite da transação, onde um único uso indevido teria impacto.

As evidências precisam vincular a aprovação a um único uso. Um registro de atividade adequado contém pelo menos:

• Um identificador único da chamada e o identificador da sessão associada.
• A referência à credencial protegida, sem colocar seu valor secreto no registro.
• O canal, o destino, a operação e o horário.
• O estado da decisão e o aprovador quando a chamada exigiu aprovação.
• O resultado, incluindo uma resposta negada, com falha ou concluída.

Não aceite um registro de aprovação que apareça apenas perto de uma ação posterior. Proximidade temporal não cria vínculo. Se um revisor aprova a Chamada A e o agente executa a Chamada B com a mesma credencial, as evidências precisam mostrar se B exigiu e recebeu aprovação própria.

É aqui que as equipes costumam exagerar na correção. Elas colocam uma pessoa diante de ações rotineiras de leitura, e os revisores aprovam uma sequência de cartões quase idênticos sem analisá-los. O controle ainda cria registros, mas a revisão se tornou uma formalidade. Reserve a aprovação por chamada para a classe restrita de credenciais ou ações que realmente merecem esse nível de análise. Use aprovação de sessão para o trabalho comum e reduza o escopo das credenciais separadamente.

O revisor precisa de contexto suficiente para decidir. Para uma ação HTTP, isso normalmente significa método, destino, identidade da credencial e uma descrição segura do efeito da solicitação. Para SSH, significa a identidade do host e o comando, ou uma descrição de comando restrita. Nunca coloque o segredo no conteúdo da aprovação apenas para tornar as evidências mais detalhadas. Um segredo revelado ao revisor por um cartão de aprovação continua sendo um segredo revelado.

A revogação precisa gerar uma negação que possa ser demonstrada

A evidência de revogação não serve se registrar apenas um evento da interface. O controle está funcionando quando a autoridade termina e uma tentativa posterior falha por esse motivo.

Faça este teste antes que um auditor o solicite. Inicie uma sessão com permissão para usar uma ação de teste não produtiva. Confirme uma chamada bem-sucedida. Revogue a sessão enquanto o processo continua em execução. Em seguida, faça o mesmo processo tentar uma segunda chamada. Preserve os quatro registros relacionados: a primeira chamada bem-sucedida, o evento de revogação, a segunda chamada negada e o estado da sessão.

Sua planilha de teste pode ser simples assim:

Test ID: AGT-REV-01
Session ID: ____________________
First call ID and result: ____________________
Revocation time and actor: ____________________
Second call ID and denial result: ____________________
Reason shown for denial: ____________________
Reviewer and date: ____________________

A ordem é o controle. Um evento de revogação às 14:03 seguido de uma chamada bem-sucedida às 14:07 indica uma falha, um problema de relógio ou que o identificador da sessão não significa o que você afirmou. Nenhuma dessas possibilidades merece uma explicação superficial.

Trate a saída normal da sessão e a revogação explícita de forma diferente. A saída encerra um processo porque ele parou de executar. A revogação encerra a autoridade porque um revisor decidiu retirá-la. Ambas devem bloquear chamadas posteriores, mas somente a revogação demonstra que uma pessoa pode terminar uma execução ativa diante de uma preocupação. Mantenha os tipos de evento separados na tabela de evidências.

Esse controle também pertence à prática de resposta a incidentes. Se um revisor identificar uma sequência suspeita de chamadas, ele deve saber quem pode revogar a execução, quanto tempo a negação leva para entrar em vigor e onde o evento aparece no diário. Um procedimento escrito que diga «desative o agente», sem indicar a ação efetiva, não é suficiente quando o agente já está executando trabalho.

A verificação offline testa o histórico depois que a aplicação sai de cena

Um diário de atividades fornece responsabilização. Uma cadeia de hash verificável de forma independente oferece um meio de testar se a sequência retida continua íntegra. Esses recursos estão relacionados, mas não são intercambiáveis.

O Sallyport projeta as visões de sessão e atividade a partir de um único registro de auditoria criptografado e somente para gravação. O comando offline sp audit verify verifica a cadeia sobre o texto cifrado e não precisa de acesso ao cofre. Isso é uma evidência útil porque o verificador pode testar o histórico retido sem pedir que o sistema que produziu o relatório descriptografe credenciais ou conceda acesso ao cofre.

Não exagere no que isso comprova. A verificação da cadeia de hash pode detectar um registro ausente, reordenado ou alterado dentro do escopo verificado, dependendo do desenho da cadeia e do material retido. Ela não comprova que a aplicação emitiu todos os eventos que deveriam existir. Também não comprova que a fonte de tempo estava correta, que o aprovador tomou uma boa decisão ou que a API externa subjacente fez o que declarou. Essas são perguntas de controle diferentes.

Mantenha um registro de verificação para um intervalo retido definido. Este formato de documento de trabalho é suficiente para muitas equipes:

{
  "verification_id": "audit-2026-07-15-01",
  "period_start": "2026-07-01T00:00:00Z",
  "period_end": "2026-07-14T23:59:59Z",
  "command": "sp audit verify",
  "verifier_version": "record the installed version",
  "source_archive": "encrypted audit export identifier",
  "result": "pass or fail",
  "performed_by": "reviewer identity",
  "exceptions": []
}

Não invente um resultado limpo depois de uma verificação com falha. Registre a falha, preserve o material, determine se ela veio do tratamento da exportação, da retenção, de um defeito de software ou de uma possível alteração, e encaminhe o caso pelo processo de incidentes. Uma verificação de integridade com falha não é automaticamente uma violação. É um evento que exige investigação porque sua cadeia de evidências deixou de ser confiável.

Execute a verificação em uma frequência compatível com o volume e o risco da atividade dos agentes, e novamente antes de montar as evidências. Um trabalho mensal pode ser suficiente para um ambiente pequeno. Uma equipe que permite que agentes operem sistemas de produção o dia todo não deveria esperar até o fim do trimestre para descobrir um problema de integridade. A frequência importa menos do que conseguir mostrar que o teste foi executado de forma consistente e que alguém tratou as falhas.

Ações operacionais e mudanças no sistema precisam de provas separadas

Este é o limite que mais costuma ficar confuso. Uma ação de agente pode alterar alguma coisa. Isso não a transforma em uma mudança controlada do sistema para CC8.1.

Considere três exemplos. Um agente usa uma API para alterar o status da assinatura de um cliente. Isso é uma operação de negócio e exige autorização, rastreabilidade e talvez revisão. Um agente edita um arquivo de infraestrutura em um repositório de código-fonte, o pull request recebe revisão, os testes passam e um pipeline de implantação o aplica. Isso é uma mudança no sistema. Um agente executa um comando SSH que edita diretamente um arquivo de configuração de produção. Isso é uma ação operacional de risco elevado e provavelmente uma violação do processo de mudanças se a política exigir implantações revisadas.

O pacote de evidências deve tornar esses caminhos visíveis, em vez de permitir que o revisor os deduza da prosa. Adicione uma classificação da ação ao registro de atividade ou à análise de evidências:

A CC8.1 espera que a administração autorize, projete, desenvolva ou configure, documente, teste, aprove e implemente mudanças em infraestrutura, dados, software e procedimentos. Um diário de agente pode enriquecer essa história ao mostrar que um agente abriu um pull request ou acionou uma operação relacionada à implantação. Ele não substitui a revisão, as evidências de teste e o registro de implantação.

Isso é impopular porque um único registro de auditoria parece capaz de responder a tudo. Não é. Mantenha a trilha de atividades do agente como registro da ação delegada. Mantenha os registros de mudanças de engenharia como prova de que as alterações do sistema seguiram o caminho exigido. Conecte-os apenas quando o agente tiver participado desse caminho.

Monte o pacote de evidências a partir de uma população, não de uma pasta de capturas de tela

Monte um pacote repetível para cada período de análise. A primeira tarefa é definir a população. Para a atividade de agentes, isso normalmente significa todas as sessões, todas as chamadas protegidas, todas as chamadas negadas, todas as revogações e todas as execuções de verificação de registros durante o período. Se você não consegue produzir contagens ou uma exportação completa, não pode afirmar de forma convincente que o auditor selecionou a amostra da população inteira.

Depois, prepare um pequeno manifesto de evidências que aponte para artefatos de origem imutáveis ou retidos. Não envie uma pilha de arquivos com nomes como final-final-auditoria. Use identificadores estáveis, local de origem, período, responsável e uma nota explicando o que o artefato comprova.

Um revisor pode seguir esta sequência:

1. Obter as populações de sessões e atividades do período, além dos registros de verificação de integridade.
2. Conciliar o número de identificadores de sessão referenciados pelas entradas de atividade com a população de sessões e investigar os registros sem correspondência.
3. Selecionar amostras entre sessões aprovadas, tentativas negadas, chamadas sensíveis, revogações e diferentes intervalos de tempo.
4. Rastrear cada chamada selecionada até sua autorização e, depois, até seu resultado. Em seguida, examinar o registro de verificação que cobre o intervalo retido.
5. Para alterações no gateway ou em controles de produção relacionados, rastrear separadamente o pull request, os testes, a aprovação e o registro de implantação correspondentes.

Essa sequência expõe lacunas rapidamente. Se uma chamada não tem sessão, a conexão com a autorização falhou. Se uma sessão não tem identidade de processo, não é possível testar a afirmação sobre o processo. Se uma revogação não tem um teste de negação posterior, você só sabe que alguém clicou em um botão. Se os registros de verificação cobrem um arquivo que não pode ser reproduzido, a afirmação de integridade é fraca.

Mantenha as anotações do revisor junto da amostra. Uma nota curta como «O ID da chamada 54b correspondeu ao ID da sessão 12a; a sessão foi aprovada pelo funcionário A; a aprovação por chamada era necessária e estava presente; o resultado da atividade foi concluído; a verificação do intervalo de auditoria foi aprovada» é mais útil do que dez capturas de tela. Ela informa ao próximo revisor o que foi testado e deixa um rastro quando o controle muda.

As evidências falham quando os responsáveis não conseguem explicar as exceções

Até a melhor tabela de evidências falha se ninguém for responsável pelo caminho das exceções. Ações de agentes serão negadas. Pedidos de aprovação expirarão. Chamadas falharão no endpoint remoto. Sessões serão revogadas. A verificação pode informar um problema. Esses resultados devem aparecer na população, e a equipe precisa saber quais exigem ação.

Defina um conjunto moderado de categorias de exceção: tentativa não autorizada, rejeição de aprovação, falha da ação remota, tentativa posterior à revogação, conexão de registros ausente e falha de verificação. Atribua um responsável, uma frequência de revisão e um registro esperado a cada uma. Não transforme toda solicitação de API negada em incidente de segurança. Negações repetidas de um processo assinado inesperado provavelmente merecem mais atenção do que um engenheiro recusando o próprio comando experimental.

O teste útil é saber se alguém consegue explicar uma exceção selecionada sem montar uma história a partir de mensagens de chat. O registro de atividade deve indicar o motivo imediato. O registro da sessão deve identificar a execução. O acompanhamento deve informar se a equipe aceitou o resultado, corrigiu a configuração, revogou o acesso ou abriu um processo de incidente.

É também aqui que as mudanças de controle precisam de disciplina. Se você alterar o comportamento de aprovação, as marcações de credenciais, os campos de registro ou o procedimento de verificação dos registros retidos, trate isso como uma mudança no ambiente de controle. Atualize a narrativa do controle, teste o novo comportamento e registre a implantação pelo processo de engenharia existente. Caso contrário, sua tabela de evidências descreverá o sistema do trimestre passado enquanto os agentes deste trimestre usarão outra coisa.

Não espere o auditor perguntar se as evidências se conectam. Escolha uma sessão real nesta semana, rastreie-a da autorização ao resultado da chamada, revogue-a em um ambiente seguro e verifique offline o intervalo de auditoria retido. Se sua equipe não conseguir concluir esse exercício com os registros já disponíveis, corrija o caminho das evidências antes de discutir a redação do controle.