Provenance

Inspiration

As enterprises deploy more autonomous agents, two questions become critical:

1. Who decides what an agent is allowed to do?
2. Who decides what the organization should remember as true?

Letting an LLM answer either question creates the same failure mode: the component making a recommendation also controls whether that recommendation becomes reality.

Provenance began with one principle:

An LLM may propose, but deterministic policy must decide.

I wanted to build more than an incident-response agent. I wanted an enterprise agent fleet that could act autonomously while maintaining institutional memory with provenance, computed confidence, supersession, retraction, and expiry.

Self-healing is the visible workflow. Governed institutional belief is the product.

What it does

A monitoring event wakes a multi-agent fleet that:

1. Classifies and routes the incident.
2. Recalls current entity and class-level beliefs.
3. Diagnoses the likely cause through a specialized domain agent.
4. Produces one typed remediation proposal.
5. Checks identity, permissions, standing, and deterministic risk.
6. Executes only an authorized action.
7. Verifies the result against a success predicate declared before execution.
8. Commits a new belief only when the evidence satisfies deterministic memory policy.

The core loop is:

OBSERVE → DIAGNOSE → PROPOSE → AUTHORIZE → EXECUTE → VERIFY → LEARN

Risk is calculated from fixed properties such as action class, target criticality, blast radius, and reversibility. Low-risk actions can proceed automatically. High-risk actions park in a durable approval queue where a store operations manager sees what the fleet wants to do, why, and the complete risk calculation.

Verification has three possible outcomes:

• CONFIRMED: record what worked.
• REFUTED: record confirmed negative knowledge and retry once.
• INCONCLUSIVE: escalate and learn nothing.

The memory system is append-only. Beliefs are superseded or retracted rather than overwritten, and a background Staleness Sweeper downgrades expired beliefs to UNKNOWN so old information cannot quietly continue looking current.

How I built it

Provenance is a Python 3.12 service deployed on Google Cloud Run. Google ADK's Graph Runtime provides explicit multi-agent routing and bounded retry edges, while Firestore stores the synthetic enterprise, agent registry, authorization ledger, approval queue, evidence, and immutable belief histories.

The fleet includes:

• A Gemini 2.5 Pro Orchestrator
• SRE/Infrastructure and Supply-Chain domain agents
• A Gemini 2.5 Pro Remediation Planner
• A Gemini 3.5 Flash Verification Agent
• A Gemini 2.5 Pro Memory Analyst
• A Vertex AI embedding model for belief recall

Gemini 3.5 Flash is exercised on every incident as the verification judge, satisfying the hackathon's mandatory Gemini 3.5 requirement.

I also integrated Gemma 4 (gemma-4-26b-a4b-it-maas) as an additional Google AI model and isolated security component. Gemma runs serverlessly on Vertex AI as an isolated sanitizer: untrusted external content is reduced to a typed neutral fact, and residual PII is replaced with validated placeholders before any frontier model sees it. This is a load-bearing security integration rather than a decorative model call.

Before Gemma, Google Cloud Model Armor screens the content for prompt injection, jailbreak attempts, and sensitive data. I deliberately treat both Model Armor and Gemma as filters — not as the final security boundary. Even if they leak, the resulting action must still pass through the deterministic Agent Gateway.

The gateway:

• Revalidates the complete action schema
• Verifies short-lived, agent-signed credentials
• Reads registry standing at request time
• Enforces RBAC and ABAC
• Computes risk from a fixed lookup table
• Signs every approval, hold, and denial
• Provides the only route to state-mutating execution

PortunusMCP supplies limited ECDSA-signing and ABAC primitives, while the project's risk engine, credential flow, registry standing, typed actions, approval queue, and authorization logic are implemented in this repository.

Memory follows the same architecture. The Memory Analyst may recommend a belief, but the deterministic Memory Policy Engine decides whether it becomes institutional truth.

Evidence decays over time:

$$ w_i(t) = b_i \cdot 2^{-a_i/h_d} $$

Here, $b_i$ is the published base weight for an evidence class, $a_i$ is its age, and $h_d$ is the domain's half-life.

Confidence uses noisy-OR over the strongest evidence from each independent source class:

$$ C = 1 - \prod_c \left(1 - \max_{i \in c} w_i\right) $$

A new belief requires $C \ge 0.50$. Overturning an existing belief requires $C \ge 0.70$ and corroboration from a genuinely different, non-zero-weight evidence class. An LLM never supplies these numbers.

OpenTelemetry spans flow into Cloud Trace and the browser interface. The UI contains six operator surfaces: the live fleet, gateway ledger, belief inspector, registry panel, human approval card, and counterfactual evaluation panel.

Challenges I ran into

The largest challenge was ensuring that my safety claims were enforced by architecture rather than prompts.

Prompt-injection filters can miss attacks. A sanitizer can preserve a malicious implication. I therefore designed the attack demonstration so the outer defensive layers can leak while the deterministic gateway still stops the dangerous action.

Durable human approval was another challenge. I initially planned to use an ADK Task API, but that API did not exist. I replaced that assumption with a Firestore-backed approval record and a second gateway entry point. When a human responds, the gateway revalidates the proposal, rereads the agent's current standing, and recomputes risk instead of trusting stale authorization state.

Live testing uncovered two security defects:

• A zero-weight external claim could participate in a belief flip by riding alongside previously strong evidence. I fixed the conflict rule so evidence that contributes nothing cannot provide corroboration.
• The approval card initially derived its hold reason from the routed domain agent instead of the action's proposer. A live queue test exposed the mismatch.

Generalizing the system also cost more than expected. The Supply-Chain agent required 114 lines, but removing hidden infrastructure-specific assumptions required 207 behavioral lines elsewhere. I documented that result rather than claiming the control plane had always been domain-independent.

Finally, the verification environment is synthetic. That makes the attack scenarios safe to run live, but it does not reproduce the ambiguity, missing telemetry, or partial failures of a real production system. I disclose that limitation instead of treating a controlled fixture as production proof.

Accomplishments that I'm proud of

• I built and deployed a complete multi-agent system that takes real action instead of only producing text.
• Every state-mutating action passes through one deterministic, signed authorization path.
• Every institutional belief passes through a separate deterministic policy engine with typed evidence and computed confidence.
• Beliefs support immutable versions, supersession, conflict handling, retraction, class-level generalization, decay, and expiry.
• High-risk actions survive process restarts in a durable human approval queue.
• The prompt-injection and memory-poisoning demonstrations exercise real failure paths rather than describing hypothetical attacks.
• Gemma 4 provides an additional, meaningful Google AI integration by isolating and sanitizing untrusted content.
• The project has 565 passing tests, strict production-code type checking, clean linting, and live verification scripts that read results back from authoritative cloud state.
• The public Cloud Run deployment exposes decisions, evidence, risk arithmetic, agent standing, and memory history instead of asking judges to trust a narrated architecture diagram.
• I published negative evaluation results when the measurement did not support my original expectation.

What I learned

My most surprising result was that memory did not make the measured incident faster.

Across twelve live incidents, the memory-enabled arm took a median of 52.3 seconds, compared with 39.0 seconds without recall — a 34% increase. Both arms made the same diagnosis, used four model calls, considered the same number of hypotheses, reached the same verdict, and committed the same confidence.

The domain agent's prompt already contained enough information to find the correct diagnosis. Recall added a Firestore read, an embedding request, and more prompt tokens without changing the conclusion.

I kept the prompt and published the negative result rather than redesigning the experiment to flatter the system.

That clarified the real value of institutional memory: it is not automatically a latency optimization. Its value is making organizational belief governed, inspectable, expirable, retractable, and resistant to manipulation.

I also learned that retrieval is not the same as memory. An embedding index can nominate something similar, but it cannot decide what the organization currently believes. The authoritative store must resolve the current version, status, confidence, and provenance.

Most importantly, verification is the foundation of learning. A memory system that confidently learns from unreliable verification is worse than one that remembers nothing.

What's next for Provenance

The next step is connecting Provenance to real operational systems and testing its three-valued verification model against uncontrolled telemetry.

Planned work includes:

• Adding production connectors for monitoring, deployment, supplier, and compliance systems
• Strengthening class-belief generalization with larger support requirements and statistical validation
• Adding audited workflows for restoring an agent's standing
• Supporting multiple approvers, escalation tiers, delegation, and out-of-office routing
• Expanding from two operational domains to domains 3–N
• Moving process-local signing keys into Google Secret Manager
• Replacing query-time brute-force embeddings with managed vector search when belief volume requires it
• Persisting the live trace surface beyond one Cloud Run process
• Giving the Staleness Sweeper an independent runtime so its schedule does not depend on a warm application instance

The long-term goal is an enterprise nervous system that can act, learn, generalize, defend what it has learned, and clearly distinguish between what it knows, what it has disproved, and what it has not checked recently.

Data sources and disclosures

The synthetic company is based on the Customer Service dataset from google/adk-samples (Apache-2.0). All services, suppliers, configuration histories, tier assignments, and fault-injection records are authored for Provenance.

PortunusMCP 0.1.0 (MIT) is pre-existing, authored by me, and was published before the submission period. Provenance consumes only limited signing and ABAC primitives as a pinned library dependency; its typed actions, credentials, registry standing, deterministic risk engine, gateway, and approval workflow are new.

My pre-existing ProdRescue project informed the general diagnose → fix → verify → retry loop shape. Provenance’s Google ADK implementation, multi-domain routing, governed memory, and authorization architecture are new.

Built With

• cloud-run
• cloud-trace
• cryptography
• css
• docker
• fastapi
• firestore
• gemini-2.5-pro
• gemini-3.5-flash
• gemma-4
• github-actions
• google-adk
• google-cloud
• html
• javascript
• model-armor
• opentelemetry
• portunusmcp
• pydantic
• pytest
• python
• text-embedding-005
• vertex-ai