Nomes de usuário da autenticação Basic são metadados sensíveis

Os nomes de usuário da autenticação Basic são metadados sensíveis.

Essa afirmação parece exagerada até você precisar limpar os rastros de uma execução de automação que copiou billing-export@north-division para uma transcrição do shell, um log de CI, um prompt de agente e um ticket de incidente. A senha pode estar ausente dos quatro lugares. Ainda assim, um invasor descobre que existe um tenant north-division, que ele tem uma integração de exportação de faturamento e que a conta provavelmente acessa uma determinada API legada.

As equipes costumam separar os dados entre segredos e todo o resto. Essa divisão é simplista demais para o trabalho com APIs conduzido por agentes. Um nome de usuário, um ID de tenant, um hostname, um caminho de API e um código de resposta podem parecer inofensivos quando vistos isoladamente. Juntos, eles descrevem uma estrutura de contas que vale a pena atacar. Trate essas combinações como metadados sensíveis, especialmente quando um agente pode copiar contexto muito mais longe e muito mais rápido do que uma pessoa digitando uma única requisição.

Um nome de usuário pode revelar como o sistema de contas foi construído

Um nome de usuário Basic costuma carregar mais significado do que o nome do campo sugere. Sistemas legados usam esse valor como nome de login, código de cliente, rótulo de divisão, função de serviço, indicador de ambiente ou identificador composto, criado antes de alguém ter um modelo de identidade melhor.

Considere estes valores:

acme-east:password
svc-payroll-prod:password
tenant-48291-export:password
[email protected]:password

O primeiro valor informa um cliente e uma divisão regional. O segundo revela uma capacidade interna e um ambiente. O terceiro expõe um identificador de tenant e uma função. O quarto mostra uma pessoa e sua relação com um cliente. Trocar a senha corrige a metade referente à senha. Isso não faz desaparecer o mapa de contas que foi copiado.

Isso importa porque os invasores não começam todo ataque com uma credencial. Eles começam com uma lista de alvos. Um nome de usuário reconhecível ajuda a criar uma solicitação de redefinição convincente, adivinhar contas relacionadas, pesquisar vazamentos de dados, sondar uma rota específica de cliente ou pressionar o suporte com detalhes que parecem internos.

Não descarte esse risco como algo teórico só porque o nome de usuário precisa de uma senha. Saber que svc-orders-import-prod existe não equivale a controlá-lo, mas é muito mais útil do que não saber nada. O trabalho de segurança fica caro quando as equipes esperam que um campo seja uma credencial completa antes de protegê-lo.

A classificação correta depende do contexto. Um nome de usuário público e genérico, usado por todas as contas de sandbox, pode exigir pouca proteção. Uma identidade de serviço vinculada a um tenant e associada a um endpoint interno merece um tratamento muito mais rigoroso. Registre essa distinção para cada integração, em vez de aplicar um rótulo genérico depois de um vazamento.

A autenticação Basic mantém o nome da conta ligado a cada chamada

A autenticação Basic envia um valor user-id:password codificado em Base64 no header HTTP Authorization. Base64 muda a representação. Ela não oculta os bytes originais de quem consegue ler o header.

Uma requisição típica é assim:

GET /v1/exports/monthly HTTP/1.1
Host: api.legacy.example
Authorization: Basic c3ZjLWJpbGxpbmctZXhwb3J0LXByb2Q6cmVkYWN0ZWQ=
Accept: application/json

O texto codificado carrega as duas partes sempre que o cliente chama a API. Essa repetição é o aspecto incômodo que as equipes esquecem. Um bearer token também pode expor o contexto da conta, claro, mas muitas integrações Basic usam nomes de usuário legíveis que deixam esse contexto explícito depois da decodificação.

O RFC 7617 define o esquema e traz dois detalhes relevantes aqui. O primeiro caractere de dois-pontos separa o user-id da senha, portanto dois-pontos não são válidos no nome de usuário. Caracteres de controle também são proibidos. Isso significa que um fornecedor legado pode aceitar uma convenção de conta visualmente conveniente que não consegue sobreviver em um header Basic compatível com os padrões. Não invente uma regra de escape esperando que todas as bibliotecas concordem com ela.

O segundo detalhe é o tratamento de caracteres. O RFC 7617 permite que um desafio do servidor anuncie UTF-8, mas esse sinal é apenas consultivo, e muitos sistemas antigos não lidam de forma consistente com identidades não ASCII. Se o nome de uma conta incluir caracteres acentuados, regras de maiúsculas e minúsculas ou Unicode transformado, teste a combinação exata de cliente e servidor antes de colocá-la em produção. Uma incompatibilidade pode causar uma falha de autenticação que alguém tentará "corrigir" despejando a credencial inteira na saída de depuração.

A autenticação Basic também exige HTTPS. A OWASP descreve as credenciais Basic como codificadas, e não criptografadas, e recomenda TLS sempre que Basic for usada. O TLS protege a conexão durante o trânsito. Ele não protege um header depois que uma biblioteca cliente, proxy reverso, agente de tracing, manipulador de erros ou ferramenta de depuração o registra.

IDs de tenant e endpoints se tornam perigosos quando combinados

Um ID de tenant isolado pode ser apenas um número opaco. Um endpoint isolado pode ser uma rota genérica. Juntos, eles podem identificar a função comercial de um cliente e o sistema que a executa.

Suponha que um agente receba esta instrução:

For tenant 48291, call https://ledger.internal.example/v2/reconciliation/import
with username tenant-48291-ledger-import.

Mesmo que outro componente injete a senha, a instrução fornece ao agente um tenant, um host, uma operação e uma identidade de serviço. O agente pode citar essa instrução nas próprias anotações de trabalho. Um wrapper de ferramenta pode registrá-la. Uma transcrição do modelo pode preservá-la. Um desenvolvedor pode colar o erro em um canal de conversa. A senha permaneceu escondida, mas a estrutura da conta não.

A exposição aumenta quando os nomes seguem uma gramática previsível. Se um nome de usuário é tenant-48291-ledger-import, é razoável supor que possam existir tenant-48291-ledger-export, tenant-48291-reporting ou as mesmas funções para outros tenants. A previsibilidade é conveniente para operadores e útil para quem enumera contas. Você não precisa abandonar todas as convenções de nomenclatura, mas deve reconhecer quando elas transformam um nome vazado em uma consulta de diretório.

Os pares de endpoint também carregam sinais próprios. /admin/users, /payroll/export, /claims/submit e /archive/retention revelam tipos diferentes de trabalho, mesmo com um hostname neutro. Um host junto com caminho e tenant costuma revelar informação suficiente para tornar convincente uma mensagem de phishing ou uma tentativa de se passar pelo suporte.

Classifique a tupla, não apenas seus campos:

• identidade de serviço mais ID de tenant
• identidade de serviço mais hostname
• ID de tenant mais caminho do endpoint
• caminho do endpoint mais corpo da resposta ou texto do erro
• horário mais registro de uma ação bem-sucedida

Essa é uma regra mais precisa do que "oculte as senhas". Ela explica aos revisores por que uma linha de log sem nenhum segredo literal ainda pode ser perigosa quando enviada a um sistema amplo de observabilidade.

Agentes copiam contexto onde clientes comuns não copiam

Um cliente de API comum geralmente recebe uma URL, um nome de conta e uma senha por meio de um caminho de configuração restrito. Um agente de IA trata instruções como texto. Ele pode inspecionar um repositório, ler um ticket, executar um comando, interpretar um erro e escrever um resumo. Cada transferência pode preservar identificadores que um cliente tradicional nunca precisaria exibir.

O risco não é que os agentes sejam descuidados de uma forma única. O risco é que os fluxos de trabalho com agentes tornam o contexto portátil por definição. A mesma capacidade que permite ao agente raciocinar sobre uma nota de implantação e uma resposta de API também permite que ele carregue nomes de tenants e padrões de endpoints para entradas de ferramentas, transcrições ou patches gerados.

Uma falha comum se parece com isto:

1. Um desenvolvedor coloca um nome de usuário Basic e um código de tenant em um arquivo .env local porque a senha vem de um cofre de segredos.
2. O agente lê o arquivo para entender uma integração que falhou.
3. A API retorna uma resposta 401 com um erro detalhado que repete o nome de usuário e o tenant.
4. O agente escreve um relatório de solução de problemas contendo o trecho de configuração e o erro.
5. O desenvolvedor cola o relatório em uma issue visível para um grupo maior.

Ninguém pretendia publicar credenciais. Mesmo assim, a issue agora registra um padrão de nomenclatura válido, um tenant, um host, uma rota, uma função de serviço e o intervalo em que a integração esteve ativa. Esse contexto já basta para criar riscos adicionais.

Não resolva isso proibindo os agentes de ver todas as strings que não são segredos. Isso impede trabalho útil e geralmente falha na prática. Em vez disso, decida quais fatos cada ação realmente exige. Um agente que precisa solicitar uma exportação mensal pode precisar de um nome abstrato de ação e de um mês. Ele não precisa do nome de usuário Basic, da senha, da regra de roteamento do tenant ou da URL de destino original.

Isso muda a pergunta de design de "O agente consegue se autenticar?" para "Qual é a menor descrição da ação de que o agente precisa para produzir a requisição desejada?" Essa é a pergunta que mantém a estrutura da conta fora da janela de contexto do agente.

Mantenha o material de identidade fora de prompts e repositórios

Um prompt é um péssimo lugar para armazenar configurações. O mesmo vale para arquivos de código-fonte, exemplos de curl, modelos de issues, aliases do shell e fixtures de teste. Todos eles viajam mais longe do que o autor imagina.

Comece separando três coisas que as equipes costumam misturar:

1. Material de credenciais é o nome de usuário e a senha usados na autenticação.
2. Metadados de roteamento informam para onde uma requisição vai, como um host, uma partição de tenant ou uma família de endpoints.
3. Intenção da ação é a operação comercial, como "baixar o arquivo de conciliação de março".

Uma pessoa ou um agente muitas vezes consegue declarar a intenção da ação sem ver as outras duas categorias. Essa é a fronteira preferível. Se uma API legada exige roteamento por um host ou nome de usuário específico do tenant, mantenha o mapeamento no componente que executa a requisição, e não no prompt que a solicita.

Evite exemplos brutos de .env como este em um repositório:

LEGACY_API_URL=https://tenant-48291.api.legacy.example/v2/payroll/export
LEGACY_API_USER=tenant-48291-payroll-export
LEGACY_API_PASSWORD=replace-me

O placeholder replace-me não torna o exemplo seguro. A URL e o nome de usuário ainda documentam um padrão de integração específico de um cliente. Um exemplo copiado também pode virar configuração de produção depois, geralmente sob pressão de prazo.

Use um contrato local abstrato:

actions:
  export_monthly_payroll:
    account_ref: payroll-export-production
    target_ref: payroll-export-api
    inputs:
      - tenant_alias
      - month

Os rótulos account_ref e target_ref devem ser opacos o suficiente para que um leitor do repositório não consiga inferir o cliente, o hostname ou a função do serviço. O executor resolve esses valores localmente. O agente recebe tenant_alias apenas se a ação realmente exigir isso, e esse alias não deve ser um identificador de tenant de produção quando um mapeamento local puder fazer o trabalho.

Essa abordagem também evita um erro comum de migração: mover a senha para um gerenciador de segredos enquanto deixa o nome de usuário, a URL de destino e o código do cliente fixos no aplicativo. Isso é melhor do que versionar uma senha, mas ainda deixa a estrutura exposta a todo desenvolvedor, log de build e exportação de ferramentas de análise de código.

Use aliases que não transformem um vazamento em uma consulta de diretório

Nomes opacos não são mágicos, mas reduzem a informação fornecida por uma divulgação acidental. O nome da conta deve explicar sua finalidade ao pequeno grupo que a administra, e não anunciar uma relação com um cliente a todos os sistemas que o veem.

Compare estes aliases de serviço:

bad:  acme-east-payroll-export-prod
better: svc-47f2-export-p1

O segundo ainda tem um prefixo de serviço legível e um indicador de ambiente. Isso costuma ser prático. Os detalhes úteis terminam aí. Um registro protegido separado pode mapear svc-47f2-export-p1 para o cliente, responsável, endpoint, permissões e histórico de rotação.

Não trate aliases com aparência aleatória como substitutos da autorização. Um invasor que tenha a senha ainda poderá se autenticar, e um funcionário com acesso ao registro ainda poderá ver o mapeamento. Aliases reduzem a divulgação desnecessária. Privilégio mínimo e revisões de acesso controlam o que a conta pode fazer.

Há casos em que um fornecedor determina o formato do nome de usuário. Algumas APIs antigas exigem um número de cliente, um endereço de e-mail ou um valor composto que inclua uma região. Quando isso acontece, aceite que o campo é sensível e mude o tratamento ao redor dele. Não finja que o valor é público porque você não pode renomeá-lo.

Mantenha os identificadores exigidos pelo fornecedor dentro do limite das credenciais e torne as saídas posteriores pouco informativas. Um executor de requisições pode retornar export accepted com um identificador de tarefa. Ele não precisa repetir o nome de usuário enviado, a URL de destino completa ou o valor de roteamento do tenant para o agente que o chamou.

Os logs precisam de uma trilha de auditoria sem virar um diretório de contas

Os logs de segurança precisam de detalhes suficientes para responder quem iniciou uma ação, o que aconteceu, quando aconteceu e se ela foi bem-sucedida. Eles não precisam preservar cada byte enviado pelo cliente. As orientações de logging da OWASP alertam explicitamente contra o registro de informações sensíveis, como senhas, identificadores de sessão e detalhes desnecessários do sistema, mas também exigem que eventos de autenticação e controle de acesso sejam registrados.

A tensão é real. Se você remover tudo, os operadores não conseguirão investigar um incidente. Se conservar headers brutos e URLs completas para sempre, seus logs se tornarão um diretório de contas pesquisável.

Use um formato de registro que separe a correlação operacional dos metadados sensíveis:

{
  "event": "legacy_api_call",
  "action": "export_monthly_payroll",
  "request_id": "req_01J...",
  "actor_run": "run_01J...",
  "credential_ref": "cred_4c91",
  "target_ref": "target_a77e",
  "result": "denied",
  "http_status": 401,
  "reason": "authentication_failed",
  "occurred_at": "2026-07-22T14:03:21Z"
}

As referências permitem que operadores autorizados correlacionem eventos com um inventário protegido. Elas não colocam o nome de usuário, o ID de tenant, o endpoint original ou o header Authorization em todos os eventos. O acesso ao inventário deve ser mais restrito que o acesso comum aos logs.

Não registre um hash do nome de usuário e considere o problema resolvido. Um hash determinístico de um espaço pequeno e padronizado de nomes de usuário costuma ser fácil de adivinhar, e um hash estável ainda permite acompanhar uma conta entre registros. Se precisar de correlação, use uma referência aleatória de credencial atribuída pelo seu próprio sistema. Troque ou aposente a referência quando trocar a credencial.

Tenha cuidado com diagnósticos de falha. Esta é uma resposta ruim para repassar:

401 for tenant-48291-payroll-export at /v2/payroll/export: user exists but password rejected

Ela confirma uma conta, um tenant, uma rota e o resultado da validação. Um tratamento interno melhor mantém o diagnóstico exato do fornecedor em um registro de suporte restrito, se ele for realmente necessário, enquanto o histórico geral registra authentication_failed. O agente deve receber uma falha curta que o instrua a parar e pedir ajuda, em vez de outra pista para tentar variações.

Redação e minimização resolvem problemas diferentes

A redação remove um valor perigoso conhecido depois que alguém já o tratou. A minimização impede que o valor entre em um lugar ao qual não pertence. Você precisa das duas, e confundi-las produz designs ruins.

Um limpador de headers pode substituir isto:

Authorization: Basic c3ZjLWJpbGxpbmctZXhwb3J0LXByb2Q6cmVkYWN0ZWQ=

por isto:

Authorization: [REDACTED]

Isso é necessário. Mas não resolve o caminho, hostname, parâmetro de tenant na query, corpo detalhado da resposta 401, rótulo da requisição ou atributos de tracing registrados ao lado do header. Um sistema que se orgulha de ocultar senhas enquanto conserva tenant-48291.api.legacy.example/payroll/export reduziu um risco e deixou para trás um mapa útil da conta.

A minimização faz perguntas mais difíceis antes de a requisição ser executada:

• O agente precisa do host de destino real ou apenas de um nome de ação?
• O log de atividade precisa do identificador do tenant ou apenas de uma referência protegida?
• O suporte precisa da resposta bruta do fornecedor no fluxo comum de logs?
• A requisição precisa do tenant na URL quando o executor pode resolvê-lo localmente?
• Uma pessoa que revisa uma aprovação precisa da identidade completa ou de um rótulo amigável, mas não revelador?

É aqui que muitas equipes fazem uma recomendação popular, mas errada: "Registre a requisição inteira uma vez e melhore os filtros depois." Elas dizem isso porque depurar APIs legadas é difícil e capturas completas respondem rapidamente às perguntas. Depois, os dados capturados se tornam evidências permanentes em backups, repositórios analíticos, ambientes de teste e notas de incidentes copiadas. Em vez disso, crie um caminho de diagnóstico restrito e temporário para uma investigação curta. Não transforme a captura bruta ampla no modo normal de operação.

APIs legadas precisam de uma barreira de contenção, não de confiança cega

Talvez você não consiga substituir a autenticação Basic neste trimestre. Um fornecedor pode oferecer apenas um estilo de integração. Um dispositivo de armazenamento pode ter uma API congelada há anos. A resposta prática é a contenção, não uma declaração otimista de que a API legada é aceitável.

Coloque a credencial Basic e o mapeamento de identificadores atrás de um componente que execute a própria requisição HTTP. O agente deve solicitar uma ação nomeada com entradas estruturadas. O componente de requisição seleciona o destino, obtém a credencial, injeta-a no header, verifica o escopo pretendido e retorna um resultado limitado.

Para uma ação de agente, um contrato de requisição útil é:

{
  "action": "export_monthly_payroll",
  "tenant_alias": "tenant_ref_91ab",
  "month": "2026-06"
}

O executor da ação pode validar o mês, resolver tenant_ref_91ab em um mapeamento local protegido e fazer a chamada ao fornecedor. Ele deve rejeitar campos extras como url, authorization, username e headers. Se os chamadores puderem substituir esses campos, poderão encaminhar uma credencial confiável para qualquer host ou transformar uma ação restrita novamente em um cliente HTTP genérico.

Essa restrição também é importante para erros do tipo SSRF e para a exposição de credenciais. Uma URL fornecida pelo usuário não é uma conveniência inofensiva quando o executor mantém credenciais. O destino deve vir de uma definição controlada, e os redirecionamentos precisam do mesmo cuidado. Não siga um redirecionamento para uma nova origem mantendo o header Authorization.

Essa barreira também deve tratar novas tentativas. Um agente mal projetado pode repetir uma requisição 401 com dados alterados ou invocar repetidamente uma operação após um timeout. O executor deve distinguir uma nova tentativa segura de transporte de uma falha de autenticação ou de um resultado de gravação desconhecido. Para um endpoint legado não idempotente, retorne um status que force uma revisão humana, em vez de enviar a mesma requisição novamente só porque o agente pediu com confiança.

O Sallyport segue esse padrão quando um agente compatível com MCP precisa chamar uma API HTTP sem receber a credencial Basic. Seu canal HTTP injeta as credenciais Basic dentro do app, e seus controles por sessão e por chamada permitem que uma pessoa decida quando uma execução de agente pode usar aquela conta. O agente recebe o resultado da ação, não um nome de usuário ou senha em texto simples para reutilizar em outro lugar.

A aprovação precisa mostrar contexto suficiente para detectar a ação errada

Uma caixa de diálogo que diz apenas "Permitir chamada de API?" não ajuda. Uma caixa que imprime o nome de usuário Basic completo, o tenant, a URL inteira e o corpo bruto da requisição compartilha informação demais. O revisor precisa de uma descrição compacta que torne uma ação errada evidente sem expor toda a estrutura da conta.

Mostre o nome da ação, um rótulo protegido do destino, um rótulo de tenant escolhido para o revisor, o tipo de operação e a consequência em alto nível. Por exemplo:

Allow export_monthly_payroll?
Target: Payroll export service
Tenant: Finance tenant 7
Operation: Create June 2026 export
Agent run: signed local coding process

Isso fornece informação suficiente para o revisor notar um mês, função ou destino inesperado. Não revela um hostname do fornecedor, número de tenant ou nome de usuário de serviço no registro da aprovação.

O rótulo exibido precisa de governança. Se "Finance tenant 7" aparecer em uma equipe que tem apenas um cliente financeiro, ele ainda pode identificar esse cliente. Use rótulos adequados ao grupo que os verá. Segurança não se consegue substituindo todos os nomes úteis por um código opaco que os revisores não conseguem entender.

Para contas Basic sensíveis, exija aprovação a cada uso quando a ação puder movimentar dinheiro, exportar registros regulados, alterar acessos ou contatar uma parte externa. A aprovação por sessão é mais prática para uma execução curta com muitas leituras de baixo risco. A escolha deve seguir a autoridade da conta e a consequência da ação, não o fato de a autenticação Basic ser antiga.

Mantenha um registro auditável da decisão de aprovação e da chamada resultante. Um registro à prova de adulteração só é útil se descrever o ator, a ação, o resultado e o estado da aprovação sem se tornar outra cópia do mapa de credenciais. Os diários separados de sessão e atividade do Sallyport seguem essa divisão, com ambas as visões projetadas a partir de seu log de auditoria criptografado e encadeado por hashes.

Torne difícil coletar a estrutura da conta desde o início

A solução não é um enorme documento de políticas dizendo "trate os metadados com cuidado". Faça do caminho mais seguro a rota que desenvolvedores e agentes usam naturalmente.

Faça um inventário de todas as integrações Basic e responda a estas perguntas para cada uma: O que o nome de usuário revela? Ele contém uma pessoa, cliente, ambiente, produto ou função? Qual combinação de host e endpoint torna esse valor mais revelador? Onde esses valores aparecem hoje? Qual chamador realmente precisa vê-los?

Depois, remova as cópias fáceis. Troque trechos brutos de curl por exemplos de ações. Substitua nomes de fixtures específicos de tenants por aliases neutros de teste. Bloqueie headers Authorization e userinfo de URLs nos logs da aplicação. Mantenha diagnósticos completos do fornecedor fora das saídas visíveis ao agente. Rejeite destinos de requisição fornecidos pelo usuário no limite das credenciais. Dê ao suporte uma forma controlada de recuperar detalhes quando um incidente justificar isso.

O RFC 9110 diz que os remetentes não devem gerar referências URI HTTP ou HTTPS com userinfo no formato user:password@host e alerta que as implementações podem expor um identificador de usuário ou senha quando usam esse formato em configurações ou opções de comandos. É um alerta útil para além das URLs: detalhes de identidade colocados em campos de texto convenientes tendem a ser copiados para lugares onde nunca deveriam estar.

A autenticação Basic pode continuar existindo porque um fornecedor não avançou. O seu tratamento não precisa ficar preso a ela. Quando você passa a tratar nomes de usuário, IDs de tenant e pares de endpoint como metadados sensíveis, deixa de entregar ao agente o diretório de contas junto com a tarefa.