# Trusted AI Agent Transactions, Part 5: End-to-End Proof > Source: > Published: 2026-08-23 23:03:55+00:00 The previous articles covered the identity model, [PingFederate token exchange](//02-pingfederate-token-exchange.md), [SPIRE workload identity](//03-spire-workload-identity.md), and [PingAuthorize policy](//04-pingauthorize-policy.md). This final part connects them into one testable application path. The browser workbench signs the user in through PingFederate with OAuth 2.0 Authorization Code and PKCE. The application never collects the user's PingFederate password. After sign-in: `Txn-Token` header while calling the MCP gateway over SPIFFE mTLSThe original user access token does not travel beyond the exchange. The Txn-Token does not become a browser session token, does not use the `Authorization` header for internal propagation, and is not rewritten by intermediaries. The workbench uses two-thirds of the screen for service interaction and one-third for a selectable audit trail. Events correlate the same transaction ID across the agent, gateway, MCP server, API, and authorization decision. Selecting an event can show safe request and response metadata plus decoded, allowlisted token claims. It must not expose raw access tokens, JWT-SVIDs, transaction JWTs, authorization headers, cookies, authorization codes, client secrets, refresh tokens, private keys, or sensitive tool arguments. Decoded claims are evidence for a human operator, not a new authorization input. Services authorize only after cryptographic validation. Both Ping products use digest-pinned images and read-only repository-owned profile overlays. PingFederate startup builds and tests the custom token processor plugin. Its Terraform configuration remains a separate explicit step. PingAuthorize starts with a repository-owned deployment package selected during first setup. The package is mounted read-only, and the container joins only the expected local application bridge network. Secrets, licenses, generated certificates, private keys, Terraform state, and discovery output remain outside Git. The main authorization statement is: ``` verified transaction context AND verified immediate caller AND target policy ``` The end-to-end suite therefore needs more than a success case. It proves rejection for: It also proves that one transaction ID appears across all expected hops and that captured logs contain no raw token material. The PingFederate clean-bootstrap test goes further by recreating the product on an isolated volume and Terraform state, applying managed TLS, completing a live exchange, rejecting a tampered actor token, and cleaning only its randomly named resources. Agent security is not solved by adding an `agent_id` claim or passing a user token farther downstream. The implementation needs distinct evidence for the user, logical agent, workload, transaction, and immediate caller. PingFederate provides the controlled delegation boundary. SPIRE proves runtime identity. PingAuthorize evaluates the verified action context. The gateway preserves the boundary between identity verification, routing, and policy enforcement. Together, they make an agent action explainable and testable: who authorized it, which agent was approved, which workload ran it, why the transaction exists, which service made each call, and which policy allowed or denied the operation. Previous: [Making policy decisions with PingAuthorize](//04-pingauthorize-policy.md) Return to the [series index](//README.md). GitHub Repository: [https://github.com/darkedges/pf-tts](https://github.com/darkedges/pf-tts)