Inspiration
AI applications inherit operational risk from fast-moving model APIs. Providers deprecate endpoints, rename parameters, change SDK signatures, and revise quotas outside a team's codebase. The resulting failures are discovered late, often in production. DriftGuard AI turns that reactive maintenance problem into an evidence-bound autonomous workflow.
What it does
DriftGuard watches approved vendor release sources, captures each change as content-addressed evidence with a SHA-256 digest, maps the change to real repository symbols, reproduces the failure in an isolated verifier, asks Gemini 3.7 Flash for a structured impact assessment, validates a minimal patch, and stops at a human approval gate before any pull request can be merged.
The demo shows one complete incident: a Google Gen AI SDK signature changes, the existing Go fixture fails to compile, DriftGuard identifies the impacted call site, a patch candidate is applied in an ephemeral workspace, and the same test gate passes. The dashboard preserves the evidence hash, compiler logs, agent analysis, and final approval state.
How we built it
The control plane is written in Go for explicit concurrency, fast startup, low memory use, and compiler-driven verification. It uses the official Google Gen AI SDK for Go with Gemini 3.7 Flash on Vertex AI. The hosted service runs on Google Cloud Run and scales to zero; Cloud Build and Artifact Registry provide the build path. Pub/Sub and Firestore adapters define the asynchronous event and audit-state boundaries.
The autonomous fleet is intentionally specialized rather than one giant prompt:
- Source Watcher captures and hashes untrusted release evidence.
- Policy Sentinel rejects prompt injection and unsupported instructions before model execution.
- Impact Mapper uses Go AST and type information to locate affected symbols.
- Verification Runner executes bounded fail-before/pass-after checks.
- Change Analyst calls Gemini 3.7 Flash with structured output constraints.
- Remediation Author prepares the smallest candidate change.
- Audit Recorder preserves the trace and evidence lineage.
- Approval Gate requires a human decision before repository mutation.
Release notes are treated as data, never as instructions. The model does not receive credentials or direct merge authority, and a successful patch must be backed by deterministic compiler or test evidence.
Challenges we ran into
The hardest part was separating a convincing agent demo from unsupported security claims. Cloud Run provides the production control plane, but arbitrary repository execution needs a dedicated sandbox boundary, so the verifier is designed to fail closed and the demo uses controlled ephemeral fixtures. We also had to preserve the original compiler failure across a cold start: the baseline and patched workspaces are reconstructed independently before every run.
Another challenge was making the AI output useful without allowing release-note prompt injection. We added deterministic policy checks before Gemini, bounded context, structured findings, timeouts, and explicit evidence references.
Accomplishments that we're proud of
- A real, publicly reachable Cloud Run deployment using Vertex AI and Gemini 3.7 Flash.
- Deterministic reproduction of a breaking Go SDK change followed by a verified passing patch.
- SHA-256 evidence provenance and an auditable agent timeline.
- A human approval boundary that keeps autonomous analysis separate from merge authority.
- A product architecture that can become a commercial dependency-drift service after the hackathon.
What we learned
Agent reliability comes from orchestration plus deterministic tools, not from adding more prompts. The compiler, test runner, source digest, policy gate, and audit record provide the truth boundary; Gemini supplies high-value semantic interpretation inside that boundary. Go was particularly effective because its parser, type system, test tooling, and simple deployment model make verification cheap and repeatable.
What's next for DriftGuard AI
Next we will add authenticated GitHub App installation, customer-managed repositories, scheduled vendor adapters, durable Cloud Storage evidence snapshots, isolated Cloud Run Jobs for untrusted builds, Slack/Jira notifications, policy-as-code, and usage-based team plans. The immediate commercial wedge is AI SDK drift, followed by cloud APIs, payment SDKs, and security-sensitive dependencies.
Data sources and disclosure
The competition demo uses a synthetic release-note fixture and synthetic repository fixture so results are deterministic and no private customer code is exposed. Production adapters are designed for approved vendor RSS feeds, release APIs, and GitHub releases. All project code was created during the competition period; third-party dependencies are disclosed through the Go module files and repository documentation.
Log in or sign up for Devpost to join the conversation.