Fortified Fleet

Multi-agent incident response where information can transfer but authority cannot.

Comment

About the Project

Inspiration

Fortified Fleet grew out of a question we kept encountering while working on AI authorization and execution safety: if one agent tells another agent what should happen, when does information accidentally become authority?

Multi-agent systems are becoming capable of investigating problems, coordinating decisions, calling tools, and initiating consequential work. In a security-response setting, that is appealing: one agent can triage an alert, another can investigate the evidence, and another can recommend containment. The problem is what happens at the end of that chain. If the final agent also receives production credentials, arbitrary infrastructure targets, and a powerful execution tool, then a sequence of probabilistic reasoning has effectively become execution authority.

We wanted to build the opposite. Our working invariant became:

Information may transfer between agents. Authority must not.

Fortified Fleet was built on the pre-existing Admissible runtime, which provides the underlying authority and effect-admissibility mechanisms. For this hackathon, we built the Gemini multi-agent incident-response system, Google Cloud integrations, deterministic candidate boundary, hosted judge experience, constrained cloud-effect path, and the evidence surfaces around that runtime.

What We Built

Fortified Fleet uses three specialized Gemini agents. Triage classifies the suspected incident. Investigation examines evidence, produces findings with provenance, and recommends containment when the evidence supports it. Remediation evaluates those findings and proposes a closed semantic containment action.

None of these agents receives execution authority. Remediation does not choose a Kubernetes object, production credential, Broker identity, or arbitrary cloud API. Its job ends with semantic intent.

That intent then crosses into a deterministic boundary. A server-owned compiler verifies the live semantic support and produces one exact, sterile candidate containing no authority, credentials, physical target, binding, or rollback capability. Admissible then evaluates that same candidate under independently controlled authority contexts. With authority absent, the result is DENY and no commit. With the exact independently authorized context present, the same candidate can receive ALLOW and a durable commit.

The architecture ultimately became:

Gemini determines meaning. Deterministic software determines identity. Admissible determines authority. The Broker constrains physical effect.

The live fleet runs on Gemini 3.5 Flash through Vertex AI, with Google ADK coordinating the agents. The judge application is hosted on Cloud Run, server-held credentials are managed through Secret Manager, and release images are built with Cloud Build and stored in Artifact Registry. For the separately certified physical path, a constrained Broker integrates with Google Kubernetes Engine, while Cloud Audit Logs provide independent evidence of the resulting cloud mutation.

The public judge path intentionally stops before physical execution. Judges can run the real Gemini → compiler → Admissible workflow and see the authority comparison, but the public demo itself has no physical-effect capability. The interface separately exposes historical evidence from the certified Broker/GKE execution path.

Challenges and What We Learned

The most useful problem we encountered appeared only after moving into production.

Our original design allowed the Remediation model to produce the candidate that would later be fingerprinted and evaluated for authority. This worked repeatedly in staging. On the first production run, however, all three Gemini stages completed successfully and the output passed the earlier structural checks, but the candidate still failed the exact fingerprint comparison.

Tracing that failure showed that model-authored finding IDs, ordering, and selected supporting references could vary between otherwise valid runs. We had asked a probabilistic model to do two jobs at once: determine the meaning of the incident and reproduce a cryptographically exact machine identity.

That was the wrong boundary.

We changed the architecture so Gemini remains responsible for interpreting the evidence and deciding whether containment is supported, while deterministic server-owned software maps those validated semantics to the exact candidate identity presented for authorization. If the evidence is missing, ambiguous, or unsupported, compilation fails closed before authority evaluation begins.

That became one of the clearest lessons from the project: probabilistic reasoning can determine intent, but deterministic software should own the identity that crosses an authority boundary.

We also had to deal with problems that only appear once a system is exercised repeatedly. Durable artifacts from one run must remain auditable without accidentally becoming authority for later runs, so we tightened the continuity semantics around historical evidence. Live model calls can also fail transiently, so we added bounded per-stage recovery rather than replaying an entire fleet. During production testing, a real Remediation request received a 429; only that failed stage was retried, and the run completed normally.

The judge experience introduced another useful constraint. We wanted reviewers to run the real system themselves, but we did not want a public hackathon endpoint to become an infrastructure-mutation surface. Judge access, model-compute permission, Admissible authority, and physical execution are therefore separate capabilities. The judge access code permits bounded demo compute; it is not an authority credential.

Where We Ended Up

Fortified Fleet started as a multi-agent incident-response system, but the project ultimately became an experiment in keeping four things separate that are often collapsed together: reasoning, machine identity, authority, and physical capability.

Gemini agents can freely exchange information about an incident and recommend what should happen next. Deterministic software turns validated semantics into a stable candidate identity. Admissible independently decides whether that candidate has authority to progress. If a physical effect is ever admitted, the Broker still limits what infrastructure capability is actually available.

That brings us back to the principle we started with:

Information may transfer between agents. Authority must not.

Built With

Share this project:

Updates