TrustGate: Fivetran-Powered Authorization for AI Agents

AI agents act on data they never checked. TrustGate holds a Gemini agent's action until live Fivetran and BigQuery evidence earns an ALLOW, with an auditable receipt either way.

Comment

Inspiration

Every time an AI agent approves a refund, it is trusting data it never checked. If the pipeline went stale overnight, if a schema shifted, or if a value shows up that no contract ever authorized, the agent still acts, confidently, and the loss is real money or a real customer.

I kept coming back to one idea: model guardrails cannot fix this, because the failure is not in the prompt. It is in the data supply chain behind the action. Fivetran already calls itself the data foundation for AI agents, so I flipped the question. Instead of asking whether the agent is smart enough to act, ask whether the data behind the action is trustworthy enough to allow it.

What it does

TrustGate is the checkpoint an AI agent must clear before it touches anything real. It sits between a Gemini agent and the action and answers one question: is the data behind this safe enough to proceed?

The demo is a customer recovery agent deciding on a refund. Before the refund runs, TrustGate inspects the live data supply chain: the Fivetran connection and sync state over REST, the same connection independently verified through Fivetran's official MCP server, and the actual customer row from the Fivetran-synced BigQuery table. It checks all of that against a versioned input contract, and a deterministic policy engine returns one of three verdicts:

  • ALLOW: the data is trustworthy and the refund is in policy.
  • APPROVAL_REQUIRED: something observable broke the contract, like a customer_tier value that contract v1 never authorized, so it routes to a human before any money moves.
  • BLOCK: a critical schema or connection failure is a hard stop.

The point is that the data drives the outcome, not the prompt. Change one attribute to an unseen customer tier and the exact same agent flips from ALLOW to APPROVAL_REQUIRED. Every decision returns an auditable receipt with the evidence, the contract version, and a transparent risk breakdown. Gemini explains the verdict. The policy engine makes it.

How I built it

I built TrustGate as a stateless API on Cloud Run with a small control-room dashboard.

  • Agent: a Customer Recovery Agent in Google Cloud Agent Builder, powered by Gemini, whose only tool is TrustGate.
  • Tool wiring: TrustGate exposes its own MCP endpoint publishing one tool, proposeTrustGateAction. The agent connects to it through Agent Builder's "Add tools" then "MCP Server" option.
  • Fivetran over REST: connection details, sync state, and schema config from a Google Sheets to BigQuery connection.
  • Fivetran over MCP: the container installs the official Fivetran MCP server (github.com/fivetran/fivetran-mcp), and the backend spawns it over stdio to call list_connections and get_connection_details.
  • BigQuery: a live query against trustgate-hackathon.trustgate_demo.customers for the exact row in the decision.
  • Policy engine: deterministic rules with transparent weights. The risk score is the sum of triggered rule weights, never a model confidence score.
  • 17 automated tests cover the decisions, the freshness signal, and the MCP endpoint.

The honest architecture: the Gemini agent calls TrustGate's MCP. TrustGate then calls Fivetran's official MCP server, Fivetran REST, and BigQuery itself. The agent never calls Fivetran's MCP directly, and I never claim it does.

Challenges I ran into

  • The Agent Designer Tools panel I had access to offered MCP Server but no OpenAPI import. So I made TrustGate an MCP server of its own and connected it that way, which turned out to be the cleaner integration anyway.
  • Fivetran /state returned 405 for the Google Sheets connector. Instead of hiding it, I made that call optional and let the receipt record exactly which calls succeeded.
  • Cloud Run is stateless, so a demo that mutated in-memory state could hit a different instance and silently fail to flip the decision. I moved the scenario into the request body so the result is deterministic on any instance.
  • Secret Manager returned 401 at first because the secret versions carried newline encoding. Recreating them as clean ASCII fixed it.

Accomplishments that I am proud of

  • The whole loop is live, not staged: a Gemini agent in Agent Builder calls an MCP tool, TrustGate on Cloud Run evaluates it against live Fivetran REST, live Fivetran MCP, and live BigQuery, and returns an auditable receipt.
  • Fivetran provably changes the decision. An unseen customer_tier flips ALLOW to APPROVAL_REQUIRED. The data is doing the work, not decorating the demo.
  • It is honest by design. The model explains, a deterministic engine decides, and I wrote down exactly what I am not claiming.

What I learned

Agent safety is a data problem as much as a model problem. The highest-leverage place to govern an autonomous agent is the one second before it acts, where you can still ask whether the data supply chain is trustworthy and hand off to a human when it is not.

What's next for TrustGate: Fivetran-Powered Authorization for AI Agents

Any team putting an agent near money, refunds, or customer records faces the same risk, so the roadmap is about making this production grade:

  • Authenticated agent identity on every proposed action.
  • Immutable, replayable audit receipts with evidence, policy version, and contract version.
  • Versioned input contracts with policy tests before a contract ships.
  • An enterprise approval workflow with approver identity, expiry, and scoped exceptions.
  • More action types: discounts, account changes, invoice adjustments, access changes.

Built With

Share this project:

Updates