Skip to main content

Connections, grants and approvals

A site connection allows a website to learn the approved development account. It grants no payment authority. A spending grant is a separate, reviewed permission, scoped to the browser-protected origin and its declared limits.

Read the entire grant​

The implemented simulator grant supports native JOLT transfers with a fixed recipient, asset, operation and chain. It limits each transaction, each UTC day and the total lifetime budget, including maximum fees, and has an expiry. Serialized requests prevent concurrent spends exceeding a budget. Revocation stops future use; a spent amount is not restored by disconnecting.

The extension derives the website origin from Chrome's protected sender context. A page-supplied origin, iframe, different port or subdomain cannot inherit another site's authority. Website code cannot invoke internal wallet-management methods.

Request limits​

  • A payment request must expire within 24 hours, and each site's request nonce can be used only once.
  • At most 20 approvals can be pending at a time. A full queue rejects new requests rather than dropping old ones.
  • A grant needs positive limits, with per-transaction ≤ daily ≤ total. The request's maximum fee counts against every limit.
  • Grants can be given only to a connected website. The local assistant cannot receive one.
  • A pending payment cannot be approved after its site disconnects.

Disconnect versus revoke​

Disconnect removes the connection. Revoke grant removes the simulator's spending permission. Ethereum token allowances and WalletConnect sessions are separate permissions and need their own management. Emergency local revocation disconnects websites, revokes simulator grants, cancels pending approvals and disables the local agent; it does not revoke on-chain authority.

Passkeys and the assistant​

A passkey assertion binds the account, chain, policy version and exact pending request, including recipient, amount, fee, nonce and expiry. An enrolled passkey requires verified authentication for spending approvals. A local assistant can prepare a payment but goes through the same queue and cannot borrow website grants.

The wallet shows security notices with source, evidence, observation time, expiry and verification status. Included notices are labelled documentation examples, not a live AI Agent Network feed. Website content, metadata and model output do not authorize spending.

Network enforcement remains separate​

These controls currently protect the local simulator and extension bridge. They do not create a session signing key or prove network enforcement. The node has its own native account and grant primitives; connecting the wallet to those policies is a release dependency.