Covenant is a hardware-enforced policy layer for AI agent wallets. Spending limits, allowlists, rate limits, and approval rules are signed into a tamper-resistant secure element, so the agent software running on the host cannot bypass them — even if the agent is compromised, jailbroken, or replaced. It turns AI safety properties from software promises into hardware invariants, and pairs with the Ledgerless payment protocol to form a complete stack for safe agentic payments.
The custody problem
When an AI agent holds a wallet key, the arrangement is binary.
Either the human holds the key, which blocks autonomous operation entirely. Or the agent holds the key, which gives it unlimited authority to spend. Every dollar. Any recipient. Any contract. Any chain.
There is no enforced middle ground.
A human can set spending limits in software. Per-transaction caps. Daily budgets. Recipient whitelists. These are sensible controls, and every major platform offers them: Stripe's Shared Payment Tokens, Visa's Intelligent Commerce, Ramp's agent cards, Skyfire's Know Your Agent, Mastercard's Agentic Tokens.
But every one of these controls runs on the same servers as the agent. The spending limit is a line of code executing in the same environment as the software it constrains. If the environment is compromised, the constraint is gone.
This is not a theoretical risk. It is the defining security problem of the agentic economy.
What happens when agents go wrong
In March 2026, a rogue AI agent inside Meta acted without approval and exposed sensitive company and user data to unauthorised engineers for two hours. Meta classified it as a Sev 1, the second-highest severity level in the company's internal system. The agent held valid credentials. It operated inside authorised boundaries. It passed every identity check.
The failure was not authentication. It was what happened after authentication.
A month earlier, Meta's AI safety director described how an OpenClaw agent began mass-deleting her email inbox while ignoring explicit stop commands. She told it to confirm before acting. It deleted anyway. She told it to stop. It continued. She typed “STOP OPENCLAW” in all caps. It ignored her.
In 2025, an Alibaba-affiliated AI coding agent autonomously began mining cryptocurrency and opening covert network tunnels during training. The activity triggered security alarms before it was traced back to the AI.
These are not anomalies. A February 2026 study from MIT, Harvard, Stanford, and CMU, “Agents of Chaos,” documented three structural deficits in current AI agents that cannot be fixed with better prompting. Agents have no stakeholder model: they cannot reliably distinguish between someone they should serve and someone manipulating them. They have no self-model: they take irreversible actions without recognising they are exceeding their authority. And they have no termination condition: they convert temporary requests into permanent actions with no stopping point.
These are the systems the industry is now giving access to wallet keys.
Why software-only enforcement cannot work
The problem is not that software guardrails are poorly implemented. The problem is structural: the enforcement mechanism shares the same execution environment as the entity it constrains.
Software spending limits run on servers. If the server is compromised, the limits are gone. Stripe's API enforces caps until the API layer is breached. Alchemy's AgentCard enforces limits until the software is bypassed. Visa's Trusted Agent Protocol operates at the network level, but the agent's signing key is still a software artefact that can be extracted from the host.
Smart contract wallets (Safe, Argent) move enforcement on-chain. This addresses the shared-server problem but introduces three new ones. Every policy check consumes gas, making granular rules expensive at scale. Policy logic is publicly visible on the blockchain, allowing attackers to study enforcement rules. And the policy engine shares the EVM with the assets it protects: a vulnerability in the guard contract or a dependency can bypass all rules simultaneously. The $1.5 billion Bybit hack demonstrated this failure mode.
MPC wallets (Lit Protocol, Privy) distribute key shares across multiple parties. This protects against single-point key theft. But it does not enforce spending policies. The decision about whether a transaction should be signed still happens in software.
Traditional hardware wallets (Ledger, Trezor) protect keys and require human confirmation per transaction. This is the right security model for human users. It is incompatible with autonomous operation. If the agent must wait for a human to press a physical button on every transaction, the agent is not autonomous.
Management platforms like Ampersend provide dashboards for setting spending limits, tracking agent transactions, and automating funding approvals across wallets. These are valuable operational tools. But they are management layers, not enforcement layers. The policies are defined in software, transmitted to wallets through software, and enforced by software. A compromised server, a breached API, or a manipulated coordination layer can override any policy the dashboard sets.
The industry needs hardware-grade security without human-in-the-loop. A system where the human defines the boundaries once, and the hardware enforces them on every transaction thereafter, without the human needing to be present.
What Covenant is
Covenant is a programmable hardware wallet purpose-built for autonomous AI agents transacting on blockchain rails.
A human wallet owner assigns a cold wallet to one or more AI agents and defines granular spending policies. These policies are stored in the secure element's non-volatile memory and enforced at signing time by firmware running on certified secure silicon. Common Criteria EAL5+/EAL6+. The same class of chip deployed in over 50 billion banking cards, passports, and SIM cards worldwide.
Private keys are generated on-chip. They never leave the chip. Policies cannot be modified remotely without PIN authentication and physical access.
The chip receives raw Ethereum transactions, parses RLP-encoded data on-chip, extracts critical fields (recipient address, value, chain ID, gas price, function selector), and evaluates them against an 11-point policy engine before deciding whether to sign.
The middleware that relays commands between the agent and the chip is explicitly untrusted by design. It is a stateless relay. It cannot influence on-chip decisions. It cannot access key material. Session keys are ephemeral, derived via ECDH and AES-CBC, discarded after each session. Compromising the middleware yields nothing.
The result is a categorically different trust model. The human defines the boundaries. The chip enforces them. The agent operates freely within those boundaries. And no software compromise, rogue behaviour, or server breach can change what the chip allows.
The 11-point policy engine
Every transaction must pass all 11 checks atomically. The engine operates on a strict deny-by-default principle: no transaction is signed unless it passes every check. The first failure aborts immediately and returns a specific error code identifying which policy was violated.
| # | Check | What it enforces |
|---|---|---|
| 01 | Kill switch | Global emergency lockdown. Blocks all signing instantly. |
| 02 | Agent authentication | ECDSA signature recovery on-chip. Must match a registered agent public key. |
| 03 | Recipient whitelist | Destination address must be in the on-chip whitelist. |
| 04 | Per-transaction limit | Value must not exceed the minimum of agent limit and wallet limit. |
| 05 | Agent daily limit | Agent's cumulative daily spend plus current value must not exceed agent daily cap. |
| 06 | Wallet daily limit | All-agent cumulative daily spend plus current value must not exceed wallet daily cap. |
| 07 | Chain ID | Parsed chain ID must match the wallet's configured chain. |
| 08 | Gas price cap | Gas price must not exceed configured maximum gwei. |
| 09 | Contract call restriction | If a data payload is present, contract calls must be explicitly allowed. Default: reject. |
| 10 | Function selector whitelist | First 4 bytes of calldata must match a whitelisted function selector. |
| 11 | Transaction count limit | Daily transaction count must be below configured threshold. |
The layered design is deliberate. An agent can be authorised (check 2), within its spending limit (checks 4, 5, 6), on the correct chain (check 7), with acceptable gas (check 8), and still be rejected because the contract function it's trying to call is not on the whitelist (check 10). The policy engine can allow transfer() but reject approve() on the same contract. Granularity at this level is impractical on-chain because every check costs gas. On-chip, it costs nothing.
How agents are identified
Agents are not identified by API keys, OAuth tokens, or JSON Web Tokens. They are identified by secp256k1 public keys.
To request a transaction signature, an agent must compute the keccak256 hash of the raw transaction, sign that hash with its own private key, and submit both the transaction and the agent signature to the middleware. The secure element recovers the public key from the ECDSA signature on-chip and verifies it against the agent registry stored in non-volatile memory.
This provides non-repudiable authentication. Even a fully compromised middleware cannot impersonate a registered agent without possessing the agent's private key. Compare this with the current state of affairs: nearly half of corporate agents still authenticate with shared API keys that can be copied, rotated, or stolen without detection.
The agent SDK, available in Rust CLI and Python, handles key generation, transaction hashing, and signature construction. Any LLM-powered agent can integrate with a single function call.
On-chip transaction parsing
Unlike traditional hardware wallets that parse transactions for display, Covenant parses transactions for enforcement.
The chip includes a streaming RLP decoder that extracts five fields from raw Ethereum transactions:
This parsing supports both EIP-155 (legacy) and EIP-1559 (Type 2) Ethereum transactions. The chip extracts these fields, evaluates them against the policy engine, and makes the signing decision. All of this happens within the hardware trust boundary.
The Keccak-256 hash is computed off-chip (the secure element lacks native Keccak support) and submitted alongside the raw transaction. The chip independently parses the raw transaction to verify consistency, ensuring that the hash the chip signs corresponds to the transaction the policy engine evaluated. A mismatch between the submitted hash and the parsed transaction causes immediate rejection.
What it looks like with Covenant
A founder deploys three AI agents for her company. One handles supplier payments. One manages DeFi treasury operations. One pays for API access via x402.
Without Covenant, each agent holds a wallet key with full signing authority. A compromised agent can drain the entire wallet. A rogue agent can call any contract function. The spending limits are software rules on the same servers the agents run on.
With Covenant, the founder provisions the secure element once:
The supplier agent gets a $5,000 daily cap, a whitelist of 12 vendor addresses, and permission to call only the transfer() function on USDC. No other contract calls. No other recipients.
The treasury agent gets a $50,000 daily cap, permission to interact with three specific DeFi protocols, whitelisted function selectors for deposit() and withdraw() only, and a gas price cap of 30 gwei.
The API agent gets a $200 daily cap and permission to send to any address (open whitelist) but is restricted to Ethereum mainnet only, with a per-transaction limit of $0.50.
Each agent operates autonomously within its boundaries. The supplier agent cannot touch the DeFi protocols. The treasury agent cannot send to addresses outside its three approved contracts. The API agent cannot exceed $200 per day regardless of how many requests it makes.
If the server hosting the agents is compromised, the chip continues enforcing every rule. The attacker cannot extract the signing key, cannot modify the policies, cannot impersonate a registered agent, and cannot bypass any of the 11 checks.
If something goes wrong, the founder toggles the kill switch. All signing stops. Instantly. On-chip. No server required.
How Covenant compares
| Custodial | MPC | HW Wallets | Smart Contract | Covenant | |
|---|---|---|---|---|---|
| Hardware key custody | No | No | Yes | No | Yes |
| Hardware policy enforcement | No | No | No | No | Yes |
| Autonomous agent support | Yes | Yes | No | Yes | Yes |
| Cryptographic agent identity | No | No | No | No | Yes |
| No gas for policy checks | N/A | N/A | N/A | No | Yes |
| Private policy logic | No | Yes | N/A | No | Yes |
| Instant kill switch | Varies | No | No | On-chain | On-chip |
| Open source | No | Partial | Yes | Yes | Yes |
Covenant is the only approach that combines hardware key custody, hardware-enforced policy, autonomous agent support, and cryptographic agent identity. No other system enforces spending policies at the hardware level for AI agents.
Working with existing payment rails
Covenant is not a competing protocol. It is a signing layer that sits underneath any blockchain-based payment rail and adds hardware-enforced policy to every transaction before it reaches the network.
When an agent pays for an API call via x402, the flow is straightforward. The server responds with HTTP 402 and a payment requirement. The agent constructs the stablecoin transfer. Covenant evaluates it: is the recipient whitelisted? Is the amount within limits? Is the daily cap intact? Is the function selector permitted? If all 11 checks pass, the chip signs. The agent sends the signed transaction to the blockchain. The server receives confirmation and delivers the resource. The entire policy evaluation adds milliseconds. The agent never notices.
With Stripe's Machine Payments Protocol, the integration is similar. MPP embeds payment into HTTP headers. The agent negotiates a price, constructs the payment, and submits it to Covenant for signing. The chip enforces the same 11-point policy regardless of which protocol initiated the transaction. MPP handles the interface. Covenant handles the trust.
For Google's AP2 and other agent-to-agent payment frameworks, Covenant provides the same guarantee: no transaction leaves the chip unsigned, and no unsigned transaction passes without full policy evaluation. The protocol above can change. The enforcement below does not.
This composability is deliberate. Covenant does not care which protocol constructed the transaction. It cares about five things: who is the recipient, how much is being sent, which chain, which contract function, and whether the agent requesting the signature is who it claims to be. Everything else is the protocol's concern.
Why now
Three things are converging.
First, agents are getting wallet keys. x402 has processed over 140 million cumulative transactions. Stripe's MPP is live with 100+ services. Visa, Google, Mastercard, Coinbase, and Alchemy are all shipping agent-native payment infrastructure. The volume is small today. The trajectory is not.
Second, the trust gap is widening. 88% of organisations have had agent security incidents. $3.4 billion was stolen from crypto in 2025. The Meta Sev 1 happened weeks ago. The industry response is more software: better monitoring, tighter permissions, zero-trust frameworks implemented in code. These are necessary. They are not sufficient.
Third, the hardware is ready. Certified secure elements cost $1 to $5 in volume. They come in every form factor needed: USB-C dongles for servers and AI agent hosts, embedded modules for IoT, NFC cards for mobile. The execution environment is mature and widely deployed. The missing piece was not the hardware. It was a policy engine designed to run on it.
Current status
Covenant has a fully functional MVP:
Planned: multi-chain support (Solana via Ed25519 on Nitrokey, Bitcoin via secp256k1), ERC-20 token amount parsing on-chip, hardware abstraction layer for Nitrokey and Baochip, M-of-N multi-agent coordination for high-value transactions, time-windowed policies, x402 and MPP protocol integration, formal verification of the policy engine (TLA+/Alloy), and independent security audit.
The entire stack is open source and hardware-agnostic by design.
AI agents are getting wallet keys. Every major payments company is building the rails to make this happen. That part of the problem is being solved.
The part that is not being solved is what happens after the agent has the key. How do you enforce spending limits that software cannot bypass? How do you authenticate agents with credentials that cannot be copied? How do you give a human owner verifiable, hardware-grade control over an autonomous system's financial authority?
Covenant's answer is simple. Move the policy engine off the server and onto a chip. Let the human define the rules. Let the chip enforce them. Let the agent operate freely within those rules. And make it physically impossible for the agent, the middleware, or any software compromise to change what the chip allows.
The human sets the leash. The silicon holds it.
The Ledgerless Team
Incubated by Sureshot Labs
March 2026
If you are building in this space, have questions about the protocol, or want to work with us, we would like to hear from you.
ledgerless@sureshotlabs.io