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

# Security Model

Security is foundational to Sovra AI's design as it operates as both a non-custodial crypto wallet and an autonomous AI trading assistant. The system employs a multi-layered security architecture to protect user assets, personal data, and transactional integrity—without compromising user experience.

1. Private Key Storage (Mobile Secure Enclave)\
   Sovra AI uses native mobile device security features to safeguard private keys:

* On iOS, private keys are stored in the Secure Enclave; on Android, they reside in Trusted Execution Environments (TEE).
* Keys are never transmitted off-device or exposed to Sovra servers.
* All on-chain transactions (e.g., trade execution, staking, swaps) are signed locally using these device-stored keys.

This ensures full user custody and eliminates centralized key management risks.

2. Biometric Login, MFA, and Encrypted Backup\
   Access control to the Sovra app and wallet is protected through:

* Biometric authentication (Face ID, fingerprint) for instant yet secure login.
* Optional Multi-Factor Authentication (MFA) tied to email, phone, or authenticator apps.
* Encrypted backup of wallet seed phrases and configurations using user-defined passwords, stored either locally or on decentralized storage (e.g., IPFS or iCloud/Drive with encryption).

These layers help protect against device loss, theft, or unauthorized access.

3. Trade Approval Verification\
   Before executing any on-chain operation, Sovra AI ensures user consent by:

* Requiring explicit approval for each transaction in Manual or Semi-Auto modes.
* Displaying trade summaries in human-readable format, including token symbols, amounts, estimated gas, and intent.
* Offering adjustable limits, such as daily trading caps, asset-specific confirmations, and strategy locks (e.g., AI cannot trade over 10% of a portfolio without user approval).

This model balances automation with user sovereignty.

4. ML Anomaly Detection on Transaction Patterns\
   To defend against wallet compromise, insider threats, or rogue AI behavior, Sovra AI employs real-time anomaly detection:

* Machine Learning models continuously monitor transaction metadata (e.g., frequency, asset class, amount, destination address).
* If an outlier or suspicious pattern is detected—such as an unusually large transfer, sudden token approval, or rapid sequence of trades—the system will:
  * Automatically pause AI automation.
  * Alert the user with a detailed explanation and recommended next steps.
  * Require additional authentication or approval before resuming.

This proactive layer provides dynamic, behavior-based security that evolves as user activity and market conditions change.

🛡️ Summary:\
Sovra AI’s security model is designed to be as autonomous and intelligent as the trading logic it powers—giving users both full control and smart protection in one unified experience.

Layers:

* Hardware-level key storage (no third-party access)
* Biometric and MFA access control
* Clear and customizable trade consent flows
* Adaptive, AI-powered fraud and anomaly prevention

This approach ensures Sovra is not only powerful—but trustworthy.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://sovra-ai.gitbook.io/sovra-ai/sovra-ai-documentation/security-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.