Ledger Agent Firewall

An AI agent processing an invoice will read whatever is in that invoice — including instructions hidden inside it. A poisoned document can redirect a payment to an attacker's address, and the agent will produce a perfectly well-formed transaction for it. The model is the vulnerability, so the model cannot also be the check.

Treasury agents are being deployed right now on the assumption that the model will behave. That assumption fails on the first adversarial invoice. The fix has to sit outside the model, at the hardware boundary.

A verification gate between agent output and hardware signing. The user's stated intent is captured first. The invoice is scanned separately. The AI-produced transaction is then compared deterministically against the original intent — not by another model, by code — and the difference drives a risk decision. Only transactions that survive that comparison reach the Ledger signing gate, where the device's trusted display shows the user what they are actually signing.

1. 01User intent captured
2. 02Invoice scanned
3. 03AI produces a transaction
4. 04Deterministic comparison against original intent
5. 05Risk decision
6. 06Ledger signing gate — trusted display confirms

• Security architecture and threat model
• Deterministic comparison engine
• Ledger DMK and Speculos integration
• API design with OpenAPI and Zod validation
• Full frontend

• Gemini
• Ledger DMK
• Speculos
• TypeScript
• React
• Vite
• Express
• OpenAPI
• Zod

The comparison layer cannot use an LLM — that would reintroduce the exact vulnerability it exists to close. Everything had to reduce to deterministic checks over structured transaction fields, which means the parsing has to be exhaustive rather than clever.

Hardware wallets already solve this problem; the industry just stopped routing decisions through them. The trusted display is the last surface an attacker cannot reach, and any agent architecture that bypasses it is trusting the wrong component.