Making policy decisions with PingAuthorize
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.
Only verified input crosses the policy boundary
The gateway constructs a typed policy request from values it has already verified:
- user identity
- logical agent identity
- agent instance identity
- original workload SPIFFE ID
- immediate caller SPIFFE ID
- transaction ID and purpose
- scopes
- MCP target
- tool name
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.
A remote 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 policy tuple
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."
OPA and PingAuthorize can share a contract
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.
What the tests prove
Failure coverage includes:
- forged logical agent
- wrong workload or immediate caller
- missing or ambiguous scope
- malformed and oversized decisions
- policy errors and unavailable service
- unsafe endpoint or disabled TLS validation
- unfulfilled obligations
- cancellation and timeout
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
