# Trusted AI Agent Transactions, Part 4: PingAuthorize Policy Decisions > Source: > Published: 2026-08-23 23:03:22+00:00 [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)