DEV Community

Cover image for Here’s the trust layer I built to prevent AI's mistakes
Alexey
Alexey

Posted on

Here’s the trust layer I built to prevent AI's mistakes

The moment I stopped trusting the agent
I built a trading agent. It worked in backtests. Clean profits. Low drawdown. Good Sharpe.

I put it on a test wallet with $50k.

On day 3, it executed a trade based on bad data. A single corrupted price feed made it think an asset was breaking out. It wasn’t.

20% loss in 60 seconds.

I watched it happen and couldn’t stop it.

That’s when I realised: the problem wasn’t the agent. The problem was the pipeline.

Agent receives data → Agent decides → Agent executes

No validation. No sanity checks. Just trust.

The architecture: Lumen → Regula → Palisade
I built a trust layer that sits between the agent and the exchange.

`Agent → Lumen → Regula → Palisade → Exchange
         │        │          │
       Data    Decision    Hard limits`
Enter fullscreen mode Exit fullscreen mode

1. Lumen — on‑chain intelligence
Lumen validates the context before the agent even sees the data.

What it checks:

Module - What it validates

  • Whale Movements - Transfers >$1M to exchanges or between wallets
  • Insider Wallets - Wallets linked to team, investors, early buyers
  • Liquidity Changes - Pool changes (inflow/outflow)
  • Vesting Unlocks - Upcoming token unlocks
  • Scam DB - Address against scam, phishing, and sanction lists Request:
POST /intel/0x742d...
{
  "address": "0x1234...5678"
}
Enter fullscreen mode Exit fullscreen mode

Response:

{
  "address": "0x1234...5678",
  "summary": "Bearish signal",
  "signals": [
    {
      "type": "whale",
      "message": "3 whales depositing to Binance",
      "confidence": 0.82,
      "severity": "high"
    },
    {
      "type": "insider",
      "message": "Team wallet started selling",
      "confidence": 0.91,
      "severity": "high"
    }
  ],
  "recommendation": "exit_or_reduce"
}
Enter fullscreen mode Exit fullscreen mode

Key design choice: Lumen doesn't tell the agent what to do. It gives structured context so the agent can make an informed decision.

2. Regula — trade validation
When the agent proposes a trade, Regula evaluates it before execution.

What it checks:

Module - What it validates

  • Market Regime - Trending, flat, chaotic (ADX + volatility)
  • Position Sizer - Optimal position size based on volatility
  • Drawdown (VaR) - Value at Risk on real prices
  • Liquidation Risk - Cascade risk based on Open Interest
  • Correlation - Correlation with the user’s portfolio Request:
POST /risk/validate
{
  "symbol": "BTCUSDT",
  "side": "LONG",
  "amount": 5000,
  "leverage": 3
}

Enter fullscreen mode Exit fullscreen mode

Response (rejected):

{
  "approved": false,
  "confidence": 0.78,
  "position_details": {
    "optimal_size": 800,
    "entry_levels": { "optimal": 64361.16 },
    "exit_levels": {
      "stop_loss_hard": 61143.10,
      "take_profit_1": 67579.22
    },
    "risk_reward_ratio": 3.0
  },
  "market_context": {
    "regime": "trending",
    "volatility_daily_pct": 0.2
  },
  "rejection_reason": "VaR exceeds 2% of portfolio"
}
Enter fullscreen mode Exit fullscreen mode

Key design choice: Regula doesn't just reject. It suggests a safer alternative (optimal_size). The agent can ignore it — but then it takes full risk.

3. Palisade — hard limits and enforcement
Palisade sits between the agent and the exchange. Every outgoing order passes through it.

What it enforces:

Module - What it does
Rules (limits) - Max order size, daily volume, orders per minute
Anomaly detector - z‑score > 3, loops, unusual patterns
Kill switch - One‑click halt of all orders
Key revoke - One‑click full API key revocation
Audit trail - Every action logged
Flow:
Agent → Palisade → Exchange

├─ rules check
├─ anomaly detection
├─ audit log
└─ if violation → 403 Forbidden

Example response (blocked):

{
  "status": "REJECTED",
  "reason": "Order size exceeds max limit",
  "limit": 10000,
  "attempted": 50000,
  "timestamp": "2026-09-06T14:32:11Z"
}
Enter fullscreen mode Exit fullscreen mode

Key design choice: Palisade is a wall, not a counsellor. It doesn't suggest — it blocks.

Real‑world example
Here’s a real log from a live run:

[Agent #17] Trade #384
Lumen: anomaly detected (whale movement)
Regula: rejected (VaR exceeded limit)
Palisade: blocked
Status: SAFE

The agent wanted to buy $50,000 worth of BTC. Lumen detected three whale wallets depositing to Binance. Regula calculated VaR and rejected it. Palisade enforced the block.

10 seconds later, BTC dropped 3%. The loss was prevented.

No human intervention.

Key principles

  1. Fail‑closed by default
  2. No human in the loop
  3. Validation before execution
  4. Structured data, not prompts

What about you?
I’m curious how others handle safety in production agents:

  • Do you validate data before the agent acts?
  • What’s your decision validation pipeline?
  • When something fails, do you default to allow or deny?
  • What’s the worst "oops" moment you’ve had?

Top comments (0)