> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vana.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> The Vana security model — trust boundaries, data collection, encryption, consent, verification, and responsible disclosure.

This page describes how the Vana data portability stack protects user data. Data is encrypted with keys derived from the user's wallet; external access to that data requires a user-signed grant that the Personal Server verifies on every request; and the storage and gateway infrastructure hold only ciphertext and metadata, never plaintext or keys. Completed third-party audits are listed on the [Audit reports](/security/audits) page.

<Info>
  **Trust and risk.** No architecture or audit guarantees the absence of vulnerabilities. If you integrate with or rely on the protocol, conduct your own due diligence and understand the risks.
</Info>

## Security model

Vana's security rests on three independent controls, so that no single component has to be trusted on its own:

1. **On-chain consent record.** Grants are recorded on Vana L1: permission state is tamper-evident and publicly verifiable, and changes only under the data owner's authority — the owner's wallet, or a server the owner has registered. This is the source of truth for who may access what.

2. **Client-side access enforcement.** The component that checks access — the Personal Server — runs on the user's own device (bundled in the desktop app, or a browser tab today; a user-owned cloud compute environment in the future), not on Vana infrastructure. On every request it authenticates the caller as a registered grantee (a valid `Web3Signed` signature), checks that an active grant covers the requested scope, returns only that scope, and logs the access. A request without a valid signature and an active, in-scope grant is rejected.

3. **Encryption under user-held keys.** Data is encrypted with keys derived from the user's wallet signature ([HKDF-SHA256](/protocol-reference/storage-encryption#key-derivation)); Vana never holds those keys, so storage and gateway infrastructure hold only ciphertext.

### Where your data lives

Plaintext user data lives in two environments: the user's own — their device, or the [Personal Server](/protocol-reference/personal-servers) they run — and an application the user has explicitly granted access to. **Storage holds only ciphertext; the protocol's records hold pointers and metadata (owner, scope, timestamps, sizes, and content hashes)** — never plaintext or keys.

| Stage           | Where                                                                                                                                                   | What is exposed                                                                            |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Collection      | The user's device (desktop app), or a session run on the user's behalf on Vana-operated infrastructure (web app)                                        | Plaintext — on the user's device, or transiently in the collection session                 |
| Personal Server | Works with plaintext locally to organize and serve data; encrypts each scope before sync                                                                | Plaintext, in the user's environment                                                       |
| At rest         | [Storage backend](/protocol-reference/storage-encryption#storage-backends) — encrypted OpenPGP blobs; the protocol holds pointers (the Files primitive) | Ciphertext bodies, no keys; path and records expose owner, scope, timestamps, size, hashes |
| Consent         | A grant recorded on Vana L1                                                                                                                             | Metadata only, never data                                                                  |
| Access          | The Personal Server validates the grant and serves the granted scope over an authenticated channel                                                      | Only the authorized application                                                            |

The Personal Server is the component that works with plaintext — and it always runs **client-side, on the user's own device**: bundled in the desktop app (Full) or as a browser tab (Lite). Both forms keep the data and the keys on the client; a user-controlled hosted form is a [future option](/protocol-reference/personal-servers#bring-your-own-compute-future). Because the Personal Server works with plaintext locally, **the user's device is the security boundary for that copy**: the decrypted working data, collector browser profiles, and any storage-backend credentials (such as cloud OAuth tokens) live on the device and are protected by it. Storage backends and on-chain records never contain plaintext or keys, so a compromise of storage or the gateway does not by itself expose user data.

### Smart contract governance

Core contracts (`DataPortabilityPermissions`, `DataPortabilityServers`, `DataPortabilityGrantees`) are upgradeable through governance with timelocks. Contract source code is verified on the [block explorer](https://vanascan.io), and contracts go through the [audit program](/security/audits).

### User-controlled revocation

Users can revoke any grant at any time. Revocation is recorded immediately at the gateway (DP RPC), so subsequent gateway-mediated reads are refused; direct integrations enforce against the grant's on-chain state. No builder or protocol operator can re-grant access on the user's behalf. See [Grants & Permissions](/protocol-reference/grants-permissions) for details.

## Data collection security

Connecting a data source imports the user's own data from a platform they use into their Personal Server. Where that collection runs depends on whether the data is behind a login, and that split is a security boundary: data behind the user's login is collected on their own device, while Vana-operated infrastructure only ever handles publicly available data. Either way, collected data lands in the Personal Server before any storage, and the user's credentials are never sent to Vana. The two paths:

| Path                          | Where it runs                                                                 | Used for                                                             |
| ----------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| **Client-side (desktop app)** | The user's own device (Playwright connector)                                  | Sources that need the user's authenticated session                   |
| **Server-side (web app)**     | A session on Vana-operated infrastructure, with no access to the user's login | Publicly available data only — landing in the user's Personal Server |

Server-side collection carries no user credentials or session, so it can only reach data that is publicly accessible without a login — anything behind the user's login is simply unreachable on that path and is collected on the user's own device via the desktop app instead. Collected data always lands in a Personal Server before storage; the infrastructure is never a place data lives. See [Collection & apps](/applications/collection-and-apps).

### The desktop app

For a user's private data that requires a login, the desktop app runs collection **locally on the user's device**. Data and session material stay on the machine — only the encrypted data the user chose to collect is synced.

* **Reuses the user's existing browser session.** So the user doesn't have to sign in again, the app can drive their installed browser and its logged-in session on the device. Where a source still needs a login, the connector prompts for it and submits it directly to the source's own login page — Vana never receives or stores those credentials.
* **Runs on the user's device.** Connectors execute in a Playwright-controlled browser under the user's home directory (`~/.vana/desktop`), with a separate profile per connector. Session state is stored locally on the machine.
* **Sessions are local and clearable.** Stored sessions live on the device so the user isn't re-prompted each time; the app lists every stored session and lets the user clear any of them at any time.
* **User-initiated.** Collection — and any continuous sync the user enables to keep a source up to date — starts only when the user initiates it and can be stopped at any time.

Because connectors run on the device with access to the user's browser session, the connector a user runs is the component that has to be trusted — see [Connector security](#connector-security).

## Connector security

The scripts that perform extraction — **connectors** — are the part of the system that touches third-party sites and runs with the user's browser session, so they are open source and reviewable.

* **Open source, maintained by the Vana core team.** Every connector lives in the public [`vana-com/data-connectors`](https://github.com/vana-com/data-connectors) repository, so anyone — a user, a builder, or a security team evaluating an integration — can read exactly what a connector does before relying on it. The connector set is maintained by the Vana core team, and every contribution — including a platform publishing a connector for its own data — goes through a security and usability review before it is included.
* **Declared scope.** Each connector declares the source and the [scopes and schemas](/protocol-reference/scopes-schemas) it produces; the user approves the requested scopes before collection, and the connector code is public for review.
* **Reviewed before inclusion.** Connectors enter the official set through pull-request review in the public repository, with validation tooling, rather than being loaded arbitrarily at runtime. See [Add a connector](/build-a-vana-app/add-a-connector).
* **Version-pinned distribution.** The official connectors the desktop app ships and updates are pinned in a lockfile and verified against a signature-and-checksum connector index published from the repository's releases, so an official connector cannot silently change between releases. The app can also run user-installed connector overrides; those are user-supplied code and should be treated as such.

Teams integrating Vana are welcome to review — and pin — the specific connectors their integration relies on. For most integrations that is a short, easily auditable list; a security team can read every line of the collection code their users will run before recommending the integration.

## Encryption & keys

Encryption keys are derived from the user's wallet signature; Vana does not generate, hold, or escrow them.

* **Per-scope keys, derived from the wallet.** Each scope's encryption key is derived via `HKDF-SHA256(master_key_material, "vana", "scope:{scope}")`, where the master key material comes from a wallet signature. These derived scope keys are handled inside the Personal Server and are never sent to or stored by builders or Vana.
* **OpenPGP at rest.** Each scope is encrypted as a single OpenPGP message — the file envelope (scope, timestamp, and data) is one encrypted blob. Storage holds that ciphertext blob plus routing metadata (owner, scope, timestamp, size, content hashes), never the plaintext or keys.
* **Signing material stays with the user.** A Personal Server needs only the master-key signature, not the wallet's private key — and since every live Personal Server form runs on the user's own device, that signature never leaves the client either.
* **The Personal Server is the decryption point today.** It decrypts only to serve a request backed by a valid, unrevoked grant, and only for the covered scopes. With [Protocol-Governed Encryption (PGE)](/protocol-reference/encryption-pge) the grantee instead receives a per-request key and decrypts the data itself — the grant a builder integrates against is unchanged.

Full detail: [Storage & Encryption](/protocol-reference/storage-encryption).

## Access & consent

External access to a user's data is authorized by an explicit, wallet-signed grant, re-checked on every request — there is no "verify once, access forever." (The owner and local management/control-plane paths authenticate separately.)

* **Scope-native grants.** A [grant](/protocol-reference/grants-permissions) authorizes a specific grantee to read specific data types (`source.data_type`), not a whole account. It is revocable at any time and can be given a bounded expiry (the safer default; a grant may also be standing consent that lasts until revoked). Grants are signed with **EIP-712**, so consent is cryptographically verifiable, and are recorded on Vana L1.
* **Verified on every request.** Builders read from a Personal Server using signed HTTP requests (`Authorization: Web3Signed`). Each signature is bound to the specific server, method, path, and request body, and carries issued-at and expiry timestamps, so a captured request cannot be used against a different server, method, path, or body, or after it expires. (The signature is short-lived but carries no nonce, so identical replay within its lifetime is not separately prevented.) The server validates the grant on **every** request — registered grantee, unrevoked, unexpired, scope covered — not just at setup. See [Personal Servers → Builder data access](/protocol-reference/personal-servers#builder-data-access).
* **Agents are bounded by the same grants.** The Personal Server's [MCP interface](/applications/agents) lets AI agents work with user data under exactly the same grant permissions as any builder — a grant is the ceiling on what an agent can reach, and revocation applies identically.
* **Access is logged for the user.** The Personal Server records an access log of successful scope reads that the user can review.
* **Revocation the user controls.** A user can revoke at any time. Where the Context Gateway serves data, revocation stops future reads immediately, even before any on-chain confirmation; direct integrations enforce against the grant's on-chain state. Revocation blocks future access — data an application already received while its grant was valid is governed by that application's own terms, as with any permissioned-data platform.

## Audits & verification

Independent audits and independent verification play different roles:

* **Third-party audits.** Protocol smart contracts are audited by independent security firms ([Nethermind, Hashlock](/security/audits)). Completed reports cover earlier protocol components; an audit of the current data portability contracts has been commissioned and will be published when it concludes. See [Audit reports](/security/audits).
* **What you can verify yourself, today.** Several properties don't require trusting an audit — or Vana: connector code is public and auditable line by line; permission state is anchored on Vana L1 and publicly inspectable; contract source is verified on the block explorer; and the key-derivation scheme is [fully specified](/protocol-reference/storage-encryption#key-derivation).
* **What the architecture limits.** The user-held-key design bounds what any single compromised — or unaudited — component can expose: storage backends and protocol infrastructure never hold both ciphertext and keys.

Teams evaluating an integration are welcome to reach out to [dev@vana.org](mailto:dev@vana.org) for a technical walkthrough of the security model for their specific use case.

## Responsible disclosure

If you believe you have found a security vulnerability in Vana contracts or infrastructure, report it privately. Responsible disclosure is appreciated; reports are acknowledged and addressed as promptly as possible.

**Email:** [dev@vana.org](mailto:dev@vana.org)

When reporting, please include:

* Affected component or contract (and version or commit if known)
* Steps to reproduce, with as much detail as possible
* Impact and severity, if you have assessed it
* Any relevant logs or proof-of-concept

Receipt is acknowledged as soon as possible; a more detailed response follows once the issue has been reproduced or triaged. **Please do not disclose findings publicly until the issue has been addressed.**