Trust model
What is verified where, what is trusted, and what a compromise of each part can cost.
Verified on-chain, by the wallet
On every execute, the wallet contract checks, itself:
- the verdict is signed by an allowlisted key, over the exact request and response (EIP-191, recovered with
env::ecrecover); - the request is the firewall core's judge request for this proposal: the owner's current rules hash, the registered prompt hash, the wallet's model, this action's bytes and args;
- the verdict is
ALLOW, and for this action; - the nonce is unused, the action hasn't expired, the receiver is allowlisted, the wallet isn't frozen;
- the payment is within the per-transaction and daily caps;
- for a payment on Base, that 1Click signed the quote, and the quote matches the proposal and pays the listed recipient.
If any check fails, nothing moves. The full list is in the contract reference.
Verified off-chain, once
Attestation is checked off-chain, not by the contract. pnpm attest verifies the model TEE's Intel TDX quote against Intel's certificate chain, checks that the quote binds the signing address and a fresh nonce, and checks NVIDIA's signed GPU attestation. Only then does the owner allowlist the signer.
It doesn't compare the attested app image with a known-good one (none is published), and it trusts NVIDIA's signing keys as served over TLS. Reports are published in docs/attestations/.
Trusted
- The model can be wrong. Whatever the agent read, such as a paywall's response, is attacker-controlled, and an attacker can keep rewording it until the model slips. The red-team numbers are our own 83 cases, not an adaptive attacker. The wallet's caps limit what one wrong
ALLOWcan cost; the model can only tighten what the contract permits, never loosen it. - 1Click is trusted to deliver. The wallet verifies that 1Click signed the quote, but it can't prove that 1Click then delivers on Base. On testnet a stand-in plays 1Click, and every delivery it reports is labelled simulated.
- NEAR AI Cloud's TEE is trusted to keep the signing key inside the enclave, as its attestation says.
What each part holds, and what it can do if compromised
| Part | Holds | If compromised |
|---|---|---|
| The agent | a function-call key on its wallet, limited to propose and execute, with a gas allowance | can propose anything, but can't move funds without an ALLOW. Can re-propose until the model slips: 30 verdicts per wallet per hour, and no more than the API's daily cap where it's set. Each wrong ALLOW is still within the caps. The owner freezes the wallet or removes the key |
| The Intented API | the NEAR AI key and the 1Click JWT; no NEAR key | can refuse to judge. Can't make the wallet pay: it can't sign a verdict with the allowlisted TEE key, and it never sends a transaction |
| The web app | nothing; the owner signs with their own wallet | can show wrong information. Every verdict can be checked from the chain alone |
| The owner's NEAR account | owner rights on the wallet | everything: withdraw, change the rules, raise the caps. Guard it like the funds |
| The wallet account's full-access key | the account itself | can replace the contract and bypass every check. Wallets made by the factory have none. For intented-wallet.testnet, the team holds it |
Untrusted data is data
The paywall's response, tool output and anything else the agent read go into the judge's prompt quoted, as data, never as instructions. The verdict is structured JSON; anything that fails parsing is a DENY.