Security Principles

Non-Custodial Design

TZUR for Agents is fully non-custodial. Your private keys are never stored on servers, and TZUR has no ability to access, freeze, or move your funds. There are no accounts to create, no cloud storage of wallet data, and no server-side record of your Bitcoin holdings. Your keys exist only on your computer, protected by Windows security and, where enabled, your computer's TPM. If TZUR's servers disappeared tomorrow, your Bitcoin would remain fully accessible. You can recover your wallet using your seed phrase and any BIP-39 compatible wallet application.

Agent Security Model

Agents operate the wallet under a strict, human-controlled model: agents operate, you authorize.

Agents never see your seed phrase or private keys. There is no agent capability that returns key material; signing happens only inside the wallet core.
Agents reach the wallet only through a scoped local interface, with each agent limited to the permissions you grant. Permissions are default-deny: an agent cannot name an action it has not been given.
Spending is disabled by default. The spending master switch resets to OFF on every restart. With spending enabled, an agent can move funds only by submitting a payment you have approved with a present-user Windows Hello gesture, or one that fits an allowance you have explicitly enabled (per-transaction cap, daily cap, recipient allowlist, and an approval threshold). Anything outside that envelope falls back to your approval.
Each owner approval issues a single-use token bound to that payment's exact parameters. Any change after approval is rejected, and the daily-spend ledger persists across restarts so a restart cannot reset your limits.
Every agent action is recorded in a tamper-evident local audit log that you can watch live. Agents cannot disable or edit this log.
Each agent operates a specific wallet you assign, isolated from your other wallets, and you can revoke any agent's access immediately.

Honest framing on prompt injection

TZUR's controls are designed to stop an agent from moving funds *without* your authorization or *outside* the policy you set. They are not a guarantee against prompt injection, a compromised agent, or a deceived owner.

A compromised, manipulated, or simply mistaken agent can still *propose* a payment. What it cannot do is move funds past the approval and policy layer on its own. This makes your verification the last and most important line of defense. Before you approve, verify the payment details that the wallet renders on screen, the recipient address, the amount, and the fee, rather than trusting what the agent told you. If the wallet shows something you did not intend, do not approve it. TZUR cannot protect you from authorizing a payment you chose to authorize.

Agent Access Tokens

Each agent authenticates to the local MCP server with its own per-agent bearer token, read from the transport. The token identifies that specific agent connection and scopes it to the permissions you granted.

Treat each token as a secret. Anyone or anything holding a valid token can act as that agent, within the scopes you granted it (and never beyond, since spending still requires your approval or an allowance you enabled).
You are responsible for protecting the token you issue to your AI client. Do not paste it into untrusted tools, logs, or shared configuration.
To cut off an agent, revoke its token. Revocation invalidates that token immediately; the agent can no longer authenticate or act.
Tokens are re-provisioned, not recovered. If a token is lost or you want to rotate it, issue a new one to the agent rather than attempting to retrieve the old value.

Operational Wallet Isolation

The wallet you expose to agents is a separate, operational wallet that you fund yourself. It is isolated from any other wallet on your computer, and an agent only ever sees and operates the specific wallet you assign to it.

This isolation deliberately limits the blast radius. Even in the worst case, the funds an agent could ever attempt to touch are bounded by the operational float you chose to place in that wallet, never your entire holdings. Keep the operational balance to what your agent activity actually needs, and top it up as required, so the amount at risk stays small by design.

Key Generation & Derivation

Private keys are generated locally on your computer. Cryptographic randomness is provided by the operating-system secure random number generator (BCryptGenRandom on Windows). TZUR follows BIP-32 for hierarchical deterministic key derivation, meaning your entire wallet is derived from a single master seed. For address generation, TZUR implements BIP-84 to produce Native SegWit (bech32) addresses using the derivation path m/84'/0'/0'. This is fully deterministic: the same seed will always produce the same sequence of addresses. No key material is ever generated on or transmitted to a remote server.

Seed Phrase Security

Your 12-word seed phrase is generated locally according to the BIP-39 standard. This seed phrase is the sole recovery mechanism for your wallet. TZUR does not store, transmit, or have any access to your seed phrase. The phrase is displayed once during wallet creation and can be viewed again in Settings for backup purposes, behind a Windows Hello gesture and screen-capture protection. It is never sent over the network, never written to server logs, and never included in analytics data or any agent-visible data. If you lose your seed phrase and your computer, your Bitcoin cannot be recovered by anyone, including TZUR.

Memory Handling

Private key material is treated as toxic data. Keys are loaded from secure storage only when needed for transaction signing. Once the transaction is signed, all key material is immediately cleared from memory. Private keys are never cached in application state, never written to temporary files, never logged, and never persisted in unprotected storage.

Secure Storage

Sensitive wallet data, including the encrypted seed, is stored in a local secrets file sealed with Windows DPAPI (the Windows Data Protection API). DPAPI binds the data to your Windows user account, so it cannot be lifted to another machine or swapped offline. On computers equipped with a Trusted Platform Module (TPM), you can additionally seal the encrypted seed to the TPM. The TPM key is non-exportable and never leaves the hardware. The application is gated by a PIN, hardened with PBKDF2-HMAC-SHA256 at 600,000 iterations, and, where available, by Windows Hello.

When you configure an optional third-party exchange, the exchange API credentials are sealed in the application the same way and are never reachable by an agent. Agents cannot read or use those credentials, and every order placed through an exchange still requires the same owner approval as any other movement of funds.

Tamper-Evident Audit Log

Every agent action and every approval decision is recorded in a local audit log.

The log is append-only. Records are added, never edited in place.
Each record is hash-chained to the previous one, so any alteration or deletion of an earlier entry breaks the chain and is detectable.
The log is sealed at rest with Windows DPAPI and bound to your Windows user account.
It is tamper-evident, not tamper-proof, and it lives only on your computer. It is not stored off the device or with Blocksight. A factory reset of the application clears it.
You can watch the log live in the supervision cockpit. Agents cannot disable, edit, or hide it.

App Lock & Capture Protection

TZUR locks itself behind your PIN (and Windows Hello, where enabled) at launch and after a period of inactivity. The application also enables screen-capture protection while the recovery phrase is shown, to reduce the risk of shoulder-surfing and screen-recording malware.

Network & Electrum Trust Model

TZUR communicates with public Electrum servers to retrieve blockchain data. Electrum servers are not trusted. They serve as data providers only. All transaction construction and signing happens locally on your computer. TZUR never sends private keys, seed phrases, or personal data over the network. Connections use TLS. Transaction integrity is verified using Merkle proofs. BlockSight supplies public chain data. The local MCP server listens on loopback only (127.0.0.1), and no agent instructions, drafts, approvals, or audit records are sent to Blocksight.

Privacy-Respecting Analytics

TZUR for Agents collects no usage analytics by default. Analytics are strictly opt-in and stay off unless you explicitly enable them in Settings; you can turn them off again at any time. If enabled, analytics never include wallet addresses, balances, transaction data, seed phrases, key material, personal identity, agent instructions, audit records, or agent access tokens. TZUR does not include advertising SDKs, third-party tracking technologies, or fingerprinting libraries. We do not sell, share, or monetize any user data.

Responsible Disclosure

If you discover a security vulnerability in TZUR for Agents, please report it to legal@blocksight.live or contact@tzur.live. We take all reports seriously and will respond promptly.

Last Updated: 8/6/2026