TZURTZURBack to TZUR for Agents

TZUR for Agents · Note legali

Agent Operation & Risk Disclosure

This disclosure explains the specific risks an owner accepts when enabling AI-agent operation in TZUR for Agents ("TZUR"), a non-custodial, Bitcoin-only Windows desktop application operated by Blocksight OÜ, an Estonian private limited company (registry code 17474529), registered at Vesivärava tn 50-301, 10152 Tallinn, Estonia. Read it alongside the other TZUR legal documents. By enabling agent operation, you accept the matters described below.

Overview

TZUR holds a separate "operational" Bitcoin wallet that you fund, and exposes that wallet to an AI agent of your choosing over a local, loopback-only MCP (Model Context Protocol) server. The agent can only do what you permit it to do, through a layered system of scoped permissions, owner approval, and an owner-configured policy. TZUR is non-custodial: keys are generated and stored locally on your computer, and Blocksight cannot access, freeze, or move your funds.

These controls are real and meaningful, but they are not magic. They are designed to stop an agent from moving funds without your authorization or outside the policy you set. They cannot turn an automated tool into a substitute for your own judgment. This document is written to be honest about where the line falls, so you can operate TZUR with realistic expectations.

You Bring Your Own AI Agent

TZUR does not include, host, or supply an AI agent. You connect your own AI agent or MCP client (for example, Claude Desktop, Claude Code, or any other MCP client). That software is a third-party product.

Blocksight does not provide, control, endorse, train, or take responsibility for the third-party AI you connect. Its behavior, accuracy, safety, privacy practices, data handling, pricing, and availability are governed entirely by that provider, under that provider's own terms. You accept those terms by using that provider, and you are solely responsible for:

  • Choosing which AI agent or MCP client to connect.
  • What you instruct, configure, or authorize that agent to do.
  • Whatever the agent transmits to its own provider as part of operating.
  • Protecting the access token you issue to it (see below).

If the third-party AI is unavailable, behaves unexpectedly, or changes, that is between you and that provider. Blocksight is not a party to your relationship with your AI provider.

Agent Access Tokens Are Credentials

Each agent connects to TZUR's local MCP server (on 127.0.0.1) and authenticates with a per-agent bearer token. That token is a credential. Anyone or anything able to present a valid token over the local transport can interact with the agent interface to the extent you have permitted.

A token never grants access to your seed or private keys, and it never lets an agent exceed the scopes and policy you set. But you are responsible for protecting the tokens you issue, for issuing them only to agents you intend to authorize, and for revoking them if a connected agent or its environment is no longer trusted. Treat a bearer token with the same care as any other secret on your computer.

What the Approval System Does and Does Not Protect Against

This is the most important section. Please read it carefully.

The agent interface is built so that an agent can never read the seed or private keys, and an agent is limited to the scopes you grant. It "cannot name an action it was not given." Spending is off by default, behind a master switch that resets to off every time the app restarts. When spending is enabled, moving funds requires either:

  • a per-payment approval that you give in person, with a present-user Windows Hello gesture, producing a single-use token bound to that payment's exact parameters (any change after approval is rejected); or
  • a payment that fits within an allowance you explicitly enabled (per-transaction cap, daily cap, recipient allowlist, approval threshold). Anything outside that envelope falls back to owner approval.

What this protects against: an agent cannot move your funds without either your live approval or a policy you deliberately configured. It cannot silently exceed your caps, pay an address outside your allowlist, or alter the details of a payment you already approved.

What this does NOT protect against: TZUR does not, and cannot, prevent a compromised, manipulated, or simply mistaken agent from PROPOSING a payment. A misled agent, including one influenced by prompt injection or deceptive content it processed, can still ask you to approve a transaction. The approval system stops unauthorized movement; it does not read minds and it does not vouch for the agent's intentions.

Because of this, the safeguard that protects you at the moment of approval is YOU. When you are asked to approve, verify the payment details that THE WALLET renders on screen, the destination address and the amount, not the words the agent used to describe them. Approve only what the wallet itself shows you, and only if it matches what you actually intend. If anything is unclear or unexpected, decline.

Autonomous Spending and Policy Configuration

If you enable an allowance, you are choosing to let payments that fit inside that envelope proceed without a per-payment gesture. This is a convenience you opt into, and the envelope is entirely yours to define: the per-transaction cap, the daily cap, the recipient allowlist, and any approval threshold.

A poorly chosen policy is your risk. If you set caps higher than you are comfortable losing, add a recipient you did not intend, or leave an allowance enabled when you no longer want autonomous spending, payments within those limits may proceed without asking you again. The daily-spend ledger persists across restarts, so daily limits are enforced consistently, but limits only protect you to the extent you set them sensibly. Review your policy before enabling it, and disable allowances you are not actively using. When in doubt, leave spending off and approve each payment in person.

The Operational Wallet

The wallet exposed to agents is a separate operational wallet, isolated from any other wallet, and funded by you. Only put into it what you are prepared to have an agent operate within the policy you set. It is intended as a working balance for agent activity, not as primary or long-term storage. Keeping the operational balance modest limits your exposure if an agent misbehaves or a policy is misconfigured.

Exchange Features

TZUR's exchange features are optional and gated. They are not active until you configure a third-party exchange. TZUR is not a broker, exchange, money-services business, money transmitter, custodian, or investment adviser, and provides no financial, investment, or tax advice.

If you choose to enable exchange features, you transact directly with that third-party exchange under ITS terms, and TZUR is not a party to the trade. Your exchange API credentials are sealed within the app and are never reachable by an agent. Each order still requires the same owner approval as any other fund movement. Availability, pricing, execution, and the handling of your funds and data at the exchange are governed by that exchange, not by Blocksight.

Audit and Supervision

TZUR records agent activity in a tamper-evident, append-only, hash-chained audit log, sealed at rest with Windows DPAPI, and viewable live in the supervision cockpit. No agent instructions, drafts, approvals, or audit records are sent to Blocksight.

The audit log is local and tamper-evident, meaning alteration is detectable, but it is not immutable and it is not stored off your device. A factory reset clears it. The log is a tool for you to supervise and review what your agents have done; you remain responsible for actually watching the cockpit and reviewing activity. Supervision detects and records; it does not, by itself, reverse a payment that was authorized.

Acceptance

By enabling agent operation in TZUR for Agents, you acknowledge and accept the risks described in this disclosure: that you bring your own third-party AI agent under its provider's terms; that bearer tokens are credentials you must protect; that the approval system stops unauthorized movement but cannot stop a deceived or mistaken agent from proposing a payment, so you must verify the on-screen details the wallet renders before approving; that any autonomous-spending policy and its consequences are yours to configure; that the operational wallet holds funds you commit to agent operation; that exchange features, if enabled, are with a third party under its terms; and that audit and supervision are local tools you are responsible for using.

Questions about this disclosure may be sent to legal@blocksight.live. General support is available at contact@tzur.live. This document is governed by the laws of the Republic of Estonia. Website: https://tzur.live

Last Updated: 8/6/2026