OPEN REFERENCE
Google ADK
Let a Google ADK agent request cloud provisioning while the receiver checks the signed ceiling before anything is created.
This is a reference, not a hosted lab. The source and instructions are open and it runs on your machine in minutes. Nothing on this page executes here, and no integration is hosted for you.
Ratify Protocol is an open protocol for proving delegated authority: a principal signs a bounded delegation naming what an agent may do, and any receiver can verify that proof offline, before acting, without calling the issuer. This page is one open reference implementation of it.What Ratify Protocol is ↗
An independent draft reference implementation. Not a Google partnership, Google-approved integration, or Google reference architecture.
Why would a developer or enterprise need this?
Google Cloud and ADK already provide substantial controls: IAM on the resource,
service identity for the workload, and ADK's own tool and callback surface for
what an agent may select. Ratify is complementary. It gives the system carrying
the consequence evidence of the narrower mandate behind one action.
| Question |
Google Cloud / ADK controls |
Ratify authority |
| Can this workload reach the API? |
Yes, through IAM and service identity |
Not its purpose |
| Can this agent select this tool? |
Yes, through ADK tool configuration |
Not its purpose |
| Did a recognized principal authorize this exact action? |
Not expressed by workload identity alone |
Yes |
| Is the authority limited to this project, region, and node count? |
IAM can bound the resource; the per-action ceiling is application logic |
Signed into the delegation and checked by the receiver |
| Can a different organization verify the mandate? |
Depends on a shared Google Cloud trust domain |
Yes, from portable proof and configured trust roots |
| Was the proof changed, revoked, expired, or replayed? |
Separate concern |
Verified before the handler runs |
Workload identity answers which service is calling. It does not carry which
human or organization sanctioned this particular provisioning request, at this
size, for this project. That distinction matters when an agent holds
credentials broader than the current task, when a receiver serves agents it did
not issue, or when the call crosses an organizational boundary.
Who implements what
Four roles. Google implements nothing: the reference uses ADK's public
agent and tool surface and an ordinary MCP receiver, so no change to ADK,
Gemini, or any Google Cloud service is required.
| Role |
Who this usually is |
What they do |
What they build |
| Principal |
The organization accountable for the cloud resource |
Signs a bounded delegation naming scope, resource, node count, and expiry |
No code. Issues a delegation with the SDK or Ratify Verify, and decides the bounds |
| Agent operator |
The team running the ADK agent |
Points the agent at the receiver and the trusted principal |
No protocol code, but real configuration: receiver address, trust root, and which tools are protected |
| Receiver operator |
Whoever owns the consequence: the provisioning API or MCP server |
Issues challenges, verifies the proof, guards the handler |
The verification path: authority_reference/receiver.py and the transport boundary in mcp_server.py. The verify call is a small part; the rest is challenge issuance, header handling, trust-root comparison, and keeping the handler unreachable except through the allow branch |
| Google ADK / Gemini |
The agent framework and model |
Select and call the tool as they already do |
Nothing |
The asymmetry is the point. The party carrying the risk is the party that
checks, and it can check without trusting the agent, the model, the prompt, or
the framework that routed the call.
What the reference proves
The suite encodes why the boundary matters:
| Case |
Expected result |
Protected tool |
Correct agent, one node, us-central1 |
allow |
Invoked once |
| Three nodes under a one-node grant |
constraint_denied |
Not invoked |
us-east1 under a us-central1 grant |
constraint_denied |
Not invoked |
| Expired delegation |
expired |
Not invoked |
| Revoked leaf delegation |
revoked |
Not invoked |
| Replayed presentation |
invalid / consumed challenge |
Not invoked again |
| Operation changed after challenge issuance |
operation_binding_failed |
Not invoked |
| Different agent answers the challenge |
agent_binding_failed |
Not invoked |
| Valid chain under an untrusted root |
untrusted_root |
Not invoked |
| Non-integral, zero, negative, boolean, or excessive node count |
Input rejected |
Not invoked |
| Duplicate transport-authentication headers |
HTTP 400 before MCP dispatch |
Not invoked |
Which path should I use?
Use this open reference when you want to read every line of the decision
path, run it without a Google Cloud account or a model key, and adapt the
receiver to your own service. It is Apache-2.0 with no runtime dependency on a
hosted Ratify service.
Register interest in Ratify Verify when you would rather not operate trust
distribution, revocation freshness, challenge storage, and audit retention
yourself. Those are the deployment concerns under "Reference scope and
production requirements" below, and they are what turns a working reference
into a production control.
Both verify the same proofs. The protocol does not change between them.
Run it yourself
Before you start: Python 3.12. No Google Cloud project, model key, or paid service.
Clone ratify-protocol, then from the repository root:
./scripts/google-adk-reference-check.sh
33 tests pass, zero skipped, and the gate fails on any skip.
