The Problem with Autonomous Agents

AI agents now control wallets and execute DeFi transactions independently. They swap tokens, manage positions, and interact with protocols without human intervention. But there's a critical gap: no security oversight between the agent's decision and the on-chain execution.

A compromised agent, whether through prompt injection, hallucinated addresses, or malicious instructions, can drain funds irreversibly. There's no firewall. No review layer. No "are you sure?" before the transaction hits the chain.

ENShell exists to fill that gap.

An On-Chain Firewall

ENShell is an on-chain firewall that sits between AI agents and the blockchain. Every transaction is encrypted, analyzed by Claude via Chainlink CRE, and scored for threats before it ever touches the chain. Suspicious actions get escalated to a human for approval.

The core flow is three steps: Encrypt. Analyze. Decide.

Four-Layer Architecture

We built ENShell as four distinct layers, each with a clear responsibility:

Layer 1: SDK and CLI

The entry point. The protect() function in the SDK encrypts agent instructions using ECDH key exchange on secp256k1 with AES-256-GCM, then submits action hashes on-chain. The CLI handles agent registration, policy management, and manual approvals.

Both are available on npm: @enshell/sdk and @enshell/cli.

Layer 2: Smart Contract

Policy validation, action queuing, and event emission. The contract receives encrypted action hashes and manages the lifecycle of each transaction request. It's deployed on Sepolia and fully verifiable.

This is where the analysis happens. Chainlink's Compute Runtime Environment retrieves the encrypted instructions, decrypts them inside its confidential environment, and runs them through Claude for threat analysis. Claude checks for address patterns, prompt injection attempts, value anomalies, and instruction-target compliance.

The verdict is written on-chain via onReport(). The critical safeguard: instruction plaintext never appears on-chain. It only exists inside the CRE's confidential environment.

Layer 4: Human-in-the-Loop

When the analysis flags a suspicious action, it gets escalated. The agent owner can approve or reject through the CLI or through Ledger Live with ERC-7730 clear-signing. Hardware wallet approval means even if the software stack is compromised, a human with physical access to the Ledger must confirm.

Identity and Reputation via ENS

Every agent registered with ENShell receives an ENS subdomain under enshell.eth. The agent's threat score, calculated using an exponential moving average (EMA), is stored as an ENS text record. Other agents can query this score on-chain to verify trustworthiness before interacting.

This creates a Trust Mesh: a network of agents that verify each other's reputation on-chain before executing collaborative transactions.

Why These Three Protocols

The architecture rests on three protocol integrations, each chosen for a specific reason:

Chainlink CRE handles the confidential analysis. We needed off-chain computation with on-chain trust guarantees. The CRE lets us run Claude on encrypted data without ever exposing the plaintext on-chain.

ENS provides decentralized identity. Agent subdomains, reputation scores, and metadata are stored on infrastructure that no single entity controls.

Ledger enables secure human approval. When an agent action is escalated, the hardware wallet ensures the approval is physical, not just digital.

What We Learned Building It

ENShell was built in 36 hours at EthGlobal Cannes 2026 and won the Chainlink CRE prize. The biggest challenge was working with Chainlink CRE's runtime environment, which lacks traditional JavaScript support. Cryptographic operations that are trivial in Node.js required creative workarounds inside the CRE.

The second lesson: existing infrastructure is your best friend at a hackathon. Chainlink, ENS, and Ledger each saved us weeks of development by providing battle-tested primitives we could compose.

ENShell is live at enshell.xyz.