ENShell Prevents AI agents from executing malicious transactions caused by prompt injection attacks.
IMPORTANT: BELOW I HAD TO REMOVE TWO OF MY REPOS BECAUSE THE FORM IS LIMITED TO 5. ALL MY REPOS ARE OF COURSE IMPORTANT SO PLEASE CONSULT THE ORGANIZATION. I MADE ONE JUST FOR THIS PROJECT BECAUSE I KNEW I WOULD HAVE MANY COMPONENTS. I REMOVED THE SITE (DASHBOARD AND DOCUMENTATION) AND THE RELAY SERVER.
ENShell is an on-chain firewall that sits between AI agent intent and blockchain execution. Every action an autonomous agent wants to take (swapping tokens, bridging assets, interacting with DeFi) passes through a four-layer security pipeline before a single wei moves.
Layer 1 : Encrypt: The SDK's protect() method encrypts the agent's instruction using ECIES (secp256k1 ECDH + AES-256-GCM) with the oracle's public key, stores the encrypted payload on a relay, and submits only the instruction's keccak256 hash on-chain. The plaintext never touches the blockchain.
Layer 2 : Queue: The AgentFirewall smart contract (deployed on Sepolia) verifies the agent exists, is active, and hasn't exceeded its strike limit. It queues the action and emits an ActionSubmitted event containing the hash, target address, and value.
Layer 3 : Analyze: A Chainlink CRE workflow picks up the event, fetches the encrypted payload from the relay, decrypts it using the oracle's private key (threshold-encrypted in Chainlink's Vault DON), and sends the plaintext to Claude via Confidential HTTP for threat analysis. Claude scores the action 0–100,000 and assigns a decision: approve (routine DeFi), escalate (suspicious patterns), or block (prompt injection, burn addresses). The verdict is DON-signed and written back to the contract through the real Chainlink KeystoneForwarder on Sepolia (thanks to --broadcast).
Layer 4 : Human-in-the-Loop. If escalated, the CLI displays Claude's full analysis (score, reasoning, target, value) and prompts the agent owner to approve or reject. Ledger Live provides the same flow with hardware wallet signing and ERC-7730 clear-signing descriptors showing human-readable transaction details on-device (tho it was not possible to integrate it into production, but the file exists and it passes the Lint, so I still consider it as if i would be in production, just like with the limitations of CRE in testnet).
At the root of it all is the SDK that would allow devs to make use of these layers into their code to protect their TX. Traditionally, dev who code agents makes them create a Transaction object from a prompt. Then this prompt, which lives only in memory, is never really consumed, analyzed and reasoned about. Its just directly broadcasted. This is where my project sits ... in between with the SDK giving simple functions exposing conditionals to wrap the broadcasting on chain in a clever condition doing a serious evaluation of the generated TX + the prompt that did it.
Built on top the SDK is the CLI that dev and operators can use to register agent, freeze them, list them, etc. Normal flow is user will install the CLI to register agent by an identifier and a wallet. Then we will give it a ENS subdomain of enshell.eth. This is the core of the project because the TRUST SCORE and STRIKES of an agent lives in the ENS TXT records. And the concept is very organic, ENS is the Web3 identity layer, easy to use and accessible in the whole ecosystem. Anyone could fetch these informations. What makes this special, is those records can only be updated by the ChainLink CRE final forwarding call. Meaning nobody, not even me or the agent owner or the bot itself can edit those fields. Only the ChainLink CRE.
There is also a compagnon Leger Live application that lives in the ledger desktop app which gives a nice UI to register client, freeze them in one click and see your fleet of agents. My idea is that the ideal way to be a bot operator is with a hardware wallet controlling them with ease. That was my main decision behind that.
i have built a live dashboard accessible at https://enshell.xyz where the detections are monitored in direct without refresh. You can open each one to view the LLM reasoning for the score and decision it gave. From the site you can also see the list of all registered agents in our smart contract with their score and strikes. And below is the trust mesh which is a visual representation of agent attesting each other's score.
Because one of the fundamental goals is to be able to dialogue (Defi) with other agents without issue. We now have LLM doing social engenering on other agent to trick them into nasty transactions. How do you protect against those? The idea is because of our ENS integration it becomes universal and easy for anyone that wanna check the trust score of an agent and people could require that their bot only talks to agents with a certain threshold score to maintain security. So the mesh represents this idea visually. The line and animation represents the agents that tested the trust of others. With the SDK this would be translated into a simple "if" statement.
Also i made the project with the idea to be fully open source from start. People can choose to be apart of the shared collective of agent reputation system or they can fork and have their own private fleet monitoring. I can even imagine something that people would not necessary wanna share that much about their agents so each one having their private bubbles but then having something connecting those bubbles together with ZK. Like without sharing everything, you can know easily if its trusted or not depending on personal threshold. Anyway ... for another project haha.
To begin, something i am proud is the GitHub organization. I made one for the project because I have a lot of moving pieces, technologies and at various levels. I made sure to made it clear for everyone to consult and bootstrap any of the repos. The org is there : https://github.com/0xenshell.
The repos are :
Also on the website you will find the full documentation of the project (https://enshell.xyz/getting-started/introduction/). It has the whole technical details you could imagine. So I will mention the big things in here.
ChainLink CRE which is fairly recent was a bit hard for me to integrate. It works flawlessly once we get it tho. I had difficulties passing from traditionnal typescript with nodejs to their CRE environnement which has limitations on ported packages because they compile the TS in WebAssembly. My project required encryption so i had to find alternatives (which are pure JS without dependencies). I spoke to the wonderful people at the ChainLink booth and i gave them a complete rundown in details of what happened. Also just writing the code in CRE somehow even the AI had trouble even with the skills haha but i dont mind much it was one of the highlights for me this year to have to go deep in cryptography manually and having to decode base64 hashes :P
ENS was tricky because I am not using it normally. I needed to make sure that it IS impossible, not even the contract owner, to change the text records. So I had to play with the namewrapping and also the ERC1155 Receiver. Took quite some time, but super happy with the result.
Maybe something interesting is my documentation site, well the whole site in fact is made in PHP with Zephyrus (which is a framework i did myself and is open source). With Zephyrus I made "Leaf" which is the equivalent of RETYPE but fully free and open source. You write the documentation in markdown and it has a hot reload to see live the result and when you are ready you build the static version of the site that you can deploy on GitHubPages for free for example. So if you like the style and wanna use that for docs ... its made to be easy for agent to update the visual palette thanks to TailWind and content is pure markdown. (https://github.com/zephyrus-framework/leaf). also what is nice compared to thing like RETYPE that are normally STUCK into a document view, well with Leaf you can do your own landing and any number of static pages you want that can have a custom look. So yeah the whole site of ENShell was done with that as the framework.
CLI and SDK are classic typescript with the classic Web3 libraries you would expect.
I have a single contract and its normal solidity stuff besides the things I had to do for ENS and CRE flow.
Something worth mentioning is how the demo was made for judges was made. I deployed and funded a bunch of addresses which they all have a set of agents under their care. I registered all of them and i prepared a loop script (available in the contract repo). This script does the real flow of event and does realistic prompt validations. Everything you see is real and on the blockchain passing through CRE each time. I let the thing run for hours and hours to see if there were some issues or caching problems. Everything went fine. I can also configure the speed at which we have new detection coming.

