# Autenticação HTTP para agentes de IA: padrões seguros de credenciais

Um agente de IA deve poder solicitar uma ação HTTP sem jamais possuir a credencial que torna essa ação possível. Essa regra importa mais do que saber se a requisição usa um bearer token, autenticação Basic ou um cabeçalho de fornecedor. Se um segredo entrar no contexto do agente, ele poderá vazar por um prompt, um registro de ferramenta, um comando de shell gerado, um arquivo do repositório ou um resumo posterior que ninguém pretendia preservar.

Os padrões de autenticação HTTP continuam importantes porque cada um define o que pode ser roubado, reutilizado, encaminhado por engano e auditado. O design correto começa pelo esquema exigido pela API e mantém a credencial dentro de um executor confiável, que envia uma requisição cuidadosamente limitada em nome do agente.

## Agentes transformam credenciais comuns em dados copiados

Um agente autônomo muda o risco de uma credencial de API comum porque lê e grava muitos tipos de texto. Um desenvolvedor pode manter um token em um armazenamento local de credenciais e colá-lo em uma única requisição. Um agente pode inspecionar variáveis de ambiente, gerar saída de depuração, montar um comando curl, criar arquivos de configuração e relatar o trabalho a uma pessoa. Cada uma dessas operações cria outro lugar onde um segredo reutilizável pode parar.

O caminho perigoso costuma parecer inofensivo no início:

1. Um executor de tarefas coloca `PAYMENTS_TOKEN` no ambiente do processo do agente.
2. O agente executa um comando de diagnóstico que imprime o ambiente ou grava um script de shell.
3. O script chega a um repositório, artefato de CI, histórico do terminal ou outra chamada de ferramenta do agente.
4. Alguém encontra o token mais tarde e envia requisições válidas até ele expirar ou um operador revogá-lo.

O token não precisou de um invasor sofisticado. Bastou virar texto em um lugar feito para copiar texto.

Não confunda o controle de acesso ao agente com a confidencialidade das credenciais. Um sandbox pode impedir que o agente abra arquivos fora de um diretório. Isso não ajuda se o segredo já aparece no contexto do modelo, nos argumentos do comando ou no resultado de uma ferramenta. Da mesma forma, um prompt de aprovação que pergunta se o agente pode executar `curl` diz pouco se o agente puder fornecer qualquer host, caminho, corpo e cabeçalho de autorização herdado.

Por isso, a autenticação HTTP para agentes de IA precisa de dois limites separados. O agente precisa ter permissão para propor uma requisição. Um componente confiável precisa manter a credencial e ter autoridade para enviar a chamada. Juntar esses limites entrega ao agente um segredo que pode ser copiado e faz os controles posteriores dependerem de ele lidar perfeitamente com esse segredo. Essa é uma suposição de design sem fundamento.

Um teste útil é simples: pergunte se você poderia colar a transcrição completa do agente em um rastreador de problemas sem revogar a credencial. Se a resposta for não, o segredo atravessou o limite errado.

## Bearer tokens são fáceis de enviar e de reutilizar

Um bearer token concede acesso a quem o apresenta. Portanto, o agente nunca deve receber um, a menos que você aceite que o vazamento de uma transcrição possa se tornar um vazamento de acesso à API. A RFC 6750 define o uso de bearer tokens no cabeçalho `Authorization` da requisição:

```http
GET /v1/projects/alpha/releases HTTP/1.1
Host: api.example.test
Authorization: Bearer eyJhbGciOi...
Accept: application/json
```

O servidor não precisa provar que quem enviou a chamada é o agente esperado, o usuário original ou a máquina original. Ele verifica se o token apresentado é válido e autorizado. Essa propriedade mantém os clientes HTTP simples, mas também faz com que tokens copiados sejam úteis para qualquer pessoa que os possua.

A RFC 6750 permite enviar bearer tokens no corpo de um formulário sob condições restritas e descreve o uso de URI em consultas para casos legados. Não os coloque em strings de consulta. URLs chegam ao histórico do navegador, registros de proxy, sistemas de análise, cabeçalhos de referência, chamados de suporte e logs de aplicação com mais facilidade do que muitas equipes imaginam. A própria norma alerta que o transporte por URI tem alta probabilidade de divulgação. Não há motivo para transformar o segredo de um agente em parte de uma URL.

Bearer tokens funcionam bem com agentes apenas quando o design das credenciais limita os danos. Prefira tokens com uma audiência de API definida, permissões restritas, expiração curta e uma identidade própria para o executor da ação. Um token de API que pode administrar todos os projetos, ler todos os registros de clientes e nunca expira é uma credencial mestre de produção com um nome mais simpático.

O argumento habitual para entregar um bearer token ao agente é a velocidade: uma variável de ambiente, um cliente HTTP e nenhum componente extra. Isso é popular porque funciona em uma demonstração. Falha quando o agente precisa de depuração, delegação, tarefas longas ou acesso a mais de um serviço. Um token copiado para o contexto fica mais difícil de revogar seletivamente porque você já não sabe por onde ele passou.

Existe outra armadilha: um token com nome restritivo ainda pode ter autoridade efetiva ampla. Leia a documentação do provedor para entender o modelo real de escopos. Alguns serviços usam escopos específicos de endpoint. Outros concedem direitos no nível da organização, projeto, repositório ou conta. Alguns tokens de API herdam silenciosamente todos os privilégios do usuário que os criou. O rótulo do token não prova seus limites.

Um mediador pode manter o bearer token e montar o cabeçalho somente depois de validar o destino solicitado. O agente deve enviar a intenção e os dados da requisição, como «criar uma release no projeto alpha com este corpo», em vez do cabeçalho `Authorization` literal. O executor acrescenta o segredo após a validação e o remove antes de devolver qualquer registro ao agente.

## A autenticação Basic precisa de uma identidade de serviço separada

A autenticação Basic pode ser aceitável para uma conta de serviço restrita usando TLS, mas é uma forma ruim de entregar ao agente o nome de usuário e a senha de uma pessoa. A RFC 7617 especifica o formato transmitido como uma codificação Base64 de `user-id:password`, colocada no cabeçalho Authorization:

```http
Authorization: Basic YWdlbnQtcmVsZWFzZXI6czNjcjN0LXZhbHVl
```

Qualquer pessoa que possa ler esse valor pode decodificá-lo. Base64 muda a representação, mas não protege o valor. TLS protege a conexão entre cliente e servidor, mas não protege a credencial depois que um agente, processo local, log de depuração ou proxy copia o cabeçalho.

Muitos provedores de API usam autenticação Basic com um token de API como senha e um nome de usuário fixo ou ignorado. Isso cria exposição semelhante à reutilização de bearer tokens, além de alguns riscos práticos. Um cliente ou logger pode registrar o nome de usuário decodificado, o cabeçalho bruto ou ambos. Um desenvolvedor pode reutilizar uma senha de conta real porque o protocolo chama o segundo campo de senha. Essa é exatamente a credencial que não deve ser delegada a um processo autônomo.

Quando a autenticação Basic for inevitável, crie uma conta exclusiva para o executor. Dê a ela apenas as permissões necessárias para a família de requisições. Não use uma conta pessoal, administrativa ou compartilhada entre automações sem relação. Uma identidade de serviço permite revogar e investigar o acesso sem bloquear uma pessoa ou interromper todos os trabalhos de uma vez.

Trate a codificação de caracteres de forma deliberada. A RFC 7617 descreve um problema de compatibilidade relacionado ao conjunto de caracteres do nome de usuário e da senha e permite que os servidores anunciem UTF-8. Se o provedor aceitar apenas valores ASCII comuns, mantenha as credenciais de máquina nesse conjunto. Não invente uma etapa de codificação própria em um prompt do agente, pois isso cria outro lugar inconsistente onde um segredo pode ser transformado e registrado.

O executor da requisição deve montar sozinho o cabeçalho Basic a partir de campos protegidos. O agente pode escolher uma operação aprovada e fornecer parâmetros que não sejam secretos. Ele não deve construir o valor Base64 e nunca deve ver uma credencial decodificada em uma mensagem de erro. Um erro seguro informa que a autenticação falhou para a referência de credencial selecionada. Ele não repete o cabeçalho nem informa ao agente qual parte da senha coincidiu.

## Cabeçalhos personalizados exigem semântica exata do fornecedor

Um cabeçalho de autenticação personalizado só é seguro na medida em que são seguros as regras documentadas de verificação da API e o tratamento de seu valor. Exemplos comuns incluem `X-API-Key`, `Api-Key` e cabeçalhos específicos de um provedor. Alguns provedores esperam uma chave de API estática. Outros esperam uma requisição assinada com timestamp, nonce, caminho canônico e resumo do corpo. Tratar todos os cabeçalhos personalizados como equivalentes é uma forma de quebrar a autenticação e, pior, ampliar por engano os lugares para onde uma credencial é enviada.

Primeiro, siga exatamente a especificação do provedor. Os nomes dos cabeçalhos não diferenciam maiúsculas de minúsculas no HTTP, mas os valores e as entradas de uma assinatura podem diferenciar. Um esquema de assinatura pode exigir uma ordem de canonização específica, os bytes exatos do corpo e uma janela de tempo limitada. Se o executor analisar JSON e o serializar novamente antes de assinar, poderá produzir um JSON visualmente válido com uma sequência de bytes diferente. O provedor rejeitará a requisição, e as pessoas muitas vezes respondem desativando as verificações de assinatura ou adicionando uma lógica ampla de repetição. Corrija o tratamento dos bytes.

Segundo, diferencie um cabeçalho usado para autenticação de um cabeçalho que identifica um cliente. `User-Agent`, IDs de requisição e identificadores da aplicação podem ajudar um provedor a observar o tráfego, mas normalmente não provam autoridade. Por outro lado, um cabeçalho `X-API-Key` pode ser tão reutilizável quanto `Authorization: Bearer`. Não avalie sua sensibilidade pelo fato de o nome conter ou não a palavra authorization.

Terceiro, impeça que o agente injete cabeçalhos. O agente não deve receber um mapa livre de cabeçalhos de saída se um executor protegido também injeta credenciais. Um mapa livre permite adicionar um segundo cabeçalho `Authorization`, substituir um content type esperado, anexar uma identidade não aprovada ou influenciar um proxy posterior de maneiras que o revisor não viu.

Use um contrato de requisição com campos nomeados e tipados. Por exemplo:

```json
{
  "credential_ref": "release-service",
  "method": "POST",
  "url": "https://api.example.test/v1/projects/alpha/releases",
  "headers": {
    "accept": "application/json"
  },
  "body": {
    "version": "2025.06.0",
    "notes": "Fix parser crash on empty input"
  }
}
```

O executor, não o agente, mapeia `credential_ref` para o cabeçalho personalizado do fornecedor ou para o procedimento de assinatura. Ele deve rejeitar tentativas de fornecer `authorization`, `cookie`, o cabeçalho de credencial do provedor, `host` ou uma forma duplicada desses nomes. Também deve controlar `Content-Length`, pois o cliente HTTP precisa calculá-lo a partir dos bytes finais.

A resposta mostrada ao agente precisa da mesma disciplina. Uma resposta HTTP pode incluir `Set-Cookie`, diagnósticos ou detalhes repetidos da requisição. Retorne o status, os cabeçalhos seguros selecionados e o corpo necessário para a tarefa. Mantenha cabeçalhos e rastreamentos brutos em um armazenamento de auditoria protegido quando forem necessários aos operadores.

## Escolha o esquema exigido pelo provedor e limite o impacto

Raramente você escolhe o esquema de autenticação de uma API de terceiros. O provedor já o escolheu. O que você pode escolher é se a credencial será ampla ou restrita, onde ficará, quais requisições poderão usá-la e o que acontecerá quando o agente se comportar de modo estranho.

Use esta comparação ao projetar o limite:

| Padrão | O que o cliente envia | Principal exposição se for copiado | Tratamento adequado para o agente |
|---|---|---|---|
| Bearer token | Um token em `Authorization` | Reutilização direta por quem o receber | Manter no executor e limitar escopos e duração |
| Autenticação Basic | Base64 de nome de usuário e senha ou token | Decodificação seguida de reutilização direta | Usar uma identidade de serviço exclusiva no executor |
| Cabeçalho personalizado estático | Um cabeçalho secreto definido pelo provedor | Normalmente, reutilização direta | Injetar apenas para hosts e caminhos aprovados |
| Cabeçalho personalizado assinado | Assinatura, timestamp e dados da requisição | A reutilização pode falhar, mas o material de assinatura continua sensível | Manter o segredo e a canonização no executor |

Requisições assinadas exigem uma observação importante. Timestamp e nonce podem reduzir a reutilização direta na fronteira da API, mas não tornam o segredo de assinatura seguro no contexto do agente. Um agente que tenha acesso ao segredo pode assinar uma nova requisição maliciosa. Se a implementação aceitar método, host, caminho e corpo arbitrários fornecidos pelo agente, ela assinará fielmente ações que você não pretendia autorizar.

O escopo deve corresponder à ação, não a um possível uso futuro. Um agente que publica releases pode precisar de permissão para criar uma release em um projeto. Ele não precisa excluir projetos, alterar cobranças, ler todos os artefatos ou convidar usuários. Se o provedor não puder emitir uma credencial adequadamente limitada, coloque um serviço mais restrito, controlado por você, na frente da API ou mantenha aprovação humana para chamadas perigosas.

Não tente compensar escopos ruins com uma longa lista de permissões escrita em linguagem natural. «Use o token apenas para releases» é uma orientação, não um ponto de controle. Aplique a restrição onde a requisição é montada: origem esperada, método permitido, padrão de caminho, conjunto de cabeçalhos, esquema do corpo e tamanho máximo da resposta. Essas restrições tornam a credencial menos útil fora da função pretendida.

## A mediação mantém os segredos fora do contexto do agente

As chamadas HTTP mediadas funcionam quando o detentor do segredo executa a requisição, em vez de devolver a credencial para que o agente a execute. A diferença pode parecer pequena porque os dois designs podem apresentar ao agente uma ferramenta chamada `http_request`. O fluxo dos dados mostra qual design foi realmente construído.

No design inseguro, a ferramenta obtém um token e o entrega ao agente, talvez como variável de ambiente, expansão de placeholder ou credencial «temporária». A próxima ação do agente envia a requisição. O token já atravessou um sistema criado para interpretar, transformar e repetir texto.

No design mediado, o agente envia uma requisição estruturada a um executor. O executor compara a requisição com o formato permitido, obtém a credencial selecionada no armazenamento protegido, injeta o material correto de autenticação, envia a chamada, registra a ação e devolve um resultado limitado. O agente nunca recebe o valor secreto, uma forma codificada dele ou um comando de shell que o contenha.

Essa diferença também muda a resposta a incidentes. Se você suspeitar que uma sessão do agente saiu do controle, poderá interromper sua capacidade de solicitar ações sem rotacionar imediatamente todas as credenciais. Se a própria credencial puder ter escapado, você ainda deverá rotacioná-la. Revogar uma sessão e rotacionar uma credencial resolvem problemas diferentes, e as equipes perdem tempo quando tratam os dois como o mesmo botão.

Um executor prático deve rejeitar por padrão várias formas de requisição:

- URLs absolutas que apontem para uma origem não aprovada, incluindo subdomínios parecidos.
- Requisições com cabeçalhos `Authorization`, `Cookie`, de proxy ou específicos de credenciais fornecidos pelo usuário.
- Redirecionamentos que possam levar uma requisição autenticada a outra origem.
- Métodos fora do uso previsto para a credencial, especialmente métodos destrutivos.
- Corpos que excedam o tamanho esperado ou não correspondam ao formato do endpoint.

O Sallyport aplica esse modelo de custódia no macOS: seu cofre criptografado mantém credenciais de APIs e SSH, enquanto um agente MCP pede ao aplicativo que faça chamadas HTTP em vez de receber os valores das credenciais.

Não confunda mediação com um mecanismo geral de políticas. Ela não consegue inferir se «excluir recursos de teste antigos» é correto em determinada conta de produção. Ela pode garantir que uma requisição permaneça dentro de um limite técnico definido e que a credencial fique fora do contexto do agente. A revisão humana, as contas restritas e as proteções específicas da aplicação continuam decidindo se a ação merece aprovação.

## O limite da requisição deve incluir redirecionamentos, DNS e respostas

Aprovar apenas `https://api.example.test` é amplo demais, porque uma requisição com credenciais contém mais do que um hostname. O executor precisa controlar cada lugar em que o agente pode alterar o destino efetivo ou o significado da requisição.

Comece por uma origem exata: esquema, hostname e porta. Exija HTTPS para credenciais de APIs comuns na internet. A RFC 9110 define as regras de destino e autoridade da requisição HTTP, mas o código da aplicação ainda precisa aplicar suas próprias regras de destino. Não aprove hosts apenas pelo sufixo. Uma verificação como «o hostname termina com `example.test`» pode aceitar `notexample.test`; uma busca por substring é ainda pior. Compare hostnames analisados com uma lista exata de permissões ou com uma regra de subdomínio projetada de propósito.

Depois, restrinja métodos e caminhos. Se o agente deve criar releases, permita a família exata de caminhos `POST` necessária. Não acrescente `DELETE` porque talvez seja útil durante uma limpeza. Não permita caminhos versionados arbitrários sem decidir se uma versão futura da API terá comportamento diferente. A normalização do caminho também importa. Analise a URL antes da comparação e rejeite codificações inesperadas, segmentos de ponto ou separadores duplicados se o código de correspondência não os tratar de modo previsível.

O comportamento diante de redirecionamentos precisa ser definido explicitamente. As bibliotecas HTTP diferem, e uma atualização pode mudar os padrões. Para chamadas com credenciais, o padrão mais seguro é rejeitar redirecionamentos e informar o local ao agente. Se um provedor realmente exigir um redirecionamento, permita apenas o destino específico esperado e reconstrua a requisição sob as mesmas restrições. Nunca presuma que um cliente removerá credenciais de forma consistente o suficiente para tornar inofensivo um redirecionamento aberto.

O DNS cria uma segunda verificação de destino. Um hostname confiável pode resolver para endereços que mudam, e sistemas internos podem ter nomes que apontam para redes sensíveis. Se o executor rodar em um laptop de desenvolvedor, HTTP de saída arbitrário poderá virar uma rota para serviços locais de administração ou endpoints de metadados de nuvem. Restrinja as origens aprovadas antes da conexão, não aceite configurações de proxy controladas pelo agente e não permita que ele escolha uma interface de rede ou resolvedor.

Por fim, limite e filtre a resposta. Um agente não precisa de um download de vários megabytes para saber que a criação de uma release foi concluída. Corpos grandes desperdiçam contexto e podem levar instruções copiadas de um serviço não confiável ao raciocínio do agente. Quando possível, retorne apenas os campos necessários para a próxima ação. Marque o texto remoto como dados no contrato da ferramenta e nunca permita que o conteúdo da resposta altere as regras de autorização do executor.

## A aprovação deve identificar o processo chamador e a ação concreta

Um clique de aprovação humana só tem valor quando oferece informações suficientes para uma decisão. «Permitir acesso do agente à API» é uma permissão ampla disfarçada de prompt. Isso incentiva a fadiga de aprovação porque a pessoa não consegue saber qual processo local solicitou o acesso, qual credencial pretende usar ou o que enviará.

Identifique o processo chamador de uma forma que ajude o operador a reconhecê-lo. No macOS, a autoridade de assinatura de código costuma ser mais útil do que um nome de processo mutável. Um processo chamado `agent` pode ser uma ferramenta legítima de desenvolvimento ou um binário diferente que escolheu o mesmo nome. A linhagem do processo, o caminho do executável e as informações de assinatura oferecem evidências melhores, embora nenhuma substitua uma requisição de ação limitada.

A aprovação de sessão e a aprovação de requisição resolvem compromissos diferentes. A aprovação de sessão reduz interrupções repetidas durante uma execução conhecida do agente. Ela funciona para operações de baixo risco e repetitivas, quando a credencial e o limite da requisição permanecem restritos. A aprovação de requisição é adequada para operações irreversíveis ou sensíveis, como publicar externamente, alterar configurações de acesso ou gravar dados que dispararão outro sistema.

Evite um design que peça a uma pessoa para revisar um dump HTTP bruto e extenso em cada chamada. Depois da terceira interrupção, as pessoas aprovarão sem ler. Mostre um resumo conciso da ação: identidade do serviço, método, destino, caminho, campos relevantes do corpo e qualquer efeito colateral documentado pela API. Preserve os detalhes brutos da requisição no registro de auditoria para investigação posterior.

Você também deve diferenciar a permissão para iniciar uma sessão da permissão para mantê-la ativa. Se um processo do agente sair, um processo substituto não deve herdar a aprovação apenas por ter o mesmo nome. Se um usuário revogar uma sessão, o executor precisa parar de aceitar chamadas dela imediatamente. Um rótulo na interface que diga «revogada» enquanto um cliente já autorizado continua enviando requisições é pior do que não ter o recurso de revogação, porque cria uma falsa sensação de segurança.

## Os registros de auditoria devem explicar o que aconteceu depois que o agente saiu

Um registro de auditoria útil permite responder quem solicitou a chamada, qual referência de credencial o executor usou, para onde a requisição foi, o que o executor permitiu e o que o serviço remoto devolveu. Você não precisa registrar o segredo bruto para responder a essas perguntas. Na verdade, fazer isso criaria um segundo armazenamento de segredos disfarçado de observabilidade.

Para cada chamada, mantenha a identidade da sessão ou do processo, o timestamp, a referência de credencial selecionada, o método HTTP, a origem aprovada, o caminho, uma representação protegida dos dados relevantes da requisição, o status da resposta e a decisão que permitiu ou negou a operação. Registre o destino final efetivo depois de qualquer redirecionamento permitido. Registre também as falhas. Tentativas negadas repetidas contra um caminho incomum costumam revelar uma instrução quebrada do agente ou uma tentativa de escapar do limite.

A evidência de adulteração muda o quanto você pode confiar no registro. Um log encadeado por hashes vincula cada entrada às anteriores, tornando detectáveis alterações ou exclusões posteriores durante a verificação. Isso não prova que o executor tomou uma boa decisão de autorização nem torna confiável um host comprometido. Torna mais difícil editar o histórico silenciosamente, que é exatamente a propriedade necessária em uma investigação.

Mantenha o registro de auditoria separado do contexto de trabalho comum do agente. O agente pode receber um resumo como `201 Created, release id r-4821`. Um operador pode precisar de um registro mais completo, com o caminho e os metadados da decisão. Nenhum dos dois deve receber o cabeçalho de autorização bruto apenas porque existe um sistema de logs.

Com o Sallyport, os diários de sessões e atividades são gerados a partir de um registro de auditoria criptografado e encadeado por hashes, e `sp audit verify` pode verificar essa cadeia offline sem desbloquear o cofre. Esse é um design adequado para revisão porque a verificação não exige expor as credenciais que autorizaram as chamadas.

## Teste os caminhos de falha antes de conceder acesso à produção

Um limite de credenciais que só funciona no caminho esperado ainda não merece acesso à produção. Crie uma pequena API de teste ou use uma conta que não seja de produção e faça o executor provar que recusa as situações que poderiam vazar ou permitir o uso indevido das credenciais.

Use uma sequência de teste como esta:

1. Solicite um endpoint `GET` aprovado e confirme que o agente recebe o corpo esperado, mas nenhum cabeçalho que contenha credenciais.
2. Forneça um cabeçalho `Authorization` pelo agente e confirme que o executor o rejeita, em vez de mesclar ou substituir cabeçalhos silenciosamente.
3. Altere a URL para um host não aprovado e para uma correspondência enganosa, depois confirme que ambas falham antes de qualquer requisição de rede.
4. Retorne uma resposta `302` entre origens pela API de teste e confirme que o executor para, em vez de encaminhar a autenticação.
5. Revogue a sessão do agente durante uma execução e confirme que as chamadas seguintes falham, enquanto a verificação de auditoria continua funcionando.

Inspecione ambientes de processos, diretórios temporários, histórico do shell, arquivos gerados, relatórios de falha e logs de teste depois da execução. Procure uma string de credencial de teste conhecida. Esse exercício revela uma quantidade surpreendente de vazamentos em scripts de integração e modos de depuração que os testes no nível da requisição não detectam.

Teste também os erros do provedor. Uma API pode devolver um corpo que repete conteúdo de cabeçalho inválido, um identificador de rastreamento ou uma instrução para tentar outro endpoint. Confirme que o filtro de resultados não devolve ao agente material parecido com uma credencial e que a lógica de repetição não transforma uma requisição negada em uma enxurrada de tentativas. Limite as repetições aos erros para os quais a documentação da API recomenda uma nova tentativa e mantenha o método e o destino inalterados.

A primeira credencial de produção deve ser restrita o suficiente para que uma falha no teste seja inconveniente, não catastrófica. Se sua equipe não consegue explicar exatamente quais formatos de requisição são autorizados e como revogar uma execução ativa do agente, a credencial ainda é ampla demais para uso autônomo.