Trusted AI Agent Transactions, Part 4: PingAuthorize Policy Decisions

A developer integrated PingAuthorize as a remote policy decision point at the MCP gateway for AI agent transactions, enforcing strict authorization checks beyond identity verification. The gateway constructs typed policy requests from verified values, requiring an exact conjunction of logical agent, workload, caller, purpose, scope, target, and tool for a permit decision. The implementation includes a replaceable policy engine with an in-process OPA adapter and a PingAuthorize JSON PDP API, with failure coverage for malformed, oversized, or unavailable responses.

Part 3 //03-spire-workload-identity.md established the transaction context and immediate caller identity. Authorization still needs to answer a separate question: may this verified combination invoke this target and tool for this purpose? PingAuthorize is integrated as a remote policy decision point at the MCP gateway. It does not verify the transaction JWT or the mTLS connection. Those checks happen before policy evaluation. The gateway constructs a typed policy request from values it has already verified: Browser fields and MCP request fields are not trusted as identity evidence. The target and tool come from the gateway's validated route, not an arbitrary policy document supplied by the caller. PERMIT is not enough by itself The adapter calls a fixed HTTPS /governance-engine endpoint with explicit connection, request, and decision timeouts. It also bounds the response size and requires an exact JSON schema. An allow result requires all of the following: policy status is OKAY AND decision is PERMIT AND authorised is true AND no unfulfilled obligatory statement exists Missing, contradictory, malformed, oversized, timed-out, cancelled, or unavailable responses deny. Unknown JSON fields deny. A PERMIT paired with authorised: false denies. Obligations deny until a named handler is implemented and tested. TLS verification cannot be disabled, and the PingAuthorize hostname must match its runtime certificate. The policy package is mounted read-only and cannot be loaded from an arbitrary network location. The repository-owned deployment package permits only an exact conjunction over the trusted values: logical agent AND original workload AND immediate caller AND purpose AND scope AND target AND tool This matters for AI agent integrations because a broad statement such as "this agent may use MCP" is usually too weak. The useful decision is closer to "this approved agent workload, acting for this verified user transaction and purpose, may invoke this tool through this caller path." The Go gateway has a small authorization interface. An in-process OPA adapter is the default local option, while PingAuthorize implements the same typed contract through its JSON PDP API. That makes the policy engine replaceable without moving identity validation into the policy layer. It also allows the same allow and deny matrix to be tested against both implementations. Failure coverage includes: The local live test has also shown an exact tuple returning PERMIT and a forged logical agent returning NOT APPLICABLE over certificate-validated HTTPS. Previous: Binding a logical agent to a real workload with SPIRE //03-spire-workload-identity.md Next: Building and proving the complete request path //05-end-to-end-implementation.md GitHub Repository: https://github.com/darkedges/pf-tts https://github.com/darkedges/pf-tts