SOAR Capabilities: When AI Agents Defend Themselves — and the Case for Hydra

A swarm of intelligent agents managing real money, without a security layer, is not a product. It is a target.

This is the final article in the AI to Web3 series. Over the past six weeks we have built every layer of Hydra: LangGraph orchestration (Article 1), n8n execution (Article 2), RAG knowledge (Article 3), LangFuse observability (Article 4), fine-tuned specialist models (Article 5), and multi-agent swarm coordination with cost-aware routing (Article 6).

Today we add the immune system: SOAR capabilities via the Guardian agent. Then we present the full Hydra architecture.

Why we are writing about this

$1.7 billion was lost to DeFi exploits in 2025. The attack surface is expanding — not because smart contracts have gotten sloppier, but because the adversaries have gotten smarter. Attackers now use autonomous coding agents to tailor exploits, simulate transaction sequences, and identify protocol interactions that create vulnerable states.

You need agents to defend against agents.

The traditional answer — SOAR (Security Orchestration, Automation and Response) — was built for enterprise IT. Static playbooks. Manual scripting. If-then logic that requires anticipating every threat scenario in advance. In an environment where novel attack vectors appear faster than security teams can author playbooks, this model has collapsed.

Torq, Elastic, and Trend Micro are in agreement: legacy SOAR is functionally dead. Agentic AI SOC — where LLM-driven agents reason through security scenarios dynamically, generating response logic at runtime — is the replacement.

SOAR: the four capabilities

S — Security. Continuous monitoring of telemetry for behavioral anomalies. In DeFi this means: on-chain transaction patterns (flash loans, unusual swap sequences, large position changes), oracle price deviations (potential manipulation), smart contract state changes (unexpected parameter modifications), and MEV activity (sandwiching, frontrunning patterns).

O — Orchestration. Coordinating specialized security agents — triage, investigation, remediation — via a supervisory OmniAgent. The key protocol here is MCP (Model Context Protocol) for standardized tool access: SIEM logs, threat intelligence, on-chain indexers, simulation APIs. Each security agent accesses exactly what it needs, nothing more.

A — Automation. Dynamic playbook generation at runtime. Instead of "if flash loan detected, run playbook_42", the Guardian agent reasons: "this flash loan pattern precedes a reentrancy attack in 87% of historical cases; here is the specific response sequence for this protocol given current state." No pre-authoring required. Self-healing integrations — agents detect API drift and generate corrective code autonomously.

R — Response. Autonomous action within defined limits: block a transaction before it executes, pause a strategy, reduce position sizes, alert a human, trigger an n8n incident response workflow. Actions are scoped by governance parameters that define the Guardian's authority.

Agentic SOAR in practice: the platforms leading the shift

D3 Morpheus — purpose-built cybersecurity LLM, Attack Path Discovery engine, self-healing integrations, runtime playbook generation. The most technically mature platform in the space.

Torq HyperSOC — multi-agent system with "Socrates" OmniAgent, five specialized sub-agents (Runbook, Investigation, Remediation, Case Management, Threat Hunting), native MCP support, RAG-enhanced knowledge retrieval. The Carvana case study shows 100% of Tier-1 alerts handled autonomously.

Prophet Security — glass-box reasoning with replayable decision timelines. Every security decision the agent makes can be reconstructed and audited.

ZeroTrusted.ai — 232 specialized AI agents, 288 tools, 94%+ auto-resolution rate. FedRAMP High and NIST SP 800-53 compliant.

Open-source options for self-hosted deployments:

For Hydra we use Tracecat — it is self-hostable, Python-native, and its Temporal-based workflow engine integrates cleanly with n8n.

Web3 SOAR: the specific threat model

DeFi security in 2026 operates under an AI-vs-AI adversarial model. The threat landscape:

Flash loan attacks. An attacker borrows a large amount within a single transaction, manipulates a price oracle, exploits a protocol's accounting logic, and returns the loan — all atomically. The entire attack may execute in under 1 second. No human can respond in time. Only an agent that has pre-simulated the transaction before it executes can intercept it.

Oracle manipulation. Price oracles are the weak link in DeFi. An attacker buys a large position, waits for an oracle update, exploits the temporary price discrepancy across protocols, then sells. The Guardian monitors oracle freshness and price deviation across multiple independent feeds.

Governance attacks. A well-funded attacker accumulates voting tokens, submits a malicious governance proposal, votes it through, and drains the treasury. The Guardian monitors Snapshot and on-chain governance contracts for proposals that would grant anomalous permissions.

Rug pulls and insider moves. Large wallet movements from protocol-associated addresses (deployers, multi-sig signers, team vesting contracts) that precede protocol abandonment. On-chain pattern recognition that no human analyst reviews at scale.

The AI arms race. Nethermind's 2026 security report documents attackers using autonomous coding agents to tailor exploits for specific protocol versions. The defender's response is fine-tuned models trained on historical exploit patterns — exactly what the Analyst from Article 5 provides.

On-chain agent identity: ERC-8004

ERC-8004, live on Ethereum mainnet since January 2026, establishes an on-chain registry for agent identity. Each agent has:

• A deterministic on-chain address
• A linked reputation score updated by independent verifier hooks
• zkML provers for verifying that the agent's decisions were produced by a specific model with specific weights
• TEE (Trusted Execution Environment) oracle attestations for hardware-level execution verification

For Hydra this means the Guardian's transaction interceptions are cryptographically attributable to a specific model run. When the Guardian blocks a transaction and logs the decision on-chain, anyone can verify: this specific model, with these specific weights, made this decision at this block height.

BNB Chain BAP-578 extends this with an agent reputation framework — a decentralized record of an agent's historical accuracy, reliability, and safety record. Agents build reputations that other protocols can query before trusting their inputs.

Transaction simulation before signing: Tenderly

The Guardian's most important capability is blocking bad transactions before they execute. Tenderly's Simulation API forks the EVM at the current block height and simulates a transaction in the forked environment — without broadcasting to the network.

If the simulation fails, or if the simulated outcome deviates significantly from the Guardian's expectations, the transaction is blocked and a human alert is triggered. The simulation result is logged to LangFuse as a trace, with the specific revert reason.

This is the DeFi equivalent of a security team reviewing a firewall rule change in a staging environment before applying it to production.

Hydra — Article 7 contribution: the Guardian agent

The Guardian is the final Hydra agent. It runs independently of the decision cycle, continuously monitoring the threat surface. It also intercepts every Executor action before it reaches the n8n webhook.

# hydra/guardian.py — commit 3f63f16
import logging, os, httpx
from langchain_core.prompts import ChatPromptTemplate
from hydra.orchestrator import HydraState
from hydra.observer import log_guardian_block
from hydra.router import get_guardian_llm

log = logging.getLogger(__name__)

async def guardian_node(state: HydraState) -> HydraState:
    """
    Security gate: evaluates every proposed decision before Executor runs.
    Conservative defaults: LLM failure → ESCALATE (not approve).
    Approved decisions go to safe_decisions; executor reads that channel.
    """
    if not state["decisions"]:
        return {}

    llm = get_guardian_llm()
    safe_decisions, blocked_decisions = [], []

    for decision in state["decisions"]:
        if "transaction" not in decision:
            safe_decisions.append(decision)
            continue

        simulation = await simulate_transaction(decision["transaction"])

        if simulation.get("status") == "reverted":
            reason = f"Simulation reverted: {simulation.get('revert_reason', 'unknown')}"
            log.warning("guardian: BLOCKED — %s", reason)
            blocked_decisions.append({**decision, "guardian_reason": reason})
            log_guardian_block(state.get("trace_id", ""), decision, reason)
            continue

        try:
            assessment = await (GUARDIAN_PROMPT | llm).ainvoke({
                "transaction": decision["transaction"],
                "simulation": simulation,
                "threats": state.get("threats", []),
                "portfolio": state["portfolio"],
                "risks": state["risks"],
            })
            verdict = assessment.content.split("\n")[0].strip().upper()
        except Exception as e:
            # LLM failure: escalate rather than silently approve (conservative)
            log.error("guardian: LLM failed — escalating to human: %s", e)
            safe_decisions.append({**decision, "require_human_approval": True,
                                   "guardian_note": f"LLM unavailable ({e})"})
            continue

        if "BLOCK" in verdict:
            blocked_decisions.append({**decision, "guardian_reason": assessment.content})
            log_guardian_block(state.get("trace_id", ""), decision, assessment.content)
        elif "ESCALATE" in verdict:
            safe_decisions.append({**decision, "require_human_approval": True,
                                   "guardian_note": assessment.content})
        else:
            safe_decisions.append(decision)

    new_risks = [{"type": "guardian_blocked", "items": blocked_decisions}] if blocked_decisions else []
    # safe_decisions is a plain list owned by guardian; executor reads it.
    # risks uses operator.add — return only new items.
    return {"safe_decisions": safe_decisions, "risks": new_risks}

The Guardian sits between the Strategist and the Executor. One state design point: decisions accumulates via operator.add (multiple writers), while safe_decisions is a plain list written only by the Guardian — this prevents approved decisions from doubling when the channel merges.

# hydra/orchestrator.py — commit d879df2
graph.add_node("guardian", guardian_node)
graph.add_edge("strategist", "guardian")
graph.add_conditional_edges(
    "guardian",
    # Check safe_decisions (guardian output) not decisions (accumulating channel)
    lambda s: "executor" if s.get("safe_decisions") and s.get("human_approved") else END,
    {"executor": "executor", END: END},
)

The full Hydra architecture

This is the system built across seven articles. Every layer is a real, self-contained capability. Every line of code shown in this series is functional.

                          ┌─────────────────────────────────────────┐
                          │            Hydra Agent Mesh              │
                          │                                          │
  ┌──────────┐  A2A/MCP  │  ┌──────────┐    ┌──────────────────┐  │
  │ Sentinel  │──────────▶│  │Strategist│◀───│     Analyst      │  │
  │ (Art. 3)  │           │  │(Art. 1+6)│    │ (Art. 5 — local) │  │
  │ GraphRAG  │           │  └────┬─────┘    └──────────────────┘  │
  │ pgvector  │           │       │                                  │
  └──────────┘           │  ┌────▼─────┐    ┌──────────────────┐  │
                          │  │ Guardian │    │     Oracle        │  │
  ┌──────────┐  A2A/MCP  │  │(Art. 7)  │    │  (Art. 3+6)      │  │
  │  Oracle   │──────────▶│  │  SOAR    │    │  Critic-Refiner   │  │
  │ (Art. 3+6)│           │  └────┬─────┘    └──────────────────┘  │
  │ Agentic   │           │       │                                  │
  │   RAG     │           │  ┌────▼─────┐                          │
  └──────────┘           │  │ Executor │                           │
                          │  │(Art. 2)  │                           │
                          │  │   n8n    │                           │
                          │  └────┬─────┘                          │
                          └───────┼─────────────────────────────────┘
                                  │
                    ┌─────────────┼─────────────┐
                    ▼             ▼             ▼
             ┌──────────┐  ┌──────────┐  ┌──────────┐
             │ Uniswap  │  │  Aave    │  │ Snapshot │
             │ Pools    │  │ Lending  │  │   DAO    │
             └──────────┘  └──────────┘  └──────────┘

  Observability: LangFuse traces every node — Art. 4
  Model routing: OpenRouter + difficulty classifier — Art. 6
  Identity: ERC-8004 on-chain agent registry

Technology stack — every article contributes a layer

Cost architecture

Naive implementation (all Sonnet 4.6): ~$3,200/month. 93% cost reduction from model tiering, caching, and local inference.

Why this is a spectacular Web3 use case

Sovereign. Every component is self-hosted. No private key data, portfolio information, or trading logic ever leaves your infrastructure. The LangFuse traces are on your server. The vector store is your Postgres instance. The fine-tuned model runs on your GPU.

Auditable. Every agent decision is traced end-to-end via LangFuse. Guardian interceptions are logged on-chain via ERC-8004. The attestation hash from Article 4 links any decision back to the specific model weights, retrieved context, and input state that produced it.

Defensible. The Guardian provides SOAR capabilities that commercial DeFi protocols charge enterprise rates for. Transaction simulation before signing catches attacks before they execute. The fine-tuned Analyst was trained on exploit data — it recognizes attack precursors that general models miss.

DAO-governable. Strategy parameters (yield targets, risk tolerance thresholds, Guardian authority limits) are externalizable to governance. A DAO can vote on how aggressively Hydra pursues yield versus how conservatively the Guardian blocks transactions.

Compounding. Each cycle makes the next one smarter. The Analyst's assessments become Sentinel retrieval context. The Guardian's blocked transactions become training examples for the next fine-tuning run. The system improves without retraining.

Building Hydra: a phased roadmap

Phase 1: Read-only intelligence (Articles 1, 3, 4) Run Sentinel + Analyst in read-only mode. No transactions. Get LangFuse observability wired. Validate that the RAG knowledge base is accurate and the Analyst's assessments match your manual analysis. Duration: 1-2 weeks.

Phase 2: Triggered execution (Articles 2, 5) Add the n8n Executor with human approval gates on every action. Fine-tune the Analyst on your specific portfolio's protocols. Start running with full human-in-the-loop before any autonomous execution. Duration: 2-4 weeks.

Phase 3: Macro context + security (Articles 3, 6, 7) Add the Oracle for off-chain signals. Add the Guardian with Tenderly simulation. Configure the Guardian's authority limits. Run for two weeks with the Guardian in monitor-only mode (log blocks but do not prevent execution) to calibrate false positive rates. Duration: 4-6 weeks.

Phase 4: Full autonomy Enable autonomous execution within Guardian-validated parameters. Set DAO governance parameters. Register ERC-8004 identity. Publish Guardian decisions on-chain. Duration: ongoing.

The series in retrospect

Seven weeks, seven technologies, one system.

The point was never to say "AI + blockchain = future." The point was to show that the tools exist today — stable, open-source, production-grade — to build autonomous AI systems that handle on-chain assets with genuine rigour: verifiable reasoning, domain expertise, observable decisions, and an immune system.

Hydra is not a product. It is a blueprint. Take whatever layers are useful. Run the Sentinel alone as a DeFi monitoring dashboard. Run the Analyst as a protocol analysis tool. Use the Guardian's transaction simulation pattern in your own smart wallet.

The stack is open. The code is in the articles.

AI to Web3 series — building Hydra, a sovereign multi-agent DeFi intelligence mesh:

1 — LangChain orchestration · 2 — n8n execution · 3 — RAG at scale · 4 — LLM observability · 5 — Fine-tuning · 6 — Agent swarms · 7 — SOAR · 8 — Production resilience