-
-
Dashboard
-
Registry
-
Vetting
-
Fleet
-
Activity
Inspiration
AI agents are becoming increasingly capable of using external tools, APIs, MCP servers, and models. That creates a new software supply-chain problem:
What happens when an AI agent trusts a capability that it should not trust?
A capability does not need to contain obviously malicious code to become dangerous. Its description, schema, endpoint, or requested permissions can contain instructions or behavior that causes an agent to expose sensitive information, make unauthorized requests, or operate beyond its intended scope.
Traditional software supply-chain security gives us mechanisms for provenance, integrity, and policy enforcement. AI-agent capabilities introduce another challenge: some security risks are semantic and require reasoning to identify.
We wanted to combine these ideas into a single security boundary for agent capabilities.
That became WARDEN.
The idea is simple:
AI reasons about risk
+
Cryptography establishes trust
+
Deterministic policy controls execution
WARDEN is designed around the principle that an LLM should help understand risk, but should not be the only thing responsible for enforcing security.
What it does
WARDEN is a software supply-chain firewall for AI agents.
A capability submitted to WARDEN goes through inspection before it can become trusted.
Capability
|
v
+-------------------+
| Gemma 2 Pre-Screen|
| Fast First Pass |
+---------+---------+
|
v
+-------------------+
| Inspector |
| Gemini + ADK |
+---------+---------+
|
Security Verdict
|
+--------+--------+
| |
BLOCK APPROVE
|
v
+----------------+
| Registrar |
| Ed25519 Seal |
+-------+--------+
|
v
Trusted Registry
|
v
+----------------+
| Gatekeeper |
| Signature + |
| Policy Checks |
+-------+--------+
|
+-----+-----+
| |
ALLOW BLOCK
Two Google Models, Two Jobs
WARDEN uses two Google models, each matched to what it does best:
- Gemma 2 (
gemma-2-9b-it), Google's open-weights model, runs a fast, low-cost first-pass screen for obvious red flags — prompt-injection phrasing, suspicious egress, and dangerous over-broad scopes. - Gemini 3.5 Flash on Vertex AI then performs the deep OWASP LLM Top 10 analysis that produces the final structured verdict, with evidence for every finding.
The fast model handles the common signal; the deeper model does the heavy reasoning. Every capability's verdict records the Gemma pre-screen result alongside the Gemini findings.
Security Analysis
After Gemma 2's fast pre-screen, the Inspector uses Gemini through Google Vertex AI to analyze capability manifests adversarially.
WARDEN currently looks for risks including:
| Threat | What WARDEN evaluates |
|---|---|
| Prompt Injection | Instructions attempting to manipulate agent behavior |
| Data Exfiltration | Attempts to send sensitive information to external destinations |
| Sensitive Information Disclosure | Exposure or misuse of sensitive information |
| Supply-Chain Risk | Suspicious or potentially compromised capability behavior |
| Excessive Agency | Capabilities requesting unnecessary authority or permissions |
| Insecure Plugin Design | Dangerous capability interfaces or behaviors |
| Insecure Output Handling | Unsafe handling of capability output |
The findings are classified using the OWASP LLM Top 10 (2025) taxonomy, together with an explicit data-exfiltration category.
The Inspector returns a structured verdict containing information such as:
- Risk score
- Severity
- Findings
- Evidence
- Threat classification
- Approval or rejection decision
Test It With Your Own Capability
WARDEN is designed to make the inspection process directly testable.
The dashboard allows a user to paste a capability manifest or upload a capability definition and submit it to the real pipeline.
Your Capability
|
v
+-------------------+
| Paste / Upload |
| Capability JSON |
+---------+---------+
|
v
Gemma 2 Pre-Screen
|
v
Gemini Inspector
|
v
Security Findings
|
+----+----+
| |
APPROVE BLOCK
This means the demonstration is not limited to a predefined list of security results. A capability submitted during the demonstration can go through the actual inspection pipeline.
Cryptographic Trust
The model verdict is not treated as the runtime security mechanism by itself.
When a capability is approved, WARDEN creates an Ed25519 cryptographic seal over the canonical representation of the capability manifest and its security verdict.
Conceptually:
$$ M = \operatorname{Canonicalize}(\text{Manifest} \parallel \text{Verdict}) $$
The registrar then creates the signature:
$$ \sigma = \operatorname{Ed25519.Sign}(sk, M) $$
At runtime, the Gatekeeper verifies:
$$ \operatorname{Ed25519.Verify}(pk, M, \sigma) $$
A modification to the signed capability or verdict causes verification to fail.
The trust relationship is therefore:
What was inspected
=
What was approved
=
What was cryptographically sealed
=
What can be verified at runtime
Runtime Enforcement
The Gatekeeper performs deterministic checks before allowing a capability to execute.
| Check | Purpose |
|---|---|
| Signature verification | Confirms the capability was cryptographically approved |
| Policy evaluation | Checks requested permissions against policy |
| Risk threshold | Rejects capabilities above the configured threshold |
| Registry lookup | Confirms the capability exists in the trusted registry |
| Audit logging | Records the enforcement decision |
This creates a deliberate separation:
Gemini evaluates risk. Deterministic code enforces trust.
Continuous Re-Vetting
WARDEN also includes a Sweeper component for re-vetting previously approved capabilities.
The current architecture supports the re-vetting and revocation workflow, while automated scheduled sweeping is part of the planned next stage.
REGISTER
|
v
VET
|
v
SEAL
|
v
RUN
|
v
RE-VET
|
+-----------> Keep Trusted
|
+-----------> Revoke
How we built it
WARDEN was built as a Google Cloud-based application with a FastAPI backend, Next.js dashboard, and separate components for inspection, registration, runtime enforcement, and re-vetting.
System Architecture
AI AGENT FLEET
|
|
Capability Registration
|
v
+-------------------------+
| ORCHESTRATOR |
| Registration Workflow |
+------------+------------+
|
v
+-------------------------+
| GEMMA 2 PRE-SCREEN |
| |
| Google ADK Agent |
| Fast first-pass scan |
+------------+------------+
|
v
+-------------------------+
| INSPECTOR |
| |
| Google ADK Agent |
| | |
| v |
| Gemini on Vertex AI |
+------------+------------+
|
Structured Verdict
|
v
+-------------------------+
| REGISTRAR |
| |
| Provenance + Ed25519 |
+------------+------------+
|
v
+-------------------------+
| FIRESTORE |
| |
| Registry + Audit Events |
+------------+------------+
|
v
+-------------------------+
| GATEKEEPER |
| |
| Signature Verification |
| Policy Enforcement |
+------------+------------+
|
+-----+-----+
| |
ALLOW BLOCK
Component Architecture
WARDEN separates AI reasoning from deterministic security operations.
| Component | Responsibility | AI-powered |
|---|---|---|
| Gemma Pre-Screener | Fast first-pass capability screening | Yes |
| Inspector | Adversarial capability analysis | Yes |
| Orchestrator | Coordinates registration workflow | No |
| Registrar | Provenance and cryptographic sealing | No |
| Gatekeeper | Runtime verification and policy enforcement | No |
| Sweeper | Re-vetting and revocation | No |
The two model-backed agents — the Gemma 2 pre-screener and the Gemini Inspector — provide the reasoning. The cryptographic and policy-critical paths remain deterministic.
Registration Pipeline
Capability Manifest
|
v
Input Validation
|
v
Gemma 2 Fast Pre-Screen
|
v
Gemini Security Analysis
|
v
Structured Vetting Verdict
|
+----+----+
| |
BLOCK APPROVE
| |
| v
| Canonical Manifest
| +
| Security Verdict
| |
| v
| Ed25519 Seal
| |
| v
| Firestore
|
v
Audit Event
Runtime Pipeline
Agent Invocation
|
v
Capability Lookup
|
v
Signature Verification
|
+---- Invalid ------> BLOCK
|
v
Policy Evaluation
|
+---- Denied -------> BLOCK
|
v
Risk / Permission Checks
|
+---- Failed -------> BLOCK
|
v
ALLOW
|
v
Capability Execution
|
v
Audit Event
Google Cloud Stack
| Layer | Technology | Role |
|---|---|---|
| Agent Framework | Google ADK | Gemma + Inspector agents |
| Pre-Screening | Gemma 2 (open-weights) | Fast first-pass capability screen |
| AI Reasoning | Gemini 3.5 Flash on Vertex AI | Deep security analysis |
| Backend | FastAPI + Cloud Run | API and orchestration |
| Frontend | Next.js + Cloud Run | Security dashboard |
| Database | Firestore | Capability registry and audit data |
| Secrets | Secret Manager | Signing-key storage |
| Cryptography | Ed25519 | Capability sealing |
| Observability | OpenTelemetry + Cloud Trace | Request tracing |
| Payload Security | Model Armor integration point | Planned runtime screening |
| Scheduling | Pub/Sub + Cloud Scheduler infrastructure | Planned automated sweep workflow |
Security Decision Model
WARDEN intentionally separates risk assessment from authorization.
A capability can be represented as:
$$ C = (M, V, \sigma) $$
where:
- (M) is the canonical capability manifest
- (V) is the security verdict
- (\sigma) is the Ed25519 signature
The runtime decision is then based on deterministic verification and policy:
$$ \text{Allow}(C) = \text{ValidSignature}(C) \land \text{PolicyAllows}(C) \land \text{RiskAcceptable}(C) $$
This is the central architectural idea behind WARDEN.
Challenges we ran into
1. Using an LLM without making it the security boundary
The biggest architectural challenge was deciding how much authority to give Gemini.
An LLM is useful for understanding natural-language descriptions and identifying suspicious behavior, but security-critical enforcement should be predictable.
We therefore separated the responsibilities:
Gemini
|
+--> Understand and evaluate risk
|
v
Structured Verdict
|
v
Deterministic Security Layer
|
+-----+-----+
| |
Cryptography Policy
| |
+-----+-----+
|
v
Runtime Decision
This allows Gemini to provide the semantic reasoning while keeping cryptographic verification and policy enforcement outside the model.
2. Balancing cost and depth with two models
Running full deep analysis on every manifest is more work than most cases need. We added Gemma 2 as a fast, lightweight first-pass screener ahead of Gemini 3.5 Flash, so the cheap open-weights model handles the obvious signals while the deeper model does the full OWASP reasoning. Designing the pipeline as two tiers — an open-weights fast screen feeding a managed deep analysis — was a deliberate architectural choice.
3. Making approvals tamper-evident
A database record saying that a capability was approved is not sufficient.
We needed the approval to remain connected to the exact capability that was evaluated.
WARDEN therefore signs the canonical representation of the capability and its security verdict with Ed25519.
If the signed data changes, verification fails.
4. Firestore query constraints
During deployment, some registry queries required Firestore composite indexes.
For the current application, we redesigned those queries to use simpler equality filtering and perform the remaining ordering and version selection in application code.
This allowed the deployed application to operate without additional composite-index configuration.
5. Vertex AI authentication
Getting the deployed Inspector working correctly required handling Google Cloud authentication rather than relying on a consumer-style API-key setup.
WARDEN uses Google Cloud service-account credentials with Vertex AI, allowing the Cloud Run service to authenticate through its Google Cloud identity.
6. Making the demonstration genuinely interactive
We wanted to demonstrate actual inspection rather than predefined security results.
The dashboard therefore supports submitting a capability manifest directly for inspection.
The submitted capability is processed by the actual pipeline and the resulting security findings and verdict are displayed in the dashboard.
Accomplishments that we're proud of
WARDEN currently demonstrates an end-to-end capability trust workflow:
SUBMIT
|
v
PRE-SCREEN (Gemma 2)
|
v
INSPECT (Gemini 3.5 Flash)
|
v
APPROVE / BLOCK
|
v
CRYPTOGRAPHICALLY SEAL
|
v
REGISTER
|
v
VERIFY
|
v
ENFORCE
|
v
AUDIT
Key accomplishments
| Capability | Implementation |
|---|---|
| Two-tier model pipeline | Gemma 2 fast screen + Gemini 3.5 Flash deep analysis |
| AI security inspection | Gemini through Vertex AI |
| Fast pre-screening | Gemma 2 (open-weights) |
| Agent integration | Google ADK |
| Structured security verdicts | Typed inspection results |
| Threat taxonomy | OWASP LLM Top 10 (2025) + data-exfiltration category |
| Cryptographic trust | Ed25519 signatures |
| Runtime verification | Deterministic Gatekeeper |
| Permission control | Policy enforcement |
| Capability registry | Firestore |
| Provenance | Registration metadata and signed approvals |
| Auditability | Recorded security events |
| Re-vetting | Sweeper component |
| Interactive testing | User-submitted capability manifests |
| Cloud deployment | Cloud Run + Google Cloud services |
The accomplishment we are most proud of is that WARDEN does not stop at:
"The AI thinks this tool is safe."
The decision continues through:
AI Analysis
↓
Approval
↓
Cryptographic Sealing
↓
Runtime Verification
↓
Policy Enforcement
That gives the project a security model that combines AI reasoning with deterministic controls.
What we learned
AI agents need a capability trust layer
Our biggest lesson was that securing an AI agent is not only about securing the model.
The tools, APIs, MCP servers, and other capabilities available to an agent become part of its effective attack surface.
That means these capabilities need their own security controls.
AI and deterministic security have different strengths
We learned that the strongest architecture is not necessarily one where AI does everything.
| AI is useful for | Deterministic systems are useful for |
|---|---|
| Understanding natural language | Signature verification |
| Identifying suspicious intent | Policy enforcement |
| Reasoning about ambiguous behavior | Permission checks |
| Classifying findings | Reproducible decisions |
| Producing contextual evidence | Audit records |
WARDEN combines these strengths instead of treating the LLM as the entire security mechanism.
Use AI to understand risk. Use deterministic systems to enforce trust.
Different models for different jobs
Pairing an open-weights model (Gemma 2) for fast screening with a managed model (Gemini 3.5 Flash) for deep reasoning taught us that a security pipeline does not need a single model to do everything. Routing each stage to the model best suited to it keeps the common path fast and inexpensive while preserving depth where it matters.
Trust is a lifecycle
We also learned that a capability's security status should not necessarily be permanent.
Capabilities can change, new threats can emerge, and previously accepted behavior may need to be reviewed again.
This led us to model trust as a lifecycle:
$$ \text{Vet} \rightarrow \text{Seal} \rightarrow \text{Verify} \rightarrow \text{Re-vet} \rightarrow \text{Revoke} $$
This is why WARDEN includes a Sweeper and revocation workflow.
Security for a fleet is different from securing one agent
WARDEN was designed around the idea of a shared trust layer for an agent fleet.
Instead of implementing capability security independently inside every agent, a common registry, inspection process, cryptographic trust model, and enforcement layer can provide a consistent security boundary across multiple agents.
This is also why WARDEN fits the Fortified Enterprise Fleet track: the focus is not simply protecting one AI interaction, but establishing consistent capability trust across an environment where multiple agents may depend on shared software capabilities.
What's next for Warden
WARDEN currently provides the foundation for a capability trust layer. The next steps are focused on making that trust layer more deeply integrated with agent runtimes and more continuous.
1. Direct agent-runtime integration
The next step is to integrate the Gatekeeper directly into agent runtimes through middleware or an ADK callback.
This would allow capability verification and policy enforcement to happen automatically during agent execution.
2. Identity-aware policies
We want to extend policy enforcement from a general policy to agent-specific capability policies.
For example:
| Agent | Example allowed scope |
|---|---|
| Research Agent | Read-only web capabilities |
| Coding Agent | Approved repository operations |
| Data Agent | Approved database access |
| Deployment Agent | Restricted deployment APIs |
This would move WARDEN further toward least-privilege capability access for individual agents.
3. Continuous re-vetting
The Sweeper is designed to support recurring re-evaluation of approved capabilities.
The next step is to connect it to the existing scheduling infrastructure so capabilities can be periodically re-vetted and revoked when their security status changes.
Scheduled Sweep
|
v
Approved Registry
|
v
Re-vet Capabilities
|
+---+---+
| |
v v
Safe Risk Changed
| |
v v
Keep Revoke
Trust Seal
4. Runtime payload screening
WARDEN includes a Model Armor integration point.
The next step is to enable runtime payload screening as part of the active enforcement path alongside capability verification and policy checks.
5. Capability-source connectors
We want WARDEN to eventually connect directly to capability registries and other trusted sources.
The longer-term workflow becomes:
DISCOVER
|
v
INSPECT
|
v
SEAL
|
v
MONITOR
|
v
RE-VET
|
v
REVOKE WHEN NEEDED
The goal is to make WARDEN a continuous trust layer between AI agents and the software capabilities they depend on.
Final Takeaway
AI agents are increasingly defined not only by the model behind them, but by what they are allowed to use and what they are allowed to do.
WARDEN addresses that boundary with three layers:
AI REASONING
|
"Is this risky?"
|
v
CRYPTOGRAPHIC TRUST
|
"Was this approved?"
|
v
DETERMINISTIC POLICY
|
"Can it run here?"
|
v
AGENT RUNTIME
WARDEN turns the AI-agent software supply chain into a verifiable security boundary.
Built With
- docker
- ed25519
- fastapi
- gemini-3.5-flash
- gemma-2
- google-adk
- google-cloud-firestore
- google-cloud-run
- google-cloud-trace
- google-secret-manager
- model-armor
- next.js
- python
- react
- typescript
- vertex-ai
Log in or sign up for Devpost to join the conversation.