Part 3 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
Next: Building and proving the complete request path
GitHub Repository: https://github.com/darkedges/pf-tts