Inspiration

AI agents are getting closer to making real purchases for users, but their spending limits are usually enforced by the same backend that executes the payment. If an agent is prompt-injected or misled, the user has to trust that the app server will still say no. Leash was inspired by a simple question: what if the AI could make a payment request, but only a smart contract could decide whether that request is authorized?

What It Does

Leash is a programmable spending firewall for AI agents. A user creates an on-chain mandate with:

  • Session key
  • Merchant allowlist
  • Cumulative cap
  • Expiry
  • Revocation state The AI agent can interpret chat and attempt payments, but every payment must pass through the LeashMandate contract.
  • If the request is valid: The contract emits AuthorizationGranted, and the backend mock settlement can run.
  • If the request is invalid: The target is not allowed, the amount exceeds the cap, the mandate is expired, or the mandate is revoked, the transaction reverts and no settlement is eligible.

How We Built It

  • Enforcement Layer (Solidity): Written in Solidity with Foundry tests covering the full refusal vocabulary: invalid mandate, wrong signer, revoked, expired, target not allowed, amount over cap, duplicate mandate, and zero amount.
  • Application Layer (TypeScript): Built with Next.js for the frontend, a confirmed-block backend listener, a demo runner, and a Telegram bot. The Telegram bot supports direct commands and natural-language payment intent parsing. English AI chat is converted into structured intents, but the AI never approves or settles anything. It only supplies the target and amount to the payment client, while the smart contract remains the final authority.

Challenges We Ran Into

  • Keeping the Security Boundary Honest: The hardest design challenge was keeping the security boundary honest. It is tempting to add backend checks for allowlists, caps, or prompt-injection filtering, but that would weaken the demo. We deliberately let the off-chain agent be manipulable to prove that the smart contract can still refuse.
  • Authorization vs. Settlement: Explaining the distinction between authorization and settlement. Leash does not move fiat on-chain; it puts spending authority on-chain, then lets a conforming backend settle only after a confirmed AuthorizationGranted event.

Accomplishments That We're Proud Of

  • Real Enforcement Demo: The core demo is not just a UI mock. The contract successfully:
    • Accepts valid payments for Rock Burger.
    • Refuses Evil Store with TargetNotAllowed.
    • Refuses overspending with AmountExceedsCap.
    • Refuses post-revocation attempts with Revoked.
    • Emits zero authorization logs for rejected attempts.
  • Integrated Ecosystem: Built a complete path around the contract: frontend, Telegram interface, simulated browsing attack, backend listener, mock BaaS settlement, and automated tests proving that only confirmed authorization events can trigger settlement.

What We Learned

  1. The Cleanest Way to Secure AI Spending: It is not by making the AI more trusted, but by making the AI less authoritative. Natural language is useful for capturing intent, but authorization should be deterministic, inspectable, and outside the agent's reach.
  2. A Strong Demo Must Show Refusal: Showing an AI agent successfully buying lunch is common. Leash demonstrates what happens when the agent tries to do the wrong thing.

What's Next for Leash

  • Real Payment Provider Integration: Move from mock settlement to real payment provider integration, where the provider verifies on-chain authorization before issuing or charging a virtual card.
  • System Feature Enhancements:
    • Persistent backend idempotency.
    • Production key custody.
    • Richer merchant identity.
    • Gas abstraction.
    • Stronger agent workflows with clearer human approval surfaces.

Built With

Share this project:

Updates

Submission history