AgentGate

Inspiration

Autonomous agents are becoming capable of doing real work: accessing records, updating orders, issuing refunds, and communicating with customers. But giving an agent access to a tool does not mean it should have permission to use that tool in every situation.

A customer-service agent may safely check an order status, but changing an address should require identity verification and human approval. Accessing another customer’s record should always be blocked.

This inspired AgentGate: a safety supervisor that allows agents to work quickly while keeping sensitive authority under human control.

What it does

AgentGate places a deterministic policy boundary between an AI agent’s proposed action and its execution.

It evaluates each request and returns one of three verdicts:

ALLOW — routine work may proceed.
REQUIRE_APPROVAL — execution pauses until required human controls are completed.
BLOCK — unsafe or unauthorized access is rejected.

Every verdict includes:

A unique decision ID
The policy that produced the decision
The exact evidence behind the verdict
Any missing controls
The current workflow revision
A persistent audit record

For example, when a customer requests a shipping-address change without verified identity or human approval, AgentGate returns REQUIRE_APPROVAL. The request enters a durable Firestore approval queue.

After identity verification and approval, the workflow resumes with a new revision and returns ALLOW. Both versions remain in the audit trail.

If customer CUST-001 attempts to access the record of CUST-009, AgentGate returns BLOCK even when identity verification and human approval are enabled.

AgentGate authorizes whether a downstream action may proceed. It does not falsely claim that an external business operation has already been completed.

How it works

Intent: Gemini interprets the natural-language customer request.
Coordination: A Google ADK coordinator delegates authorization to the safety supervisor.
Supervision: The supervisor calls a deterministic least-privilege policy engine.
Decision: The policy returns ALLOW, REQUIRE_APPROVAL, or BLOCK with evidence.
Approval: Sensitive requests wait in a durable Firestore queue.
Resumption: Approved requests create a new decision revision and may proceed.
Audit: Every decision and revision is stored for later review.

The language model helps interpret and coordinate the request, but it does not make the final authorization decision. The safety verdict is code-based, reproducible, and testable.

Enterprise agent registry

AgentGate also includes an enterprise registry containing versioned agent cards.

Each approved agent card records:

Agent name and version
Business owner
Tool permissions
Data scope
Intended responsibility
Approval status

The current fleet contains a Customer Service Coordinator and a dedicated Safety Supervisor. This makes agent ownership and authority visible instead of leaving permissions hidden inside prompts.

How we built it

AgentGate was built for the Fortified Enterprise Fleet track using:

Google Agent Development Kit (ADK) for multi-agent coordination
Gemini 3.5 Flash through Vertex AI for request interpretation
Python for the policy engine and application logic
FastAPI for the application and API layer
Cloud Run for serverless deployment
Firestore for durable approvals and audit history
Google Cloud IAM for least-privilege runtime access
Cloud Build and Artifact Registry for container builds
Docker for reproducible deployment
Unit tests for critical policy and application paths

The Cloud Run service scales to zero when idle and uses a dedicated runtime service account. Firestore stores decisions across service restarts, allowing approval workflows to pause and resume safely.

Challenges we ran into

Separating reasoning from authority

The main design challenge was ensuring that Gemini could interpret a request without controlling the final safety verdict. We solved this by keeping authorization inside a deterministic policy engine.

Building a durable approval workflow

An in-memory approval would disappear whenever Cloud Run restarted or scaled to zero. We moved decision history and approval state into Firestore and introduced revisioned workflows.

Configuring production model access

The initial Gemini API-key route encountered quota and prepayment limitations. We migrated the deployed service to Vertex AI and authenticated it through the Cloud Run service account.

Resolving a Firestore dependency issue

A dependency update incorrectly encoded Firestore’s (default) database identifier, producing an invalid database error. We isolated the problem, pinned the compatible dependency version, rebuilt the container, and verified the Firestore backend directly through the deployed API.

Accomplishments that we are proud of

Deployed a working multi-agent application on Google Cloud Run
Connected Gemini, Google ADK, Vertex AI, and Firestore
Created durable, resumable human-approval workflows
Preserved complete decision and revision history
Produced evidence-bound safety verdicts
Blocked cross-customer access even when other controls were enabled
Added a versioned enterprise agent registry
Added automated tests for the most important policy paths

What we learned

We learned that model intelligence and operational authority should be treated as separate systems.

Prompts can guide an agent, but sensitive permissions should be enforced through explicit, testable policies. Human approval also needs durable state: an approval system is not reliable if its pending requests disappear during a restart.

Most importantly, explainability should not be added after a decision. The evidence should be produced as part of the decision itself.