Transações de Agentes de IA Confiáveis, Parte 5: Prova de Ponta a Ponta
Construindo e provando o caminho completo da solicitação
Os artigos anteriores abordaram o modelo de identidade, troca de token PingFederate, identidade de carga de trabalho SPIRE e política PingAuthorize. Esta parte final conecta-os em um caminho de aplicativo testável.
O fluxo do aplicativo
O ambiente de trabalho do navegador faz o login do usuário através do PingFederate com o Código de Autorização OAuth 2.0 e PKCE. O aplicativo nunca coleta a senha do PingFederate do usuário.
Após o login:
- o agente de demonstração recebe o token de acesso do usuário
- o agente obtém um JWT-SVID do SPIRE
- o PingFederate, atuando como o TTS, troca a evidência do sujeito e do ator por um Txn-Token de curta duração
- o agente envia esse token no cabeçalho
Txn-Tokenao chamar o gateway MCP via mTLS SPIFFE - o gateway valida o token de transação e o chamador imediato
- OPA ou PingAuthorize avaliam o alvo verificado e a solicitação da ferramenta
- o gateway encaminha o token de transação inalterado para o servidor MCP via mTLS
- o servidor MCP chama a API protegida através de outro salto mTLS autenticado
O token de acesso original do usuário não viaja além da troca. O Txn-Token não se torna um token de sessão do navegador, não usa o cabeçalho Authorization para propagação interna e não é reescrito por intermediários.
Uma interface que mostra evidências sem expor credenciais
O ambiente de trabalho usa dois terços da tela para interação com o serviço e um terço para um histórico de auditoria selecionável. Os eventos correlacionam o mesmo ID de transação entre o agente, gateway, servidor MCP, API e decisão de autorização.
Selecionar um evento pode mostrar metadados de solicitação e resposta seguros, além de reivindicações de token decodificadas e permitidas. Não deve expor tokens de acesso brutos, JWT-SVIDs, JWTs de transação, cabeçalhos de autorização, cookies, códigos de autorização, segredos de cliente, tokens de atualização, chaves privadas ou argumentos sensíveis da ferramenta.
As reivindicações decodificadas são evidências para um operador humano, não uma nova entrada de autorização. Os serviços autorizam apenas após validação criptográfica.
Inicialização de produto de propriedade do repositório
Ambos os produtos Ping usam imagens com digestão fixada e sobreposições de perfil de propriedade do repositório somente leitura.
A inicialização do PingFederate constrói e testa o plugin do processador de token personalizado. Sua configuração Terraform permanece um passo explícito separado.
O PingAuthorize começa com um pacote de implantação de propriedade do repositório selecionado durante a primeira configuração. O pacote é montado como somente leitura, e o contêiner se junta apenas à rede de ponte de aplicativo local esperada.
Segredos, licenças, certificados gerados, chaves privadas, estado do Terraform e saída de descoberta permanecem fora do Git.
Testando a declaração de segurança
A principal declaração de autorização é:
contexto de transação verificado
E chamador imediato verificado
E política alvo
A suíte de ponta a ponta, portanto, precisa de mais do que um caso de sucesso. Ela prova a rejeição para:
- identidade de agente lógico forjada
- carga de trabalho SPIFFE errada
- token de transação expirado
- público errado
- alvo MCP não aprovado
- token de transação roubado apresentado pelo chamador mTLS errado
- acesso direto de agente para API quando apenas o servidor MCP é permitido
- decisões de autorização malformadas ou contraditórias
Ela também prova que um ID de transação aparece em todos os saltos esperados e que os logs capturados não contêm material de token bruto.
O teste de inicialização limpa do PingFederate vai além, recriando o produto em um volume isolado e estado do Terraform, aplicando TLS gerenciado, completando uma troca ao vivo, rejeitando um token de ator adulterado e limpando apenas seus recursos nomeados aleatoriamente.
A lição mais ampla
A segurança do agente não é resolvida apenas adicionando uma reivindicação agent_id ou passando um token de usuário mais adiante. A implementação precisa de evidências distintas para o usuário, agente lógico, carga de trabalho, transação e chamador imediato.
O PingFederate fornece a fronteira de delegação controlada. O SPIRE prova a identidade em tempo de execução. O PingAuthorize avalia o contexto da ação verificada. O gateway preserva a fronteira entre verificação de identidade, roteamento e aplicação de políticas.
Juntos, eles tornam uma ação do agente explicável e testável: quem a autorizou, qual agente foi aprovado, qual carga de trabalho a executou, por que a transação existe, qual serviço fez cada chamada e qual política permitiu ou negou a operação.
Anterior: Tomando decisões de política com PingAuthorize
Voltar ao índice da série.
Repositório GitHub: https://github.com/darkedges/pf-tts
O artigo aborda a integração de protocolos de segurança em transações de agentes de IA, essencial para empresas brasileiras que buscam garantir a proteção de dados e a conformidade em suas aplicações. A implementação de práticas seguras pode aumentar a confiança do usuário e a eficiência operacional.
