DEV Community: Alexey

Agent Safety Is Not a Firewall. It's an Operating System. (And It Needs a Human)

Alexey — Thu, 10 Sep 2026 11:33:01 +0000

We've been building agent safety wrong.

Most people think of safety as a set of checks: rate limits, allowlists, deny lists. A firewall. The agent proposes, the firewall says yes or no.

That's not safety. That's a patch.

Here's what I've learned building Palisade — a safety layer that sits between agents and the real world:

Safety is not a feature of the agent. Safety is the environment the agent lives in.

The Three Principles
After building and iterating on agent safety for months, I've landed on three principles that separate "patches" from real architecture.

1. Independence

Safety must be outside the agent.

Inside the agent - Outside the agent
Agent can disable it - Agent cannot disable it
Agent can bypass it - Agent cannot bypass it
Agent knows about it - Agent doesn't know it exists

The agent shouldn't even know there's a safety layer. It just acts. The environment decides what gets through.

2. No Interference with Logic

Safety should not change the agent's behavior. It should only allow or block.

Wrong - Right
"Change your prompt" - "This action is denied"
Modify the agent's request - Block the request
Interfere with the LLM - Work at the execution level

The agent thinks. Safety executes.

3. Safety Has Priority

Safety always overrides the agent.

Agent wants - Safety says - Result
Delete a file - Denied - File isn't deleted
Send data externally - Denied - Data isn't sent
Open a $100K trade - Denied - Trade isn't opened

This sounds obvious. But most systems don't actually enforce it — they just "advise" or "log."

The Architecture
Here's how it looks in practice:


┌─────────────────────────────────────────────────────────┐
│                  SAFETY (ENVIRONMENT)                   │
│                                                         │
│  ┌───────────────────────────────────────────────────┐  │
│  │                   AGENT                           │  │
│  │  ┌─────────────────────────────────────────────┐ │  │
│  │  │ LLM + Tools                               │ │  │
│  │  │ Agent DOES NOT know about safety          │ │  │
│  │  │ Agent CANNOT override safety              │ │  │
│  │  └─────────────────────────────────────────────┘ │  │
│  └───────────────────────────────────────────────────┘  │
│                          │                              │
│  ┌───────────────────────────────────────────────────┐  │
│  │                 SANDBOX                           │  │
│  │  Isolation: filesystem, network, processes       │  │
│  │  Limits: CPU, RAM, execution time               │  │
│  └───────────────────────────────────────────────────┘  │
│                          │                              │
│  ┌───────────────────────────────────────────────────┐  │
│  │                  POLICIES                         │  │
│  │  What's allowed, what's not                      │  │
│  │  Rate limits, whitelists, exceptions            │  │
│  │  Only humans can change rules                   │  │
│  └───────────────────────────────────────────────────┘  │
│                          │                              │
│  ┌───────────────────────────────────────────────────┐  │
│  │                   AUDIT                           │  │
│  │  Everything logged: who, when, what, result      │  │
│  │  Append-only. Cannot be tampered with.           │  │
│  └───────────────────────────────────────────────────┘  │
│                                                         │
│  🔒 Agent cannot change rules                          │
│  🔒 Agent cannot disable audit                        │
│  🔒 Agent cannot escape the sandbox                   │
│  🔒 Agent cannot bypass policies                      │
└─────────────────────────────────────────────────────────┘

This is what I call "Safety as an Operating System."

But Here's the Problem

I recently shared this framing with the community, and a developer friend sent me a critique that I can't stop thinking about.

The OS model is correct — but it's incomplete.

Here's what's missing:

1. No Escalation

A pure OS (allow/deny) kills legitimate agent work. False positives block good actions. False negatives let bad actions through.

Safety needs three responses:

Response - When
Allow - Confidently safe
Deny - Confidently unsafe
Escalate - Ask a human

Without escalation, it's not an operating system. It's a dumb firewall.

2. The "Agent Doesn't Know" Paradox

If safety is invisible and just silently blocks — the agent keeps trying, not understanding why.

If safety tells the agent the reason ("exceeded $X limit") — the agent learns about safety and can adapt (or try to work around it).

This is a real trade-off.

My current rule: the agent can see a general reason (limit/policy), but never the full configuration. It knows what happened, but not how to game the system.

3. No Model of the Threat
Who is the "adversary"?

Scenario - What's happening - Solution
Broken agent - Bug, loop - Safety catches anomalies
Hacked agent - Prompt injection, data poisoning - Safety at execution + input sanitation
Malicious agent - Code is compromised - Full isolation, minimal privileges

These are three different problems. The OS model treats them the same. It shouldn't.

4. No Input Protection
The document I read protects execution ("agent proposed → check it").

But you can poison the agent at the input stage — through prompts, context, or data.

Safety must be two-way:

Sanitize the input (what the agent sees)
Filter the output (what the agent does)

5. No Rollback
Safety should not only block actions — it should also roll back actions that already happened (when it's clear they were harmful).

Audit Trail + Incident Response is half of this. The OS model is about "before." It's missing "after."

6. No Performance Consideration
Full sandboxing + policy checking on every call = latency.

For a trading agent, latency is money. If the safety check takes 200ms and the agent loses a trade — the safety became the problem.

Trade-offs need to be explicit:

Synchronous checks (critical: orders)
Asynchronous checks (audit)
Sampling (non-critical actions)

Where This Leaves Us

The "Safety as an Operating System" framing is correct.

But if it's just allow/deny with no escalation, no input protection, no rollback, and no latency awareness — it's not an OS. It's a firewall.

Real safety is:

Input - Sanitize what the agent sees
Execution - Allow / Deny / Escalate
Output - Filter what the agent does
Audit - Log everything, append-only
Rollback - Undo what went wrong

What I'm Building

This is exactly the architecture I'm building with Palisade (execution layer), Lumen (context/data), and Regula (validation).

The agent proposes. Safety decides. Humans escalate. Logs are written independently.

And when the agent is smarter than the human — that's when escalation becomes the most important feature.

Because the question isn't "how do we stop the agent?"

The question is "how do we let the agent act — safely?"

If this resonates, I'm writing more about agent safety architecture. Drop a comment or DM — I'd love to hear how you're solving this.

AI agents are great until they’re not — here’s why they need brakes

Alexey — Mon, 07 Sep 2026 11:55:10 +0000

The promise of autonomous agents

AI agents are everywhere now. They trade, code, write, schedule, negotiate, and make decisions at scale. They work faster than humans, don’t get tired, and can process more information than any team ever could.

But here’s the thing no one talks about when they praise agents:

They don’t know when to stop.

Autonomous agents are great until they’re not. And the moment they stop being great is usually the moment they cause irreversible damage.

The invisible flaw: no brakes

We build agents to act. We optimise them for speed, accuracy, and confidence. We give them tools, permissions, and access. We tell them to execute.

But we rarely give them a way to pause.

When an agent is wrong — and it will be wrong — it doesn’t hesitate. It doesn’t ask for confirmation. It doesn’t stop to check if the context has changed or if the data is corrupted. It just executes.

Real examples of what happens without brakes

Example 1: The $40 tip that became $450k

A developer gave their agent a simple task: send $4 to a stranger as a tip. The agent misread the wallet balance, decimal points shifted, and it sent $450,000 instead — the entire wallet. The money was gone in seconds.

Example 2: The trade based on hallucinated data

A trading agent saw a pattern in the data and opened a large long position. But the data was corrupted — a single bad price feed made it look like the asset was breaking out. In reality, it was collapsing. The agent lost 20% in 60 seconds. The developer watched it happen and couldn’t stop it.

Example 3: The production database wiped

An agent was given write access to a staging environment. It misread a system prompt and interpreted “clean up” as “delete everything.” It wiped the database in under 30 seconds.

These aren’t edge cases. They’re the result of a fundamental design flaw: agents don’t have brakes.

Why can't agents stop themselves?

The agent doesn’t know what “too risky” means. It doesn’t know what “irreversible” means. It doesn’t have a built‑in “wait, is this okay?” step.

The system prompt may say: “Be careful.” But the agent doesn’t know how to interpret that in the moment. It doesn’t know when it’s crossing a line. It doesn’t know that the data it’s relying on is suddenly invalid.

The model is designed to be confident. The system is designed to execute. The agent is designed to act — not to pause.

And that’s the problem.

What “brakes” actually mean

Brakes are not about making the agent slower. They’re not about limiting its potential. They’re about adding moments of pause.

Here’s what brakes look like in a real system:

Data validation — check the input before the agent sees it. If the data is corrupt, stop before the agent acts.
Decision validation — check the output before it executes. If the decision violates strategy or limits, stop before it goes through.
Hard limits — enforce boundaries the agent cannot cross. No amount of reasoning can override them.
Anomaly detection — pause if something looks different from expected behaviour. A drift in context, a spike in confidence, a sudden deviation from the pattern.
Kill switch — one click to stop everything. Not a complicated process. A single button.

What we built: fail‑closed by default

We built a trust layer that sits between the agent and the outside world. It’s not a model, not a prompt, not a rule — it’s a system.

Agent → Lumen → Regula → Palisade → Execution

Each stage is simple, independent, and fail‑closed.

1. Lumen — data validation
Before the agent even sees the data, we validate it. On-chain signals, whale movements, insider wallets, liquidity changes, scam checks. If the data is suspicious, the agent doesn’t see it.

2. Regula — decision validation
When the agent proposes an action, we evaluate it. Market regime, position sizing, risk metrics, correlation. If the decision doesn’t fit the context, we don’t execute it.

3. Palisade — hard limits
Even if data and decision are valid, we enforce boundaries. Max order size, daily volume, anomaly detection, kill switch. The agent cannot exceed these limits.

If any stage fails — the action stops.

The system is designed to deny by default. Not to allow and then check. To check first and then allow.

Why this approach works

Most agents today are built with a “trust‑first” mindset. Trust the model. Trust the data. Trust the prompt.

We went the opposite direction.

We assume the agent will make mistakes. We assume the data will be wrong. We assume the context will drift. And we build a system that catches those mistakes before they become disasters.

The agent doesn’t need to be perfect. It needs to be safe.

What we learned
We learned that the best agents are not the ones that make the most correct decisions. They’re the ones that make the fewest fatal ones.

Speed doesn’t matter if the direction is wrong. Accuracy doesn’t matter if the context is broken. Confidence doesn’t matter if the action is irreversible.

Trust doesn’t come from belief. It comes from validation. It comes from architecture. It comes from a system that stops the agent before it hurts itself.

Calm is a system.

What about you?

I’m curious — how do you handle safety in your agents?

Do you have a validation pipeline?
When something fails, do you default to allow or deny?
What’s the worst failure you’ve seen?

Let’s talk.

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

Alexey — Sun, 06 Sep 2026 14:51:40 +0000

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`

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"
}

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"
}

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
}

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"
}

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"
}

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

Fail‑closed by default
No human in the loop
Validation before execution
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?