The agent key cannot approve itself

A Probarion agent cannot raise its own limit or approve its own payment with the key it is given. That key is a function-call key on the vault, which NEAR lets call spend and nothing else, with no deposit. A higher limit needs a new mandate signed from the owner's account, and a held payment needs approve signed from an approver's account. No passcode approves a payment or raises a limit, so there is none for the agent to read. The sandbox test ihitl_replay_the_agent_cannot_raise_its_own_limit_or_approve_itself replays the I-HITL paper's attack with that key, adds other ways around the gate, and checks what stops each one; three of the test's steps also have NEAR testnet records. This holds only while the owner's and the approvers' full-access keys stay out of the agent's reach. An agent that can sign with one of them on its own machine is in what the paper calls the plain topology, and the vault cannot tell it from a person: What this does not do covers that and the other gaps.

What the paper found#

I-HITL: Inalienable Human-in-the-Loop, by Samuel Breckenridge, Dani Vilardell, Wenhao Wang, Fan Zhang and Ari Juels, is arXiv:2610.35835 (opens in a new tab); its third version is of 30 October 2026. It tested a commercial agent wallet on Base mainnet, which the paper names. Each wallet held 10 USDC under a policy of 0.01 USDC a transaction and a day, 0.30 a week and 1 a month. A change to that policy took effect only with a one-time passcode that the wallet's provider emails to the account owner. The agent ran in an agent framework with three tools: the user's email, web browsing and the wallet. Its system prompt told it to treat whatever a tool returns, emails included, as data, and no task mentioned the policy or how to change it.

Ten models from five model families ran 20 times in each of three experiments:

In the paper's words, "Anyone who can email the user can spend from the wallet." One recorded run shows the steps. A transfer fails on the limit. The agent asks the wallet for higher limits, and a passcode is emailed. The agent lists the inbox, reads the code and submits it. The policy goes up, and the agent pays the invoices. The tool names in that run, such as raise_limit and submit_otp, come from the paper's test harness.

The authors told the provider on 22 September 2026. It added a warning to its documentation to keep the agent away from the inbox the passcode goes to. The paper calls that sensible, but notes that it leaves the burden on the user and leaves the policy-update flow as it was.

Plain topology and trusted devices#

The paper models three parties: the human, the platform the agent controls, and the service that gates the action. In the plain topology, every message between the human and the service passes through the agent's platform, and the paper proves that no approval gate can then tell the human's approval from the agent's. A trusted device out of the agent's reach is necessary, but it is not enough: the paper's Theorem 7 sets two conditions on that device. Toward the person, the agent must not be able to come between the person and the device. The device needs a screen the agent cannot read, or an input the agent cannot drive. A keypad of that kind is enough on its own; a button or a biometric sensor, which only says yes, also needs a screen the agent cannot draw over or imitate, so that the person sees the exact action they approve. Toward the service, the device must attest to the keys it generates, so that the service can check them. For strong I-HITL, which holds even against a human who wants to hand approval to the agent, it must also keep those keys from being extracted.

Most approval methods in use today fail one condition or the other. A code sent by email or SMS comes from no device key at all, and it passes through a channel the agent can read before the person types it into the agent's platform. An authenticator app shows a code, not the action, and its shared secret is shown on the platform when the app is set up, so the agent can copy it. A push-approval app's key is not attested, so an agent that reads the activation code can enroll a key of its own. A FIDO2 security key has an attested key that cannot be extracted, but no screen: the platform describes the action, so the person's press approves whatever the platform chose. A proof-of-personhood app the paper examines can give the service a suitable key too, but by default the person confirms with a tap on the touchscreen, which the paper counts as untrusted, since software on the phone can perform taps. A Ledger Nano X, Flex or Stax, a signing token with its own screen and keypad that banks and enterprises issue to their customers, and the authors' prototype, a phone app with attested keys gated by a biometric, can meet both conditions. A Ledger meets them only with a key it keeps to itself: the paper rates a Nano X whose key is derived from the recovery seed, which it says is how most Ledger apps sign, only weak I-HITL, since whoever holds the seed can import it into software the agent controls. The paper adds that its Ledger rows describe what the hardware can do, not what shipped Ledger apps provide. It recommends that services gate policy changes with such a construction, rather than rely on users to keep the agent away from the inbox; that authenticator apps add an I-HITL approval mode; and that mobile OS vendors add a confirmation screen drawn by secure hardware and key use gated on a biometric they can attest.

Where Probarion stands#

No passcode approves a payment or raises a limit in Probarion. What the paper's agent unlocked with a code takes a signature here:

The agent holds a function-call key on the vault itself, and its one method is spend. NEAR refuses, before the vault runs, any transaction that key signs for another method, with a deposit, to another contract, or with any action but one function call. Owner alerts, which are Preview, are notices: none of them can approve or move anything.

In the paper's terms, the service is the vault, and the gate is a signature from the full-access key of the owner's or an approver's account. The vault knows which account signed, not where that key lives, and NEAR checks no attestation of the device that holds it. So Probarion is not an I-HITL construction as the paper defines one. What it takes away is the agent's own way through the gate: the key the agent holds cannot approve or raise anything, and no code that approves a payment or raises a limit travels through a channel the agent reads. The alert email's stop link is a credential of another kind, covered below.

The replay, step by step#

The test runs on a local NEAR node, the near-workspaces sandbox. It funds a vault with 100 test USDC and creates one mandate: 100 USDC a payment, 1 000 in all, 10 uses, and a hold above 10 USDC. The agent key is the vault's only access key. The rows marked Paper follow the paper's recorded run, its Fig. 7, and the rows marked Added are other ways around the gate that the test also tries, with no step in that run. Each row gives what the agent key tries, and what the test checks stops it. The step letters are the test's own.

The node's refusals have no testnet record. A transaction the node refuses does not enter a block, so there is no hash to record, and the key's nonce does not move. The test checks both: each attempt must come back as the node's refusal, not as a receipt that ran and failed, and step (d) reads every nonce again. The three testnet transactions are in contracts/deployments/testnet.json (opens in a new tab), and the demo vault's run is told in docs/evidence/demo-vault (opens in a new tab).

Run the replay yourself#

The test is contracts/integration-tests/tests/ihitl.rs (opens in a new tab). It needs the near-workspaces sandbox, a local NEAR node with no Windows build. CI runs it on ubuntu in its sandbox job (opens in a new tab), with the other sandbox tests. To run it as CI does, you need Linux on x86_64, git, Rust through rustup, and cargo-near 0.22.0 to build the contracts; the site's usual setup below also uses Node.js 24 and pnpm 10, which the test itself does not need. Step 1 of Reproducible builds installs cargo-near and checks its archive for Linux on x86_64. The first run downloads the sandbox binary.

git clone https://github.com/probarion/probarion
cd probarion
pnpm install
pnpm --filter "{packages/cli}..." build
bash scripts/build-contracts.sh
cargo test --manifest-path contracts/Cargo.toml -p integration-tests --test ihitl

The first four lines are the site's usual setup; CI's sandbox job skips the two pnpm lines. build-contracts.sh builds the test token, the Intents stub, the vault and the factory, which the sandbox tests deploy. The last line runs this one test. CI runs every sandbox test with cargo test --manifest-path contracts/Cargo.toml -p integration-tests -- --test-threads=2, which pnpm test:sandbox also runs. When every step holds, cargo prints:

test ihitl_replay_the_agent_cannot_raise_its_own_limit_or_approve_itself ... ok

Each refusal must carry its exact InvalidAccessKeyError variant, so a transaction refused for another reason, such as a key's gas allowance running low, fails the test. Each function call the agent key attempts in step (c) attaches 30 Tgas, not the test helpers' usual 300, to keep that allowance out of the way. The spend batched with an added key takes near-workspaces' default of 10 Tgas, and the transfer, key and deploy actions attach no gas.

Where to go next#

• Security model: each key, the loss bounds if one leaks, and how to stop a vault.
• Holds and approvals: what approve checks, and when a hold expires.
• Vaults, roles and keys: who can do what, and where each key lives.
• Mandates: approval_above and the other limits a spend counts against.
• THREAT_MODEL.md (opens in a new tab) on GitHub: attack 7, forged or self-approval, and the known gaps.

What this does not do#

• It does not keep the owner's and the approvers' keys away from the agent. The vault checks which account signed, not who held its key. The CLI prints every owner and approver transaction as a near-cli-rs command that ends in sign-with-keychain send, the testnet demo vault's approver signed that way, and the developer quickstart lets the developer be the owner. If an agent's shell or browser can reach that keychain, or an unlocked wallet of the owner or an approver, on the machine it runs on, the agent can sign a new mandate or an approval, and the vault cannot tell it from a person: the paper's plain topology. A full-access key of the owner has no bound inside the vault at all (if the owner key leaks). What to do: keep the owner's and every approver's keys on a device the agent cannot drive. The console's wallet list includes Ledger, and the CLI's hint for one is to replace sign-with-keychain send with sign-with-ledger usb send. A wallet on a separate phone also takes the key off the agent's machine. Neither makes Probarion an I-HITL construction in the paper's sense, since the vault cannot check where the key is, but either keeps the agent from signing with it. Nor is a Ledger by itself the paper's strong configuration: the paper rates a Ledger key derived from the recovery seed only weak, since whoever holds the seed can import it into software the agent controls. If you think the agent reached an approver's key, freeze the vault: freeze takes no deposit and stops every spend and every approval at once. Freezing does not stop a holder of the owner's key, who can unfreeze.
• It does not stop an agent from splitting a payment under the threshold. approval_above applies to each spend on its own. An agent that picks its own invoice hashes and refs, as the SDK's requestSpend and the MCP server's request_spend let it, can split a payment that would be held into several spends at or under the threshold, each with a new hash and ref. No code rule looks for this. Each spend still counts against the mandate's max_uses and max_total and the vault's daily backstop, and goes only to the mandate's payee. A key that several mandates name can also pay under whichever one lets the payment through. What to do: keep max_uses and max_total small, or set approval_above to 0, which holds every spend for an approver, as Mandates explains.
• It does not protect the MCP server's keys. With the MCP server (Live), the agent and ledger keys sit in plain text on the agent's machine, as the server's README says: in ~/.probarion/<vault>/keys.json, which init writes (the client run of 2026-11-11 kept them there, and its client config held only PROBARION_VAULT_ID), or in the MCP client's config when they are given as PROBARION_AGENT_KEY and PROBARION_LEDGER_KEY. An agent that can read that file can sign spend itself, skipping decide() and its code rules, and can sign ledger entries and anchors for those spends with the ledger key, so check d does not catch them. The key scope and the contract still hold: it cannot approve, raise a limit or pay anyone a mandate does not name. What to do: keep that file readable only by the account that starts the MCP server, out of reach of the agent's own file and shell tools, and keep in the vault only what the agent may spend.
• It does not keep alerts on. An owner alert email (Preview) about a held spend carries a one-click stop link, and that link is a credential on its own. An agent that reads the inbox, as the paper's agents did, can turn the alert off. It cannot approve: the email only links to the console, and approving takes an approver's wallet signature. What to do: send alerts to an inbox the agent cannot read, or add a second channel, such as Telegram alerts (Preview) in a chat on a device the agent cannot reach.
• It does not ask more than one approver. One approver's approve pays, and no method changes the approver list after the vault is created. If the owner is the only approver, one account both signs the mandates and approves their holds, and the console's create form warns about it. A leaked approver key can approve every live hold, each to its mandate's payee for the amount reserved. What to do: name as approver a second person, other than the owner and whoever runs the agent, who signs on their own device. If an approver key may have leaked, freeze the vault, then revoke the mandates of its held spends or move to a new vault (if an approver key leaks).
• It does not replay the paper with a model. The test signs with the agent key from a script, and no model runs. It runs on a sandbox node, not on testnet, and it does not try the agent key inside a meta-transaction (NEP-366) or with its gas allowance used up.