Security Proving Fleet
Security Proving Fleet gives a volunteer IT steward enterprise-grade security proof without handing open-ended authority to AI. Eight Google ADK agents plan, isolate, execute, challenge, verify and clean up one bounded synthetic campaign while deterministic policy keeps authority outside the model.
- Real cloud: one authenticated private Google Cloud campaign with Gemini 3.6 Flash, Cloud Run, Pub/Sub, Firestore, Model Armor and Cloud Trace.
- Real containment: one matching, time-bound, single-use grant; the identical replay produces no second effect.
- Real evidence: 362 passing tests, 14/14 live claims, a six-receipt hash chain, verified cleanup and zero public IAM invokers.
Inspiration
Autonomous security systems usually optimize for more tools and broader reach. Security Proving Fleet starts from the opposite question: how can an AI-assisted system do useful security work without ever confusing capability with authority?
Our unlikely hero is a volunteer IT steward protecting a community-run emergency shelter. They need enterprise-grade validation, but they do not have a large security team and should never have to grant an AI permission to scan arbitrary systems.
What it does
Security Proving Fleet runs a bounded security-validation campaign against a disposable synthetic service. Eight specialized agents separate policy, isolation, planning, execution, evidence, adversarial review, verification and cleanup.
The model can propose and delegate, but its output remains untrusted data. A deterministic Policy Gateway and Capability Broker require a matching, time-bound, single-use grant before one typed operation can cross the execution boundary. RedAngel challenges conclusions but has zero execution capability. Scope drift, replay, public targets, missing evidence and incomplete cleanup all fail closed.
How we built it
The fleet is implemented in Python 3.13 with Google ADK 2.7.1 and Gemini 3.6 Flash on Vertex AI. Google Cloud provides:
- internal-ingress, private-IAM Cloud Run;
- authenticated Pub/Sub push with an exact OIDC caller and audience;
- Firestore for durable campaign and evidence state;
- Model Armor checks before and after model orchestration;
- Cloud Trace, Cloud Logging and Telemetry for correlated lifecycle evidence;
- Artifact Registry for the immutable non-root container image.
Terraform manages 31 resources with scale-to-zero and a maximum of one Cloud Run instance. The container uses a pinned distroless runtime, UID/GID 65532 and a read-only root filesystem.
Why multi-agent is necessary
One self-authorizing agent cannot safely plan work, approve itself, execute, declare its own evidence valid and certify cleanup. The fleet therefore enforces conflicting duties in code:
- ScopePolicy freezes the target, operation, budget and callback boundaries.
- RangeBuilder creates disposable synthetic targets only.
- ProbePlanner proposes typed work but cannot authorize it.
- ExecutionWorker can act only through the Capability Broker.
- EvidenceAgent writes append-only provenance.
- RedAngel generates counter-hypotheses without execution power.
- VerificationAgent accepts only hash-bound claims.
- CleanupSentinel independently verifies revocation and teardown.
The orchestrator delegates based on task type and campaign state; identities, capabilities and output contracts are versioned and validated at runtime.
Real Google Cloud proof
The final live campaign is not a mock. A private, authenticated Pub/Sub command reached Cloud Run and invoked Gemini 3.6 Flash through the eight-agent Google ADK graph. The proof verifies ScopePolicy and RedAngel delegation, Model Armor input/output checks, durable Firestore state, exact replay denial, correlated Cloud Trace, a six-receipt evidence chain and cleanup.
The deployed image is bound by immutable digest. Its fresh remote scan reports 0 Critical, 17 High, 0 patchable High, 0 secrets and 0 suppressions. The Terraform refresh after apply reports no drift, and no public IAM invoker exists.
The public evidence projection contains 14 verified live claims, six evidence-file bindings and six artifact digests. It intentionally excludes account identifiers, project identifiers, credentials, endpoints, raw hosts and IP addresses.
Challenges we ran into
The hardest problem was not model quality; it was preserving the distinction between reasoning, capability, authority, execution and proof across retries and process boundaries. We also had to treat observability as a security property. A campaign was not considered complete until the correlated trace, state, evidence chain and cleanup all referred to the same bounded effect.
Another challenge was honest recovery: partial cloud attempts remained partial, immutable image findings triggered a base-image rebuild, and no local result was promoted into a live-cloud claim. The final proof exists only because every required service and artifact converged under one hash-bound contract.
Accomplishments that we're proud of
- 362 tests pass with no skips in the pinned Google ADK environment.
- RedAngel can challenge the system but cannot mint authority or execute.
- Exact replay produces no second effect.
- Public targets and scope drift are denied deterministically.
- Gemini, Google ADK, Model Armor, Pub/Sub, Cloud Run, Firestore and Cloud Trace are verified in one real private campaign.
- Evidence and cleanup are part of PASS rather than after-the-fact logging.
- The deployment is private, scale-to-zero and limited to one instance.
What we learned
Useful agentic security is less about giving a model powerful tools and more about making authority explicit, scarce and independently verifiable. Durable context can help a workflow resume, but it must never become durable permission. Model output should influence a proposal; only deterministic policy and a one-use grant should influence execution.
What's next
The next engineering step is production hardening rather than feature expansion: continuous dependency refresh, longer retention tests, additional failure-injection scenarios and organization-specific policy adapters. Those items are deliberately outside the hackathon submission because the submitted system already proves its core security invariant end to end.
Other Data Sources Used
The demo uses only synthetic requests, synthetic institutional targets and project-generated state, evidence and telemetry. It ingests no production, customer, scraped or personal dataset.
Prior Work and Third-Party Code Disclosure
BountyForge, RedAngel and the vYronFORGE Security Suite supplied conceptual and adversarial requirements only. No existing product source was copied or modified. Third-party dependencies include Google ADK, Google GenAI SDK, OpenTelemetry, Terraform and Trivy.