> For the complete documentation index, see [llms.txt](https://docs.vishwalab.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vishwalab.com/security.md).

# Security

Vishwa's security model rests on one architectural decision: verification happens before execution, inside hardware the agent cannot reach. Everything else follows from it.

### Non-custodial by design

In the CLI, the agent never holds keys - it submits unsigned requests through the gateway, and only the control layer can sign, only on a passing proof. In the vault, deposited BTC stays native (never wrapped or bridged) and remains subject to operational policies, risk limits, and verification rules throughout.

### Hardware-sealed policy

Constraint policies live inside a Trusted Execution Environment (TEE). Neither the agent proposing an action nor the wallet executing it can read or modify the policy; the agent only ever receives allowed or denied. This removes the two most common failure modes of agent finance: an agent talked (or hallucinated) into overstepping, and a policy quietly edited by the thing it constrains.

### Independent verification, three axes

Every request is checked for authorization (right agent, right action, right venue), solvency and limits (caps and balances), and execution fidelity (fill price against independently sourced market data). Because the control layer pulls oracle and venue prices itself, it can catch a bad fill that transaction-level policy engines cannot see.

### Fail-closed

A request that fails any check is denied before signing. There are no after-the-fact alerts, no approval queues racing against execution, and no irreversible action taken on an unverified request.

### Defense in depth

No single component is trusted alone: the proposer (agent or coordinator), the policy (owner- or curator-defined), and the verifier are separated by design. In vault deployments this appears as the Ciara / Naro / Veta split; in the CLI, as owner policy vs. agent vs. control layer. Rate limits bound the blast radius of any runaway loop, and every executed action leaves an auditable on-chain signature.

### Audits and disclosures

Five third-party audits cover the stack: FuzzLand's 2025 audits of the token contracts, BTC ZK-circuits, and light client; FuzzLand's June 2026 audit of the agent product (Vishwa CLI, Veta TEE Engine, Agent Service - 14 issues, none High or Critical); and ExVul's June 2026 audit of the Vishwa Proof Token (passed, 0 Critical/High). The Veta TEE Engine itself is covered by FuzzLand's audit. Summaries and reports are on Audits and Compliance. A public bug bounty program has not yet opened.

### Honest limits

The model reduces and bounds risk; it does not remove it. Strategy losses within policy limits, venue or counterparty failure, and custody risk remain possible. Constraints ensure capital cannot move outside the rules - they do not ensure the rules produce profits.