How I built an agentic safety layer for natural-language wallet transactions

This project is intentionally technical. It shows that I can explain complex AI opportunities to executives, but also design and build the underlying architecture when the domain has real risk. The problem I chose is hard: agents that move assets on-chain from natural-language instructions.

The commercial story is clear: wallets and crypto apps need simpler UX. The engineering reality is harsher: transactions are irreversible, gas-sensitive and exposed to prompt injection, ambiguous intent and user mistakes. I built the project to show both sides together: product narrative, architecture, implementation and evaluation.

The research question behind the project is whether a multi-agent system can reduce unwanted or unsafe token transfers while preserving a usable natural-language interface. That tension is the point: too much autonomy is dangerous, too much friction kills the experience.

I scoped the project around token-to-token transfers where the destination is assumed to be known and trusted. That kept the focus on the critical path: understanding how much, which token, when, under what conditions and whether execution is safe.

The decisive architectural choice is the boundary between probabilistic reasoning and deterministic authorization. The LLM can classify intent and propose transaction parameters, but policy, risk and final authorization are handled by separate engines.

That boundary matters because prompt injection should not become financial authorization. Even if an LLM is confused, manipulated or overly helpful, it cannot bypass token whitelists, amount limits, daily caps, frequency constraints or risk thresholds.

The repository is not a static concept deck. It includes the technical structure, the research framing, implementation modules, test strategy and a development plan for hardening the codebase after analysis.

The engineering plan covers data integrity, configuration wiring, RPC setup, async Web3 correctness, dead-code cleanup, type safety and adversarial test improvements. That is the part I want visible: I am comfortable moving from strategy to the messy engineering details that decide whether an AI system is trustworthy.

For this type of system, a successful transaction is not enough evidence. The relevant question is what happens when the instruction is ambiguous, hostile, too expensive, too frequent or outside the user policy.

The project evaluates prompt injection, policy bypass attempts, risky destinations, gas conditions and confirmation paths. I also document limits clearly: testnet-first, no broad mainnet claim, and no claim that application guardrails replace full wallet, network or operational security.