# Agentes de IA em várias contas de nuvem: vincule cada ação

Agentes de IA que operam em várias contas de nuvem só trabalham com segurança quando cada solicitação informa um único limite imutável de conta e o executor recusa qualquer divergência. Um agente que consegue dizer «implante em produção», mas não identifica a conta AWS, a assinatura do Azure ou o projeto do Google Cloud por trás dessa expressão, recebeu uma autoridade ambígua.

As equipes costumam tratar isso como uma tarefa de limpeza do IAM. Na verdade, é um problema de desenho da execução. O IAM pode conceder corretamente acesso a duas contas, enquanto o agente, seu wrapper ou um perfil de shell ainda escolhe a conta errada. Quando isso acontece, uma credencial perfeitamente válida faz uma alteração perfeitamente válida no lugar errado.

A solução é menos sofisticada do que um modelo engenhoso de permissões. Defina os destinos executáveis com antecedência, vincule cada um a identificadores emitidos pelo provedor e a uma identidade de execução dedicada, faça o agente solicitar um destino por identificador e verifique o solicitante imediatamente antes de uma chamada que altere estado. Nomes de ambientes legíveis continuam úteis, mas não devem decidir onde o código será executado.

## Destinos ambíguos criam autoridade real

Um rótulo de ambiente não é um limite de autoridade. «Produção» informa a uma pessoa como a equipe pretende usar os recursos. Não informa a uma API qual conta AWS, assinatura do Azure, projeto do Google Cloud, tenant, região ou função assumida deve receber a solicitação.

Essa distinção parece preciosista até que uma empresa tenha `prod`, `production`, `prod-old` e `production-sandbox` espalhados por organizações diferentes. Já vi aliases de contas copiados durante migrações, perfis de shell antigos apontando para contas aposentadas e uma operação de leitura aparentemente inofensiva cair na conta que as equipes de resposta a incidentes tentavam preservar. Os agentes pioram o problema porque interpretam rótulos em linguagem natural literalmente e podem agir muito mais rápido do que a pessoa que percebe a ambiguidade.

Antes da execução, um destino precisa responder a todas estas perguntas:

- Qual provedor é responsável pelo recurso?
- Qual limite imutável de conta receberá a chamada?
- Qual ambiente a organização atribui a esse limite?
- Qual identidade de execução pode agir nele?
- Quais limites geográficos ou organizacionais se aplicam?

A ordem importa. O limite da conta vem antes do rótulo do ambiente. Se uma solicitação diz `environment: production`, mas não informa um ID de conta ou de assinatura, ela está incompleta. Recuse-a, em vez de pedir ao agente que deduza o detalhe ausente pelo nome de um repositório, pelo título de um tíquete ou pela configuração atual do terminal.

Uma recomendação ruim, bastante comum, afirma que convenções de nomenclatura resolvem o problema. Elas ajudam as pessoas a examinar uma lista, mas não funcionam como controle. Nomes são strings mutáveis. Um ID de conta, ID de assinatura, ID de tenant, número de projeto, UID de cluster e ARN de função são referências emitidas pelo provedor, com uma ligação muito mais forte com a identidade.

## Um rótulo de ambiente não deve escolher uma conta

Trate o ambiente como metadado controlado anexado a um registro de destino, e não como uma entrada que resolve o destino no momento da execução. Isso impede que uma solicitação como «aplique esta correção de produção» pesquise um inventário ativo e escolha qualquer conta que coincida com uma tag.

A diferença tem uma consequência prática. Seu catálogo de implantação pode conter vários destinos com `environment: production`: pagamentos, ferramentas internas, serviços regionais e contas criadas durante aquisições. Cada um continua sendo um destino separado. O agente precisa selecionar um identificador aprovado, como `aws-prod-payments`, em vez de enviar um seletor amplo como `environment=production`.

Use os identificadores do provedor que estabelecem o limite real:

| Provedor | Vincule a | Não dependa de |
| --- | --- | --- |
| AWS | ID da conta, partição, ARN da função e região permitida | Alias da conta, nome do perfil e nome de exibição da função |
| Azure | ID do tenant, ID da assinatura e, quando necessário, escopo do grupo de recursos | Nome de exibição da assinatura e seleção do diretório no portal |
| Google Cloud | Número e ID do projeto e, quando relevante, organização ou pasta | Nome de exibição do projeto e configuração local ativa |

O ID do projeto no Google Cloud costuma ser estável o suficiente para ser útil nas solicitações, enquanto o número do projeto oferece uma verificação imutável adicional. O Azure precisa do tenant e da assinatura, porque uma assinatura sozinha não descreve o contexto de identidade que emitiu um token. Na AWS, o número da conta sozinho não informa qual função a ação usará. Vincule os dois.

Não esconda essas informações no texto de um prompt. Uma frase nas instruções do agente dizendo «nunca toque em produção» não impede uma credencial que já permite a ação. O executor confiável precisa ter o registro do destino e decidir se a identidade e o destino solicitados correspondem a ele.

## Um registro de destinos deve conter fatos, não suposições

Mantenha um registro pequeno e revisado dos destinos de nuvem executáveis. Isso não é um segundo sistema de IAM e não deve tentar repetir todas as permissões da nuvem. O IAM da nuvem continua decidindo se uma função pode chamar uma API. O registro responde a uma pergunta mais específica: para onde esta solicitação pode ir quando usa este identificador de destino?

Este exemplo usa identificadores fictícios, mas sua estrutura é intencional:

```yaml
targets:
  aws-prod-payments:
    provider: aws
    environment: production
    account_id: "482901736154"
    partition: aws
    role_arn: "arn:aws:iam::482901736154:role/agent-payments-deploy"
    regions:
      - us-east-1
      - us-west-2

  azure-prod-fulfillment:
    provider: azure
    environment: production
    tenant_id: "2f34c630-1ce8-4ed3-a7ce-8a3286e799a1"
    subscription_id: "841742bf-9db5-4cf8-9f6b-f1778d5b7511"
    scopes:
      - "/subscriptions/841742bf-9db5-4cf8-9f6b-f1778d5b7511/resourceGroups/fulfillment-prod"

  gcp-prod-catalog:
    provider: gcp
    environment: production
    project_id: "catalog-prod-417"
    project_number: "548201736915"
    parent: "organizations/193847561029"
```

O registro deve ser administrado como uma configuração de produção. Atribua a cada destino uma equipe responsável, um processo de revisão e uma data ou status de aposentadoria quando a conta deixar de ser usada. Caso contrário, destinos antigos se tornam silenciosamente um mapa dos lugares que um agente ainda consegue alcançar.

Não crie registros a partir de descoberta livre e permita a execução imediatamente. APIs de inventário da nuvem ajudam a encontrar contas que precisam de um responsável. Elas não são decisões de autorização. Uma conta descoberta pode ser uma cópia forense, uma assinatura administrada por um fornecedor, um remanescente de uma aquisição ou um tenant de testes que compartilha rótulos confusos com a produção.

O registro também evita um problema sutil de desvio. Uma pessoa pode renomear uma assinatura do Azure ou uma função da AWS sem alterar o ID imutável. O rótulo de exibição pode ser atualizado para facilitar a leitura enquanto a vinculação permanece intacta. Se o ID imutável mudar, trate-o como um novo destino que exige revisão, mesmo que o nome continue igual.

## O agente deve solicitar um identificador, nunca montar um destino

Um agente deve enviar a intenção e um identificador de destino. Ele não deve enviar um ARN de função copiado de um comando, um nome arbitrário de perfil de nuvem ou um comando de shell que inclua uma assinatura escolhida pelo usuário. Esses campos dão ao agente controle sobre a parte mais sensível da solicitação.

Uma solicitação pode ser tão simples quanto esta:

```json
{
  "request_id": "chg-8a31f6",
  "target": "aws-prod-payments",
  "operation": "aws.ec2.reboot_instances",
  "region": "us-east-1",
  "arguments": {
    "InstanceIds": ["i-0abc123def4567890"]
  },
  "reason": "Recover the failed checkout worker after approved release"
}
```

O executor resolve `aws-prod-payments` usando o registro que já possui. Ele assume apenas a função listada, rejeita `eu-west-1` porque essa região não aparece no registro e envia a solicitação com a identidade da conta selecionada. O agente nunca recebe uma credencial de nuvem reutilizável durante essa troca.

A falha evitada é fácil de reconhecer. Um agente executa um comando com `--profile prod`, mas o perfil local `prod` de um desenvolvedor aponta para a conta de serviços compartilhados. O comando é sintaticamente correto, a API o aceita e a equipe só descobre o erro quando o worker de pagamentos esperado continua em execução. Um identificador de destino resolvido fora do agente, seguido de uma verificação de identidade, interrompe o comando antes que a solicitação de reinicialização saia do executor.

Não aceite um identificador e um destino fornecido pelo solicitante ao mesmo tempo «por flexibilidade». Isso cria duas fontes de verdade. Se uma solicitação contém `target: aws-prod-payments` e um ARN de função diferente, o executor deve rejeitá-la. Nunca deve escolher o campo que parece mais específico.

## Verifique o solicitante ativo antes de uma gravação

Um registro de destino fixo é necessário, mas não prova que a credencial ativa é a pretendida. Tokens expiram, a assunção de funções falha, perfis locais vazam para subprocessos e SDKs de nuvem podem usar cadeias inesperadas de provedores de credenciais. Verifique a identidade ativa imediatamente antes de uma chamada que altere estado.

Na AWS, a AWS documenta `GetCallerIdentity` como uma operação que retorna a conta, o ARN e o ID do usuário da identidade chamadora. A documentação também informa que a chamada retorna esses dados mesmo quando uma negação explícita normalmente bloquearia a operação. Isso faz dela um bom recurso de diagnóstico e verificação preliminar. Ela não concede permissão para fazer qualquer outra coisa e não substitui a comparação com um registro esperado.

Um comando preliminar tem um formato de saída como este:

```bash
aws sts get-caller-identity --output json
```

```json
{
  "UserId": "AROAEXAMPLEID:agent-run-8a31f6",
  "Account": "482901736154",
  "Arn": "arn:aws:sts::482901736154:assumed-role/agent-payments-deploy/agent-run-8a31f6"
}
```

Compare `Account` com `account_id` do destino. Analise o ARN e compare a função assumida com a função configurada. Não use um teste de substring como «o ARN contém payments». Rejeite uma partição, conta ou função diferente antes da chamada de gravação.

Aplique o mesmo padrão em outros provedores. No Azure, consulte o tenant e a assinatura ativos e compare ambos com o destino selecionado. No Google Cloud, consulte o projeto ativo e o principal autenticado e valide o projeto contra o registro do destino antes de uma chamada que modifique a API. Essas verificações precisam ocorrer no mesmo contexto de processo que envia a ação. Verificar em um terminal e executar em outro oferece apenas uma sensação de segurança.

Há um limite para as verificações preliminares: uma função pode estar correta e ainda ter permissões demais. A própria função de nuvem continua precisando do menor privilégio para o destino atribuído. A vinculação impede que uma solicitação atravesse para uma conta não pretendida. O IAM limita o que a identidade correta pode fazer depois que chega lá. Você precisa dos dois controles.

## Funções amplas entre contas escondem o erro até que ele cause prejuízo

Uma função de administrador capaz de assumir funções em todas as contas é popular porque reduz o trabalho de configuração. Ela também transforma a seleção do destino em uma decisão irreversível e de alto risco. Se o agente ou o executor escolher a conta errada, a mesma identidade ampla geralmente terá acesso suficiente para concluir o erro.

Separe as funções de execução por conta e finalidade. Uma função de implantação de produção para pagamentos não deve ter também um caminho de confiança para as contas de análise, identidade ou recuperação de desastres. Quando um agente precisa de acesso de leitura a várias contas, use funções de leitura separadas e deixe a vinculação do destino visível em cada chamada. O acesso de leitura pode expor dados de clientes, a topologia da infraestrutura e credenciais armazenadas em locais inadequados. Chamá-lo de somente leitura não torna os erros de seleção inofensivos.

Use condições de confiança nativas da nuvem para limitar como uma função pode ser assumida. As políticas de confiança de funções da AWS podem restringir o principal confiável e exigir um ID externo quando esse padrão se adequar ao solicitante. As identidades de carga de trabalho do Azure podem ser limitadas por declarações de credenciais federadas e atribuições de funções a recursos. A personificação de contas de serviço do Google Cloud pode restringir quem pode criar um token de acesso. O mecanismo exato varia, mas o desenho permanece igual: uma identidade de execução deve corresponder a um destino e uma finalidade revisados.

Não confunda uma identidade central de broker com autoridade ampla. Um broker pode coordenar solicitações para muitos destinos, enquanto cada solicitação obtém uma identidade específica do destino. Isso exige mais configuração do que uma função de administrador universal. Também torna visível o raio de impacto quando um processo, prompt ou integração falha.

## A aprovação deve mostrar um destino que a pessoa consiga verificar

Uma pessoa não consegue aprovar uma ação segura se a aprovação esconder o limite da conta. «Reiniciar o worker de pagamentos em produção» pede que o revisor confie em uma lógica de resolução invisível. A aprovação precisa incluir o identificador do destino, o rótulo do ambiente, o identificador imutável da conta, a função ou identidade de serviço ativa, a operação e o escopo de recursos que a API afetará.

Para uma reinicialização de instância na AWS, uma aprovação útil seria:

```text
Target: aws-prod-payments
Environment: production
Account: 482901736154
Identity: agent-payments-deploy
Action: ec2:RebootInstances
Region: us-east-1
Resource: i-0abc123def4567890
Reason: Recover failed checkout worker after approved release
```

Esse nível de detalhe não é teatro de aprovação. Os revisores muitas vezes conhecem o número da conta ou o identificador do próprio serviço, enquanto a descrição do agente pode ser plausível e estar errada. Deixe o destino grande o suficiente para ser examinado antes da descrição da ação. As pessoas percebem um número de conta inesperado mais facilmente do que uma divergência sutil escondida em um payload de comando.

Não peça aprovação geral para «todo o trabalho desta sessão» quando a sessão abrange várias contas de produção. Uma sessão pode ter um limite legítimo, como alterações repetidas em um único destino de implantação, mas não deve se ampliar silenciosamente. Exija nova aprovação quando o identificador do destino mudar, quando uma operação passar de leitura para gravação ou quando a solicitação atingir um escopo mais sensível do que o aprovado pelo revisor.

A autorização por sessão do Sallyport identifica o processo conectado, e sua configuração de credenciais por chamada pode exigir aprovação a cada uso. Isso só ajuda quando a solicitação carrega um destino que o revisor reconhece e o executor já o vinculou a um único lugar.

## Os registros devem conectar intenção, identidade e evidências do provedor

Os registros de auditoria da nuvem informam qual identidade chamou uma API, mas raramente explicam a instrução do agente, a seleção do destino ou a decisão do revisor. Os registros do agente podem explicar a intenção, mas não provam que a nuvem recebeu a chamada esperada. Mantenha os dois registros e relacione-os por um ID de solicitação e pelos identificadores imutáveis do destino.

Para cada ação, registre estes campos antes e depois da execução:

- O processo ou a sessão do agente que fez a solicitação
- O identificador de destino selecionado e seus identificadores imutáveis resolvidos
- A identidade de execução observada durante a verificação preliminar
- A operação, o escopo do recurso, o resultado e o ID da solicitação
- A referência ao evento de auditoria do provedor, quando disponível

AWS CloudTrail, Azure Activity Log e Google Cloud Audit Logs capturam atividades no lado do provedor, conforme os serviços e a configuração de registro usados. Preserve esses registros em seu próprio limite de segurança. Não trate o registro de atividade do agente como substituto das evidências do provedor, porque um processo local comprometido poderia mentir sobre uma solicitação que nunca concluiu.

O Sallyport registra execuções de agentes e chamadas individuais em diários separados, projetados a partir de um registro de auditoria criptografado e encadeado por hashes. O comando `sp audit verify` pode verificar essa cadeia offline sobre o texto cifrado, o que ajuda quando é necessário confirmar se os registros locais de ações foram alterados depois de um incidente.

O teste prático é um exercício de investigação. Escolha uma alteração aprovada e peça a um engenheiro que responda a quatro perguntas sem fazer suposições: qual processo do agente a solicitou, qual destino foi selecionado, qual identidade de nuvem a executou e qual evento no lado do provedor a confirma. Se alguma resposta exigir a correlação manual de horários em três consoles, seus registros são fracos demais.

## Um incidente na conta errada normalmente começa antes da chamada à API

A falha visível costuma ser uma alteração de produção na conta errada. A falha anterior geralmente é um caminho de resolução sem controle. Trate o incidente como um defeito de vinculação, não apenas como o caso de uma pessoa que «usou o perfil errado».

Considere uma sequência plausível. Um repositório contém um script que aceita `ENV=prod`. O wrapper traduz isso para um perfil AWS chamado `prod`. Durante uma migração, um desenvolvedor alterou esse perfil para apontar para uma conta de serviços compartilhados, porque a antiga conta de pagamentos já não precisava de acesso direto. Mais tarde, um agente recebe uma solicitação para reiniciar um worker de pagamentos. Ele encontra o script, define `ENV=prod` e o executa. A resolução do perfil aponta para os serviços compartilhados. A função tem permissões amplas de EC2 porque a equipe a usava por conveniência operacional. A reinicialização é concluída na conta errada.

Nenhuma parte da API da nuvem ficou confusa. O script fez uma solicitação válida com uma identidade válida. Uma correção pós-incidente que apenas diga aos agentes para «verificar a conta novamente» falhará, porque mantém o mesmo caminho de resolução.

Corrija essa classe de falha nesta ordem específica:

1. Desative a sessão ou o caminho da função afetada e preserve os registros de auditoria do agente e da nuvem.
2. Identifique o seletor exato que escolheu o destino errado, como um nome de perfil, uma assinatura padrão, uma tag de ambiente ou um ARN de função fornecido pelo solicitante.
3. Substitua esse seletor por um identificador de destino aprovado e resolvido pelo executor.
4. Adicione uma comparação da identidade ativa que rejeite qualquer divergência antes das gravações.
5. Divida a função ampla se ela permitia ações em contas sem relação.

Depois, teste deliberadamente o caminho de rejeição. Aponte um destino de preparação para uma credencial de outra conta de testes e confirme que o executor para antes da chamada à API que modifica o estado. As equipes costumam testar os caminhos de sucesso e nunca provar que a vinculação de contas falha com segurança.

## A implementação funciona melhor quando começa pelas gravações mais arriscadas

Não espere um inventário completo da nuvem para colocar uma vinculação explícita em torno das ações perigosas. Comece pelas operações que podem alterar ou expor o estado de produção: implantações, mudanças de identidade, alterações de rede, exportações de dados, rotação de segredos e comandos destrutivos de infraestrutura. A descoberta somente leitura pode ajudar a construir o registro, mas não deve conceder silenciosamente acesso de execução a contas recém-encontradas.

Primeiro, liste as contas que podem receber essas ações e atribua a cada uma um rótulo claro de ambiente e um responsável. Em seguida, crie um registro de destino para cada par conta-finalidade. Depois, faça um caminho de execução resolver identificadores, obter credenciais específicas do destino, verificar a identidade ativa e registrar a ação. Por fim, remova o acesso direto dos agentes a perfis disponíveis no ambiente, assinaturas padrão e arquivos de credenciais.

Espere resistência de engenheiros acostumados a trocar de conta no terminal com uma única variável. Esse hábito é rápido porque coloca o contexto na memória de uma pessoa. Um agente autônomo não tem essa memória, e as pessoas que revisam suas ações também não. Coloque o contexto na solicitação, no registro de destinos e nas evidências da execução.

Se você não consegue informar o número da conta, a identidade de execução e o escopo do recurso antes que uma ação seja executada, o agente ainda não tem informações suficientes para agir com segurança. Faça-o reunir os dados que faltam ou mantenha a ação nas mãos de uma pessoa.