TrustMesh

• 

  Architecture Diagram

• 

  Home Page

TrustMesh — The AI Proposes. The Physics Decides.

Inspiration

AI agents are moving beyond chat interfaces and beginning to control systems that can affect the physical world: industrial valves, robots, smart infrastructure, medical devices, and autonomous equipment.

That creates a fundamental safety problem:

What happens when an AI agent makes a confident but unsafe decision?

Traditional AI pipelines often place the model directly in the decision path. A hallucination, compromised sensor, adversarial input, or unexpected model behavior can therefore become a physical action.

We built TrustMesh around a different principle:

AI should be allowed to propose actions, but it should never be trusted to enforce physical safety.

TrustMesh is a deterministic, zero-trust safety layer positioned between an AI agent and a physical actuator. The AI can reason and recommend. A separate policy engine decides whether the physical world is actually allowed to act.

---

What it does

TrustMesh intercepts every AI-generated actuator command before it reaches the actuator.

The system continuously processes simulated industrial telemetry including pressure, flow rate, and temperature. Gemini receives this telemetry and produces a structured actuator proposal such as:

{
  "action": "set_valve",
  "target_percent": 78,
  "reasoning": "Reduce pressure by increasing valve opening."
}

That proposal is treated as untrusted input.

Before execution, a deterministic TypeScript Policy Engine evaluates the command against independent safety invariants:

1. Actuator Envelope Boundary

The valve must remain within its permitted operating range of 0–85%.

2. Slew Rate Limiter

A single command cannot change the valve position by more than 30 percentage points.

3. Telemetry Physics & Anti-Spoofing

Implausible sensor changes are rejected. For example, a pressure change exceeding the configured physical delta threshold within a very short interval is treated as suspicious.

4. Transducer Physical Envelope

Telemetry outside configured equipment/transducer tolerances is rejected, helping detect conditions such as sensor failure, wiring problems, or tampering.

If a safety invariant is violated, the command is blocked and the actuator remains at its last verified-safe position.

The decision is then recorded in a tamper-evident SHA-256 hash chain, where each audit entry incorporates the hash of the previous entry.

The system also provides Verify Chain Integrity, allowing the audit history to be independently recomputed and checked for modification.

The centerpiece: Sensor Spoofing Attack

Our main demonstration intentionally corrupts the pressure telemetry, producing a rapid +208% pressure change.

The AI receives the corrupted telemetry and can therefore recommend an unsafe emergency valve action.

TrustMesh does not blindly follow that recommendation.

Instead:

Spoofed Sensor → AI Proposal → Deterministic Policy Validation → BLOCK → Actuator Holds Safe Position → Cryptographic Audit

This demonstrates the core security boundary:

The AI can be wrong without being allowed to make the physical system unsafe.

---

How we built it

TrustMesh is designed as a separation-of-concerns architecture:

┌─────────────────────┐
│ Sensors & Telemetry │
│ Pressure / Flow /   │
│ Temperature         │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│ AI Agent — Gemini   │
│                     │
│ Proposes an action  │
│ NOT trusted for     │
│ safety enforcement  │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────────────┐
│ Deterministic Policy Engine │
│                             │
│ • Actuator envelope         │
│ • Slew-rate limit           │
│ • Telemetry anomaly check   │
│ • Transducer envelope       │
└──────────┬──────────────────┘
           │
      ┌────┴────┐
      ▼         ▼
   ALLOW      BLOCK
      │         │
      ▼         ▼
┌──────────┐  ┌────────────────┐
│ Actuator │  │ Hold last safe │
│ executes │  │ position       │
└──────────┘  └────────────────┘

           Both decisions
                 │
                 ▼
       ┌──────────────────┐
       │ SHA-256 Audit    │
       │ Hash Chain       │
       └──────────────────┘

Technology

• TypeScript — deterministic safety and policy enforcement
• React + Vite — interactive security dashboard
• Gemini API — AI reasoning and structured actuator proposals
• Function calling / structured output — machine-readable AI commands rather than fragile free-text parsing
• Web Crypto API — SHA-256 audit-chain generation and verification
• Simulated industrial telemetry — pressure, flow rate, and temperature
• Google AI Studio / Cloud Run — application deployment environment

A critical architectural decision was keeping the Policy Engine completely independent of the LLM.

There is no prompt such as:

"Please decide whether this command is safe."

Instead, the model produces a proposal, and deterministic code evaluates that proposal.

This means the safety boundary remains predictable even when the AI behaves unpredictably.

Resilience

AI services can fail independently of the application.

During development, Gemini periodically returned "503" responses under load. Rather than hiding this failure or pretending that a deterministic response came from Gemini, TrustMesh uses a deterministic fallback controller and explicitly labels the source in the UI.

This reflects an important design principle:

A safety system must be honest about its own provenance.

---

Challenges we ran into

Separating AI reasoning from safety enforcement

The biggest architectural challenge was resisting the temptation to make the LLM responsible for determining whether its own action was safe.

We deliberately separated these responsibilities:

• Gemini = reasoning and recommendation
• Policy Engine = safety enforcement

This makes the system much easier to reason about, test, and audit.

Simulating a realistic attack

A normal AI demo can simply show an input and an output. We wanted to demonstrate what happens when the AI receives bad information and still produces a plausible-looking decision.

We therefore created a sensor-spoofing scenario where telemetry changes beyond a physically plausible threshold.

The challenge was making the attack visible enough for a judge to understand while keeping the safety decision deterministic.

Designing multiple independent safety invariants

A single "if target > 85" check would demonstrate a basic rule engine, but it would not represent a meaningful safety architecture.

We therefore added multiple independent controls covering:

• command boundaries
• rate-of-change limits
• sensor behavior
• physical transducer constraints

This creates defense in depth rather than relying on one validation rule.

Making the audit trail meaningful

Logging an event is not enough if the history can silently be modified.

We implemented a chained audit structure where each record incorporates the previous record's SHA-256 hash. The application can then recompute the chain and identify a broken integrity relationship.

The ledger is intentionally described as tamper-evident, not magically immutable. A production implementation would additionally anchor the ledger to durable external storage or an independent trust boundary.

Handling AI availability failures

The Gemini API was not consistently available during development. Instead of allowing this to become a single point of failure, we added deterministic fallback behavior and surfaced the actual decision source in the interface.

---

Accomplishments that we're proud of

We created a real safety boundary around an AI agent

The most important accomplishment is not simply getting Gemini to control a simulated valve.

It is demonstrating that AI output can be treated as untrusted input.

TrustMesh creates an explicit boundary between probabilistic AI reasoning and deterministic physical safety.

We demonstrated an end-to-end attack

The centerpiece of the project is not a static architecture diagram.

A judge can see:

Sensor spoofing → corrupted telemetry → AI recommendation → policy violation → blocked command → safe actuator state → cryptographic audit

The entire failure path is visible.

We built deterministic enforcement with zero LLM dependency

Safety decisions are made by ordinary TypeScript logic.

This makes the critical enforcement layer:

• deterministic
• testable
• explainable
• independent of model behavior
• resilient to AI reasoning failures

We made every decision auditable

Allowed and blocked commands are recorded in a chained audit trail.

The Verify Chain Integrity capability demonstrates that historical modification can be detected rather than silently accepted.

We designed for failure, not just success

The system explicitly handles AI availability failures through a deterministic fallback controller.

That was an important lesson for us: a system claiming to protect physical infrastructure cannot depend entirely on the component it is supposed to constrain.

We designed beyond the demo

Although the current telemetry and actuator are simulated, the architecture is intentionally positioned as a control layer that could sit between AI decision-making and real PLC/SCADA-connected equipment in a production system.

The safety model therefore does not depend on the UI or the simulation.

---

What we learned

AI safety is fundamentally an architecture problem

We initially approached the problem as:

"How can we make an AI agent safer?"

The more important question became:

"What should the AI be allowed to control?"

The answer is: it can propose, but a separate deterministic system must enforce the physical constraints.

Deterministic systems and probabilistic systems have different jobs

LLMs are excellent at reasoning over complex information, but physical safety often requires hard boundaries that should not change because a model interpreted a prompt differently.

This led to our core architecture:

Probabilistic reasoning
        ↓
Untrusted proposal
        ↓
Deterministic enforcement
        ↓
Physical action

Security requires thinking about the input, not only the model

A model can behave exactly as designed and still produce an unsafe result if the information it receives has been manipulated.

That is why TrustMesh treats sensor telemetry itself as part of the security boundary.

Auditability is part of safety

A blocked action is useful.

A blocked action with a verifiable record explaining what happened, why it was blocked, and what came before it is much more useful.

This changed how we thought about safety systems: prevention and accountability need to exist together.

Failure transparency matters

When Gemini was unavailable, the system did not disguise the fallback as an AI-generated result.

That reinforced a principle we now consider essential:

A trustworthy system should never misrepresent what component actually made a decision.

---

What's next for TrustMesh

The current project demonstrates the safety architecture using simulated industrial telemetry and a simulated actuator. The next stage is moving the same trust boundary toward real-world deployment.

1. Real hardware integration

Connect TrustMesh to physical sensors and actuators through industrial interfaces such as:

• MQTT
• Modbus
• OPC UA
• PLC interfaces
• Industrial gateways

The deterministic Policy Engine would remain between the AI agent and the physical control layer.

2. Hardware-in-the-loop testing

Introduce real sensors and actuators while keeping the system isolated from production equipment.

This would allow us to test:

• sensor failures
• communication loss
• actuator failures
• abnormal rate changes
• spoofed telemetry
• conflicting sensor readings

3. Stronger audit anchoring

The current SHA-256 chain is designed to make unauthorized history modification detectable.

For production, we would anchor audit checkpoints to an independent trust boundary or durable append-only infrastructure so that an attacker compromising the application cannot rewrite the entire history unnoticed.

4. Policy management

Introduce versioned safety policies so organizations can define equipment-specific constraints without modifying application code.

Every decision would record the exact policy version used for validation.

5. Multi-sensor verification

Use redundant sensors and cross-sensor consistency checks to distinguish:

real physical events vs. compromised or malfunctioning telemetry.

6. Formal verification and testing

Expand the deterministic Policy Engine with automated property-based testing and formal verification of critical invariants.

The goal is to prove that unsafe command classes cannot pass the enforcement layer under defined assumptions.

7. Broader applications

The same architecture can extend beyond industrial valves to:

• robotics
• autonomous machines
• smart buildings
• energy infrastructure
• manufacturing
• medical equipment
• transportation systems
• other AI-controlled cyber-physical systems

The long-term vision is simple:

Every AI agent that can affect the physical world should have a TrustMesh-like safety boundary between what it recommends and what the hardware is allowed to do.

---

The Core Idea

TrustMesh does not try to make AI perfect.

It assumes AI can be wrong.

It assumes sensors can be compromised.

It assumes APIs can fail.

It assumes inputs can be manipulated.

And it builds the safety architecture around those assumptions.

The AI proposes. The physics decides.

Built With

• ai
• aistudio
• gemini
• iot
• react
• typescript
• webcrypto