Google Cloud’s agentic architecture provides strong controls for identity, isolation, prompt protection, observability, and tool access.
However, once an AI agent is allowed to trigger a consequential operation — such as approving a financial condition, changing an account state, executing a transaction, or closing a security alert — observability alone is not authorization.
We are currently testing the following separation of responsibilities for a regulated financial workflow:
1. **The AI interprets**
- Understands the user’s intent.
- Retrieves permitted context.
- Selects a potential action and its parameters.
- Produces a proposal, not an authorization.
2. **A deterministic policy service authorizes**
- Evaluates the end-user identity, agent identity, tenant, purpose, consent, policy version, transaction parameters, authority limits, and risk constraints.
- Returns either a denial or a short-lived, single-use authorization artifact.
- Operates fail-closed.
3. **The transactional system executes**
- Does not trust the model’s output as authorization.
- Independently validates the authorization artifact.
- Verifies that the identity, parameters, policy decision, and requested operation are still the same.
- Prevents replay and time-of-check/time-of-use substitution.
4. **An evidence layer proves**
- Generates a unique Decision ID and a tamper-evident receipt.
- Binds the policy version, identities, action, result, and timestamps.
- Avoids retaining the raw prompt or model output when the payload contains regulated or personal data.
Conceptually:
User / Channel
→ Agent Runtime
→ Deterministic Policy Decision Point
→ Tool or MCP invocation
→ Transactional backend
→ Verifiable decision receipt
The unresolved question is where the definitive enforcement boundary should live in Google Cloud’s current agentic stack.
The candidate patterns we are evaluating are:
- Agent Gateway as the policy enforcement point before every tool call;
- a dedicated Cloud Run policy decision service;
- an MCP proxy wrapping each consequential capability;
- enforcement directly inside each transactional backend;
- or a combination in which the gateway evaluates policy, but the backend independently verifies a signed authorization artifact.
The design must preserve the following invariants:
- the model cannot grant authority to itself;
- the human and agent identities remain attributable end-to-end;
- authorization is bound to one exact action and parameter set;
- authorization cannot be replayed or substituted;
- policy changes invalidate stale authorizations;
- failures and timeouts deny execution;
- tenant and jurisdiction boundaries remain isolated;
- audit evidence can be independently verified;
- sensitive prompts and outputs do not need to be retained;
- the additional latency remains suitable for synchronous transactions.
I would value the community’s perspective on five specific questions:
1. Is Agent Gateway intended to become the definitive authorization boundary for consequential tool execution, or primarily a routing, visibility, and security-policy layer?
2. What is the recommended Google Cloud pattern for binding a policy decision to exactly one downstream tool invocation, so that the backend can independently verify the decision?
3. Should the final enforcement decision occur at Agent Gateway, at the MCP server, or inside the transactional system itself?
4. Is there a Google-native reference pattern for producing signed, append-only, independently verifiable decision receipts without retaining the underlying prompt and response?
5. How should a single correlation or Decision ID propagate across Agent Runtime, Agent Gateway, MCP, Cloud Run, and the transactional backend without placing regulated data in logs or traces?
Our current architectural position is:
**The AI interprets.
The institution authorizes.
The system executes.
The evidence proves.**
This pattern is being implemented and adversarially tested in a bounded financial-services workflow on Google Cloud. I can share a sanitized architecture diagram and the associated security invariants if that would help the discussion.
