# Identidade do agente vs. identidade da credencial: pare de esconder os atores

Um agente de IA que possui uma credencial de produção cria dois problemas de identidade ao mesmo tempo. O agente pode agir como a conta, e depois a equipe precisa fingir que o nome da conta explica quem agiu. Não explica. Uma solicitação de API autenticada como `deploy-bot` informa que alguém possuía a credencial de `deploy-bot`. Ela não informa se o chamador era o agente de programação aprovado, um script de shell copiado, uma dependência maliciosa ou um processo que ficou em execução depois de um teste.

As equipes precisam identificar separadamente o processo que solicitou uma ação e a conta autorizada a executá-la. Isso não é um detalhe de acabamento dos registros de auditoria. Essa separação define se você consegue aprovar uma execução específica do agente, interrompê-la sem afetar trabalhos independentes, investigar uma implantação incorreta e conter uma credencial vazada sem precisar adivinhar.

## Uma credencial identifica autoridade, não o chamador

Uma credencial identifica a autoridade que um serviço concederá, enquanto a identidade do agente identifica o processo que solicitou essa autoridade. Misturar as duas torna todas as decisões de segurança posteriores genéricas demais.

Considere uma solicitação que exclui um objeto do armazenamento em nuvem. A API que recebe a solicitação pode ver um bearer token e associá-lo a uma conta de serviço chamada `release-publisher`. Essa conta responde a uma pergunta de autorização: essa conta pode excluir este objeto? Ela não responde a uma pergunta de atribuição: qual processo local usou o token, quem o iniciou, que código ele executou e alguém aprovou essa execução?

Essas perguntas parecem semelhantes em períodos tranquilos porque o processo esperado e a conta costumam ter o mesmo responsável. Sob pressão, eles se separam. Um desenvolvedor copia o token para um ambiente local. Um agente de programação herda esse ambiente. Um plug-in iniciado pelo agente lê o token. Todas as solicitações continuam aparecendo como `release-publisher`. A camada de autorização funciona exatamente como foi configurada, enquanto a investigação perde o ator.

A identidade da credencial costuma ter vida longa e finalidade ampla. Ela pode ser um token de API, uma credencial privada SSH, uma conta de serviço na nuvem ou o sujeito de um certificado de cliente. A identidade do processo deve descrever algo bem mais específico: este executável, assinado por esta autoridade ou vindo desta imagem, iniciado neste contexto, durante esta execução.

A distinção tem uma consequência prática:

- Revogue uma sessão de processo quando uma execução do agente deixar de ser confiável.
- Desative ou rotacione uma credencial quando houver possibilidade de que seu segredo tenha escapado.
- Altere as permissões da conta quando a própria autoridade for excessiva.
- Investigue o registro do processo quando precisar saber o que realmente aconteceu.

Se um único campo tiver de cumprir as quatro funções, não fará nenhuma delas bem. Chamar uma credencial de `agent-prod-42` não resolve o problema. Um rótulo melhor não transforma um bearer token em prova de quem o apresentou.

## Quatro identidades aparecem em uma solicitação de agente

Uma ação de produção normalmente envolve pelo menos quatro identidades, e um registro de auditoria deve preservar todas elas em vez de reduzi-las ao nome de uma conta.

Primeiro, há a pessoa ou o sistema responsável por iniciar o trabalho. Pode ser um desenvolvedor em um terminal, o acionamento de um trabalho de CI ou uma tarefa agendada. A responsabilidade responde a quem solicitou a execução do agente e quem deve receber os alertas.

Segundo, há o processo do agente. Para um agente de programação local, evidências úteis podem incluir o caminho do executável, a autoridade de assinatura, o identificador do processo, o processo pai, o horário de inicialização e um identificador de sessão aleatório emitido no início. Em um ambiente de contêiner, as evidências equivalentes podem incluir um digest de imagem, um documento de identidade da carga de trabalho, o nome da carga de trabalho do orquestrador e a instância do pod ou da tarefa. Essa identidade responde a qual programa em execução solicitou a ação.

Terceiro, há a identidade da credencial. Ela é a conta de serviço, o principal SSH, o cliente OAuth ou o registro do token de API aceito pelo destino. Ela responde ao que o destino permitirá.

Quarto, há a identidade do destino: o nome do host, repositório, projeto de nuvem, banco de dados ou audiência da API afetada pela solicitação. As equipes costumam registrar um endpoint genérico e só depois descobrem que a ação atravessou um limite de ambiente que nunca pretenderam conceder.

Um registro claro pode ser lido assim:

```json
{
  "event": "http.request",
  "session_id": "ses_7zQ2...",
  "process": {
    "pid": 8421,
    "signing_authority": "Example Developer ID",
    "parent_pid": 8190,
    "launch": "interactive-terminal"
  },
  "credential_ref": "cred_release_publisher",
  "credential_subject": "release-publisher",
  "target": "api.example.internal",
  "operation": "POST /releases",
  "decision": "approved",
  "result": 201
}
```

O `credential_ref` aponta para um registro no cofre. Ele não é o segredo. O bloco do processo fornece a evidência que o sujeito da credencial não consegue fornecer. Agora, um revisor pode ver que uma sessão aprovada usou `release-publisher` contra um destino específico e distinguir essa execução de outra que use a mesma conta mais tarde.

Também não sobrecarregue o campo do responsável humano. A pessoa que pediu a um agente que atualizasse a documentação não é automaticamente a pessoa que aprovou uma implantação de produção que o agente tentou fazer depois. Mantenha separadas a iniciação, o processo, a credencial e o destino. As lacunas desconfortáveis ficam visíveis, e esse é o objetivo.

## Bearer tokens apagam as evidências de que você mais precisa

Um bearer token é aceito porque o chamador o possui, portanto não consegue estabelecer qual processo o está apresentando. Essa é uma característica do mecanismo, não uma falha de registro do seu provedor de API.

A RFC 6750 define diretamente o uso de bearer tokens: qualquer parte que possua o token pode usá-lo. Essa portabilidade tornou os bearer tokens fáceis de implantar, mas também significa que uma API não consegue distinguir o agente aprovado de um processo copiado sem que você acrescente um controle separado. A resposta comum, «colocamos o token em um gerenciador de segredos», trata do armazenamento em repouso. Ela não trata do que acontece depois que um processo recebe o valor.

As melhores práticas atuais de segurança do OAuth 2.0, RFC 9700, apontam na direção certa ao recomendar, quando apropriado, tokens de acesso vinculados ao remetente, além de vida útil curta e restrição de audiência. A vinculação ao remetente pode reduzir a reutilização do token porque o servidor de recursos verifica uma prova do cliente pretendido. Ela não elimina a necessidade de identificar o processo que controla essa prova do cliente. Se um processo de agente consegue usar o material privado da prova, um invasor que controle esse processo ainda pode agir como o cliente.

Essa distinção importa para agentes de IA porque o ambiente em que eles operam é especialmente permeável. Eles leem repositórios, executam comandos, chamam ferramentas, inspecionam variáveis de ambiente e às vezes seguem instruções fornecidas em arquivos ou comentários de issues. Um token exposto ao agente não permanece em um único limite de confiança bem definido só porque a equipe o destinou a uma chamada de ferramenta específica.

Evite a recomendação popular de dar a cada agente um token próprio de longa duração e considerar o problema resolvido. Ela é popular porque produz nomes de contas organizados e painéis simples. Falha quando o agente consegue ler o token, quando outro processo consegue ler o mesmo ambiente ou quando a conta continua existindo depois do fim da execução do agente. Credenciais dedicadas melhoram o cálculo do raio de impacto, mas não comprovam a origem do processo.

Você precisa de dois controles: impedir que o agente receba material secreto reutilizável e manter um registro separado do processo do agente que solicitou cada ação. O primeiro limita o roubo. O segundo torna a aprovação, a revogação e a investigação específicas o bastante para serem úteis.

## A identidade do processo precisa de evidências que sobrevivam a um prompt

A identidade de um processo deve vir de fatos que o sistema operacional ou o ambiente de execução consegue informar, não de uma string fornecida pelo agente em uma solicitação de ferramenta. Um agente que declara `name: trusted-release-agent` fez uma afirmação, não apresentou evidência de identidade.

Em um Mac gerenciado, a autoridade de assinatura de código é um bom ponto de partida. O sistema operacional pode informar a um aplicativo supervisor qual executável assinado foi iniciado e qual autoridade o assinou. Isso não significa que todo programa assinado mereça aprovação. Significa que uma tela de aprovação pode mostrar um fato mais difícil de falsificar do que um rótulo fornecido pelo processo.

Em um servidor, procure evidências equivalentes. Uma identidade de carga de trabalho emitida pelo ambiente de execução, um digest de imagem verificado, um canal com autenticação mútua ou uma atestação do supervisor de processos pode vincular uma ação a uma instância de carga de trabalho. O SPIFFE documenta esse modelo com o SPIFFE Verifiable Identity Document e os X.509 SVIDs: a carga de trabalho recebe uma identidade do ambiente e depois a apresenta a outra carga de trabalho. Esse modelo é mais forte que uma variável de ambiente compartilhada porque a identidade tem escopo definido para uma carga de trabalho.

Não confunda um digest de imagem estático com uma identidade de processo completa. Ele identifica o conteúdo do código, mas uma decisão de ação útil ainda precisa da instância em execução e do contexto de inicialização. A mesma imagem pode ser executada no trabalho de produção pretendido, no ambiente experimental de um desenvolvedor ou em uma tarefa controlada por um invasor. O destino e a sessão continuam fazendo parte da decisão.

Para o trabalho local com agentes, capture as evidências na criação da sessão e vincule as ações seguintes a essa sessão. Um registro mínimo de sessão poderia incluir:

```text
session_id: ses_7zQ2...
executable: /Applications/Agent.app/Contents/MacOS/agent
signing_authority: Example Developer ID
parent_process: /Applications/Terminal.app
started_at: 2025-03-08T14:03:19Z
owner: developer@example.invalid
```

Os campos exatos variam conforme o sistema operacional. A disciplina não muda: o componente que autoriza uma ação deve coletar os fatos do processo por conta própria. Ele não deve confiar que o agente se descreva com precisão depois de já ter recebido uma entrada não confiável.

A identidade do processo também tem limites. A assinatura de código não prova que um agente assinado seguiu instruções seguras. Um digest de imagem não prova que sua configuração é segura. A identidade informa qual ator você aprovou e oferece um mecanismo de revogação. Sozinha, ela não torna segura uma ação arriscada solicitada pelo agente.

## A aprovação deve estar vinculada a uma execução, não ao nome de uma conta

Uma aprovação humana deve autorizar uma sessão específica do processo por um período limitado, não conceder aprovação permanente a qualquer processo que use uma conta mais tarde. Caso contrário, a aprovação se torna uma concessão disfarçada de acesso permanente.

A fadiga de aprovações geralmente começa com a unidade de aprovação errada. As equipes pedem que alguém aprove toda solicitação inofensiva, treinando essa pessoa a clicar sem ler, ou aprovam uma conta de serviço uma vez e nunca mais mostram uma solicitação significativa. Nenhuma das opções identifica o processo ativo.

Use uma aprovação de sessão quando um agente iniciar uma execução. Mostre as evidências do processo que o operador pode avaliar: executável ou nome da carga de trabalho, autoridade de assinatura ou digest da imagem, processo pai ou inicializador, canais pretendidos e identificador da sessão. Depois de aprovado, permita ações por meio dessa sessão até que o processo termine ou o operador a revogue. Um novo processo deve solicitar uma nova sessão, mesmo que planeje usar a mesma credencial.

Reserve a aprovação por ação para credenciais cujo impacto justifique uma interrupção. Uma credencial de administrador de banco de dados de produção, uma identidade SSH com acesso aos hosts da frota ou uma conta capaz de publicar artefatos públicos pode exigir uma decisão humana a cada uso. O acesso comum de leitura não precisa disso. O mecanismo de aprovação deve deixar essa diferença explícita, em vez de escondê-la em um arquivo de políticas enorme que ninguém revisa.

Essa estrutura oferece opções de contenção que o acesso compartilhado não consegue oferecer. Se um agente começar a se comportar mal, revogue a sessão dele. A credencial continua disponível para um processo de lançamento aprovado separadamente. Se você suspeitar de exposição do segredo, desative também a credencial e inspecione todas as sessões que fizeram referência a ela.

O Sallyport usa essa separação diretamente: um novo processo de agente recebe por padrão uma autorização por sessão, enquanto as credenciais ficam em seu cofre criptografado e as ações são executadas fora do processo do agente. A solicitação de sessão destaca a autoridade de assinatura de código do processo, que é a evidência de que o aprovador precisa antes de permitir a execução.

O registro de aprovação deve incluir tanto a sessão do processo quanto a referência da credencial usada depois. Não mostre o valor da credencial na solicitação nem o retorne no resultado de uma ação. Um sistema que esconde um token na interface, mas o coloca na resposta de uma ferramenta do agente, ainda entregou o token ao agente.

## A injeção de credenciais mantém os segredos fora do alcance do agente

O agente deve solicitar uma ação informando uma referência de credencial e um destino, enquanto um executor confiável injeta o segredo apenas no momento em que faz a chamada HTTP ou SSH. O agente recebe o resultado, não a credencial reutilizável.

Essa é uma barreira muito mais precisa do que colocar um token em uma variável de ambiente do shell e pedir ao agente que não o imprima. Variáveis de ambiente vazam para processos filhos, saídas de depuração, relatórios de falha, mecanismos de histórico de comandos e chamadas de ferramentas. A ocultação ajuda a evitar a exibição acidental depois do fato, mas não consegue recuperar um segredo de um processo que já o leu.

Uma solicitação de ação segura contém detalhes suficientes para autorizar e executar a chamada sem conter a própria credencial:

```json
{
  "session_id": "ses_7zQ2...",
  "credential_ref": "cred_release_publisher",
  "channel": "http",
  "request": {
    "method": "POST",
    "url": "https://api.example.internal/releases",
    "headers": {"Content-Type": "application/json"},
    "body": {"version": "1.4.2"}
  }
}
```

O executor verifica se a sessão continua aprovada, confirma que o cofre está disponível, busca `cred_release_publisher`, injeta a credencial no cabeçalho de autorização necessário, executa a solicitação e registra a decisão e o resultado. Ele deve retornar os dados da resposta necessários para a tarefa do agente, aplicando antes os tratamentos usuais exigidos para conteúdo sensível.

O mesmo princípio vale para SSH. O agente pode solicitar `git fetch` ou um comando remoto por meio de um canal SSH, mas não deve receber a credencial privada como um bloco PEM nem um soquete de agente que qualquer processo filho possa usar sem supervisão. O executor pode usar a credencial privada para a conexão e vincular o evento à sessão do agente.

Atualmente, o Sallyport oferece injeção de credenciais HTTP e ações SSH por meio de seu auxiliar integrado, portanto um agente compatível com MCP pode solicitar o trabalho sem possuir o segredo de API ou SSH. Esse projeto não torna toda ação segura. Ele preserva a separação necessária para decidir se o processo deve ter permissão para solicitá-la.

## Um token de implantação compartilhado esconde a falha até o momento crítico

Uma credencial compartilhada transforma um incidente simples em um exercício de reconstrução porque o mesmo nome de conta aparece em todas as linhas de registro relevantes. A falha geralmente começa com um atalho razoável.

Imagine uma equipe que mantém `PUBLISH_TOKEN` em um armazenamento de segredos de CI. O trabalho de implantação o lê, como esperado. Um desenvolvedor também o exporta localmente para reproduzir um problema de lançamento. Mais tarde, inicia um agente de programação nesse shell porque o agente precisa inspecionar os scripts de implantação. Agora, o agente consegue chamar a API de lançamentos por meio do ambiente.

Uma instrução escondida em um arquivo do repositório manda o agente executar um comando que envia uma versão preliminar. O comando funciona. O registro de auditoria da API diz `release-publisher created release 1.4.2`. O registro do CI não mostra nenhum trabalho correspondente. O desenvolvedor diz que só pediu ao agente para inspecionar os arquivos. Todos conseguem concordar com esses fatos, mas nenhum identifica o processo que fez a chamada.

A equipe costuma responder rotacionando `PUBLISH_TOKEN`. Isso impede a reutilização se o token vazou, mas também interrompe o trabalho legítimo de CI e exige uma correção apressada. Depois, a equipe pode culpar o desenvolvedor, o agente ou a instrução do repositório sem ter evidências. O nome da conta não permite distinguir uma execução do CI de uma ação do agente local.

Agora, mude o projeto. A credencial de lançamento permanece em um cofre controlado por um executor de ações. O agente inicia uma sessão que registra sua autoridade de assinatura e o terminal pai. Ele solicita a ação de envio por meio dessa sessão. O executor registra a decisão de aprovação, a referência da credencial, a API de destino, o caminho da solicitação e o status da resposta.

Quando ocorre o envio suspeito, o registro do incidente responde imediatamente às primeiras perguntas úteis: ele veio de uma sessão de agente local, essa sessão começou em um terminal específico, recebeu autorização em um horário determinado e usou a credencial de lançamento em uma única solicitação POST. O operador revoga essa sessão. O CI continua funcionando porque seu processo identificado separadamente não foi revogado. Se a instrução do repositório puder ter exposto segredos mais amplos, a equipe ainda poderá rotacionar a credencial, mas fará isso porque as evidências justificam a ação, não porque não dispõe de nenhum outro controle.

A diferença não é uma prevenção perfeita. Um agente aprovado ainda pode solicitar uma ação que um humano depois se arrependa de ter aprovado. A diferença é que o sistema preserva um ator, uma decisão de autorização e um mecanismo de interrupção direcionado. Isso basta para encurtar um incidente, em vez de transformá-lo em uma discussão.

## Os registros de auditoria devem relacionar identidades sem armazenar segredos

Uma trilha de auditoria deve permitir relacionar uma sessão de processo, uma referência de credencial e uma ação externa, mantendo o material secreto fora do registro. Se esses dados estiverem em produtos separados, sem um identificador de evento comum, a resposta a incidentes dependerá de correlação manual sob pressão.

Escreva um evento para a decisão da sessão e um evento para cada ação. Use o mesmo `session_id` nos dois tipos e dê a cada ação seu próprio identificador de evento. Armazene uma referência da credencial e o sujeito da credencial, se for seguro mantê-lo, mas nunca armazene o bearer token, a credencial privada ou o cabeçalho de autorização bruto.

Um registro de ação útil inclui o destino normalizado, o método ou comando remoto, o digest da solicitação quando os corpos puderem conter dados sensíveis, a decisão, o status da resposta e os horários. Para SSH, registre o host, o usuário remoto, o comando solicitado e o resultado de saída. Para HTTP, registre o método, o host, o caminho e o status. Capture o corpo bruto somente quando suas regras de retenção e tratamento de dados permitirem.

A evidência contra adulteração importa porque o processo que executa uma ação pode depois ser acusado de ocultá-la. Uma cadeia de hashes torna a remoção ou reorganização detectável quando o investigador tem a sequência completa. Ela não torna um evento verdadeiro. Se o coletor aceitar um nome de processo fornecido pelo agente, um registro perfeitamente encadeado preservará essa afirmação falsa para sempre. Colete primeiro as evidências da identidade no limite de supervisão e depois proteja o registro.

Um processo simples de verificação deve funcionar independentemente do conteúdo do cofre. O verificador lê cada bloco de evento criptografado, confere se o hash anterior armazenado corresponde ao hash do evento anterior, recalcula o hash atual e informa a primeira posição quebrada. A saída deve identificar a posição na sequência sem expor segredos:

```text
$ audit verify events.log
verified: 184 events
chain: valid
first_event: evt_01J...
last_event: evt_01K...
```

Se a verificação falhar, preserve os arquivos originais antes de tentar corrigi-los. Um registro ausente pode significar corrupção, uma gravação interrompida, um problema no tratamento da exportação ou uma alteração deliberada. A cadeia identifica a inconsistência; seus registros complementares e controles de armazenamento explicam a causa.

## Separe as identidades antes de adicionar mais automação

As equipes podem adotar esse modelo sem reconstruir todas as integrações de API. Comece pelas credenciais que podem alterar o estado de produção, publicar artefatos, acessar dados de clientes ou conectar-se por SSH. Essas são as contas que geram os incidentes mais difíceis quando um processo de agente as herda.

Faça uma primeira etapa concreta:

1. Liste cada sujeito de credencial, os serviços que ele pode alcançar e todos os processos que atualmente recebem seu segredo.
2. Remova valores secretos reutilizáveis dos prompts dos agentes, da configuração dos agentes e dos ambientes dos processos de agentes.
3. Defina quais evidências do processo você consegue coletar no ponto em que as ações são autorizadas.
4. Emita um identificador de sessão para cada execução de agente e registre-o ao lado da referência da credencial em cada ação.
5. Teste a contenção revogando uma sessão enquanto outra carga de trabalho aprovada continua usando a mesma conta.

O último teste revela rapidamente o erro mais comum. Se você só consegue interromper um agente desativando a conta compartilhada, não separou a identidade do agente da identidade da credencial. Apenas deu um nome amigável a um risco compartilhado.

Não comece com um mecanismo de regras enorme. A maioria das equipes precisa de algumas decisões claras: o cofre está disponível, esta sessão de processo está aprovada e esta credencial exige aprovação para esta ação? A parte mais complexa é a disciplina operacional: parar de enviar segredos para processos de agentes, coletar evidências confiáveis do processo e recusar-se a tratar o nome de uma conta de serviço como se fosse uma pessoa ou um programa.

Quando a próxima ação questionável aparecer, exija uma resposta para duas perguntas separadas: qual processo solicitou isso e qual autoridade executou a ação? Se seus registros não conseguirem responder às duas, corrija esse problema antes de conceder acesso de produção a outro agente.