illusiontion

Inspiration

AI agents are becoming capable of doing more than answering questions — they can increasingly recommend, decide, and act.

That makes hallucination a much bigger problem.

A wrong answer is annoying. A confident wrong answer that becomes an authorized decision can be dangerous.

Imagine someone asking an AI whether two medications can be taken together. The model may sound certain even when its evidence is weak, incomplete, or wrong. The problem is no longer just whether the model can produce an answer. The problem is: when has that answer earned the right to become authority?

That question became the foundation of Illusiontion.

Evidence before authority.

What it does

Illusiontion is a governed AI review system that separates model reasoning from authorization.

Before a claim can PASS, Illusiontion:

1. freezes the claim and the complete evidence universe;
2. separates evidence into three spaces:
   • E0 — the complete frozen evidence universe;
   • E1 — the evidence selected to support the claim;
   • E2 — independent reviewer views derived from E0;
3. invokes seven context-isolated specialist reviewer roles;
4. checks evidence validity, scope, provenance, semantic support, counterexamples, and prompt-injection risk;
5. sends the results to a deterministic governance gate;
6. returns PASS, HOLD, or REJECT;
7. persists the governed decision;
8. creates a cryptographically signed proof that can be verified independently.

A successful model run does not automatically produce PASS.

For example, one of our certified cases completed the live evidence acquisition and reviewer execution successfully, but the evidence did not meet the required source and origin diversity. Illusiontion returned HOLD.

That behavior is the core of the project: a capable model is not automatically an authorized model.

How we built it

Illusiontion is built around Google ADK and runs on Google Cloud.

The reviewer roles use Gemini 3.7 Flash through Vertex AI. They are independently invoked and context-isolated, while the certified run uses the same configured Gemini model ID across those roles.

The production flow is:

Trusted evidence acquisition → frozen evidence spaces → Google ADK reviewer roles → deterministic governance gate → Firestore decision record → Cloud KMS signed proof → independent offline verification

The live system uses:

• Google ADK for agent orchestration;
• Gemini 3.7 Flash via Vertex AI for specialist review;
• Cloud Run for the deployed runtime;
• Firestore for governed decision persistence;
• Cloud KMS for asymmetric proof signing;
• Secret Manager for runtime secrets;
• Cloud Build / Artifact Registry for deployment infrastructure.

We also built a standalone verifier using only the Python standard library. It can verify a frozen Illusiontion proof outside the running application and pins both the expected public key and exact KMS key version.

Challenges we ran into

Some of the hardest problems appeared only after we stopped testing happy paths.

One live Google Cloud documentation page was larger than the reviewer-facing evidence schema allowed. The HTTP acquisition itself succeeded, but the evidence object failed validation. We changed the design so Illusiontion hashes the complete HTTP response while exposing a bounded reviewer snapshot and explicitly records whether truncation occurred.

We also found a false-positive prompt-injection rule. Ordinary Cloud Run documentation containing phrases such as "run your code" and "function" was being interpreted as an instruction attack. Instead of weakening the security gate globally, we narrowed the detector to explicit command/tool instructions and red-teamed it against both benign prose and real injection patterns.

Trusted evidence acquisition created another boundary: the model cannot be allowed to invent its own evidence provenance. Illusiontion therefore performs HTTPS acquisition inside the trusted runtime, restricts allowed origins, rejects redirects, hashes the captured response, and creates the evidence admission record outside the model.

Finally, producing a proof was not enough. We wanted the verifier to distrust the producer. That led us to a separate offline verification path that independently reconstructs the signed payload and rejects repaired hashes, corrupted signatures, and substituted keys.

Accomplishments that we're proud of

Illusiontion is not only a presentation prototype — the full governance path is deployed and exercised live.

We built and demonstrated:

• a live Google ADK service on Cloud Run;
• Gemini 3.7 Flash reviewer calls through Vertex AI;
• seven context-isolated specialist reviewer roles;
• trusted live HTTPS evidence acquisition;
• the E0 / E1 / E2 evidence separation;
• deterministic PASS / HOLD / REJECT governance;
• Firestore persistence of governed decisions;
• Cloud KMS asymmetric proof signing;
• an independent offline proof verifier;
• certified examples showing both PASS and conservative HOLD behavior.

We also red-teamed the publication build and proof system with mutated proofs, signatures, evidence receipts, malformed reviewer responses, substituted keys, URL/origin fuzzing, and prompt-injection variants.

The result we are most proud of is still the simplest one:

reviewer success does not equal permission to act.

What we learned

The biggest lesson was that hallucination containment cannot be solved by adding another prompt that asks the model to "double-check."

The important boundaries need to exist outside the model.

Evidence acquisition, evidence immutability, reviewer isolation, authorization policy, persistence, and proof verification each need explicit ownership.

We also learned that security rules can fail in both directions. A weak detector can admit an attack, but an overly broad detector can block legitimate evidence. Red-teaming both false negatives and false positives changed several parts of the system.

Most importantly, we stopped thinking of trustworthy AI as "making the model more confident."

The better question is:

What evidence and independent checks must exist before confidence is allowed to become authority?

What's next for Illusiontion

The next step is to move from a single governed-review application toward a reusable authorization layer for agentic systems.

We want to explore:

• policies tuned for different decision domains;
• heterogeneous reviewer models and providers;
• richer provenance and evidence-source policies;
• organization-level approval workflows;
• integrations where an external agent must present a valid Illusiontion authorization proof before a high-impact action can execute.

The long-term goal is simple:

As agents gain more power to act, they should also gain a stronger obligation to prove when they have earned that authority.

Built With

• ai-agents
• artifact-registry
• cloud-build
• cloud-kms
• cloud-run
• firestore
• gemini
• gemini-3.7-flash
• google-adk
• google-cloud
• python
• secret-manager
• vertex-ai