Where should deterministic authorization live before an AI agent executes a transaction?

I would treat the transactional backend as the definitive policy enforcement point, with Agent Gateway and the MCP layer providing earlier, defense-in-depth enforcement.

The model should only produce a proposed operation. A deterministic PDP can evaluate that proposal and issue a short-lived, audience-bound, single-use authorization artifact, but the backend must independently verify it against the exact operation, canonicalized parameter hash, resource identity/version, tenant, user identity, agent identity, purpose, policy version, and current policy epoch.

One important distinction is that a self-contained signed artifact does not by itself satisfy the requirement that policy changes invalidate stale authorizations. That requires either online introspection, a backend-validated policy/revocation epoch, or a very short-lived grant backed by a one-time authorization registry.

For replay protection, I would bind the grant to a unique jti or nonce and consume it atomically with the transaction. The artifact should also include a narrow audience identifying the specific backend capability, not merely the agent or MCP server.

My preferred enforcement sequence would therefore be:

Agent Gateway validates identity and constrains the call
→ MCP proxy normalizes the capability request
→ deterministic PDP authorizes the exact canonical request
→ transactional backend independently validates and atomically consumes the grant
→ evidence service records the Decision ID and signed result receipt

For the evidence layer, the receipt can contain hashes and identifiers rather than prompts or model output: Decision ID, identity references, canonical action hash, policy version, authorization result, execution result, and timestamps. That preserves independent verification without retaining regulated conversational content.

So I would describe Agent Gateway as an important policy enforcement layer, but not as the sole or definitive authorization boundary for consequential transactions. The system that owns the protected state must retain final authority over whether that state changes.

Hi Alex,

The architecture you're describing is very close to a question I'm currently testing: what actually guarantees that the operation which reaches the transactional backend is still the operation that was authorized?

You mentioned you're adversarially testing the bounded financial workflow. Have you tested cases where authorization succeeds for action A, but immediately before execution something material changes — for example the canonical parameters, resource/version, agent identity, or policy epoch?

If so, I'm particularly interested in what actually happens at the final enforcement point and whether the backend rejects the altered action.

I'm researching the execution-boundary problem from the implementation side, so actual test results are much more useful to me than the intended architecture.

Brodin

Hey Brodin — yes, that’s one of the cases we’re focusing on.

At the authorization layer, we’re already testing tampering and substitution. The decision is tied to a canonical representation of the requested operation, so changing something material after authorization should cause verification to fail.

The more important part, though, is the one you pointed out: that doesn’t prove the execution boundary is safe until the transactional system itself rejects the altered operation.

That’s the end-to-end test we’re working through now. Authorize an operation, change something meaningful before execution, send it downstream, and verify that the backend refuses it and that no protected state changes.

We’re looking at changes such as transaction parameters, resource or version, user or agent identity, policy version, reuse of an authorization that has already been consumed, and substitution of the target capability.

I don’t want to claim that part is fully closed until we have the end-to-end results. We have evidence at the deterministic authorization layer, but the stronger guarantee is what happens at the last enforcement point.

My current view is that Agent Gateway and the MCP layer are useful places to reject bad requests early, but they shouldn’t be the only authority for a consequential transaction. The system that actually owns the protected state still needs to verify that what it is about to execute is the same thing that was authorized.

Otherwise an authorization can be perfectly valid when it is issued and still be wrong by the time it reaches the system that changes state.

Google Cloud’s recent direction is interesting here. Agent Gateway can delegate authorization decisions to custom authorization services through Service Extensions, which gives us a strong place to insert deterministic policy enforcement before the tool call.

But I still think the final check belongs with the transactional backend for operations where the consequence is a real state change.

Once we finish the mutation tests, I’m happy to share a sanitized version of the results. I agree with your point: for this problem, the useful artifact isn’t another architecture diagram. It’s whether the altered transaction actually fails when it reaches the execution boundary.

A few Google Cloud references I’m using while testing this:

Agent Gateway overview:
https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview

Delegating authorization to custom services:
https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/delegate-authorization

Configure authorization extensions:
https://docs.cloud.google.com/service-extensions/docs/configure-authorization-extensions

Service Extensions release notes:
https://docs.cloud.google.com/service-extensions/docs/release-notes

This is exactly the distinction I was trying to get at.

I agree that the end-to-end result is the meaningful evidence here. A deterministic authorization decision can be correct in isolation, but the stronger property is whether the protected system actually refuses the altered operation and produces no state change.

The distinction you're making between the gateway/authorization layer and the system that owns the protected state is particularly useful. It also makes the test more interesting because it lets us separate “the authorization decision was correct” from “the consequential execution was actually constrained by that decision.”

I’d definitely be interested in the sanitized mutation-test results once you have them.

The cases you're testing — parameter/resource mutation, identity changes, policy changes, replay, and capability substitution — are very close to the dimensions I've been using in the AgentGuard challenge, so comparing the actual outcomes should be much more useful than comparing architectures.

And I agree with your point that the result should ultimately be demonstrated at the side-effect boundary rather than inferred from an authorization record.

Thanks for sharing the Google Cloud references as well. The Agent Gateway → custom authorization → protected system separation is particularly relevant to what I'm trying to understand.

Brodin