> For the complete documentation index, see [llms.txt](https://surf-2.gitbook.io/surfliquid-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://surf-2.gitbook.io/surfliquid-docs/execution-security/vault-isolation-and-permissioning.md).

# Vault Isolation and Permissioning

#### **Why every user vault is sovereign, and automation never becomes custodial**

Surf is built on a simple but non-negotiable principle:

Each user vault is a self-contained, isolated financial entity.\
Automation operates *inside* the vault.\
Ownership and withdrawal rights always remain with the user.

This is what vault isolation and permissioning mean in practice.

***

#### Vault Isolation

Every Surf user has a dedicated user-owned vault.

That vault:

* Holds only that user’s assets
* Executes only that user’s vault actions
* Enforces only that user’s rule set
* Is not pooled at the custody layer
* Is not co-mingled with protocol treasury or other users

There is no shared balance sheet.

A failure, liquidation, or strategy unwind in one vault cannot:

* Affect another user’s funds
* Propagate risk across accounts
* Create cross-contamination of positions

Isolation is enforced at the contract and execution layer, not just logically.

This is the same principle used in institutional prime brokerage and segregated accounts, applied on-chain.

***

#### Permissioning Model

Surf follows a strict separation of rights:

1. **Ownership Rights**

The user is the sole owner of the vault.

Only the user can:

* Deposit
* Withdraw
* Close positions
* Revoke automation
* Change risk profiles and vault permissions

**Surf cannot override this.**

2. **Execution Rights**

The Surf can:

* Propose rebalances
* Execute approved vault actions
* Route funds across allowlisted venues
* Optimise within defined constraints

But only:

* Inside the vault
* Inside the Guardian Layer rules
* Inside exposure and risk caps
* Inside withdrawal-safe boundaries

**The agent has *****functional authority*****, not *****custodial authority*****.**

3. **Rule Authority**

The Guardian Layer enforces:

* Protocol allowlists
* Max exposure per venue
* Max leverage and utilisation
* Slippage and liquidity thresholds
* Circuit breakers and kill switches

Even if:

* The AI proposes an action
* A vault signal suggests a move
* Market conditions look attractive

**If rules are violated, execution is blocked.**

***

#### Why This Matters

Most DeFi automation fails in one of two ways:

1. It becomes custodial
2. It becomes uncontrollable

Surf avoids both by design.

Vault isolation ensures:

* Your risk is your own
* Your returns are your own
* Your losses, if any, are contained
* No socialised failures

Permissioning ensures:

* Automation cannot exceed authority
* No silent rehypothecation
* No hidden vault logic changes
* No operator discretion over user funds

***

#### Institutional-Grade Control, Consumer-Grade Simplicity

This model allows Surf to support:

* Retail users who want a simple deposit-and-earn product
* Funds and treasuries that require segregated accounts
* Neo-banks that need clear custody boundaries
* Compliance teams that need provable control limits

All with the same architecture.

***

#### The Result

Each Surf vault is:

* Legally and technically isolated
* Fully non-custodial
* Governed by deterministic permissions
* Automated without surrendering control
* Withdrawable at any time

Automation operates as a constrained system inside your vault, not as an owner of your funds. **This is how Surf can manage capital without becoming custodial.**