How we protect your vault
You are trusting us with sensitive details. Here is what AscenVent protects today, and what is still on the roadmap.
The plain-English version: your saved wizard answers are encrypted with AES-256-GCM before they are written to the database, the encryption key stays on the server, documents live in private owner-scoped storage, and Postgres row-level security isolates user data. We are explicit about what the current product does and what remains on the roadmap.
Current security posture
Application-layer encryption
Wizard answers are encrypted server-side with AES-256-GCM before they are written to the encrypted answers field. The browser never receives the encryption key. Legacy plaintext answer data is scrubbed to an empty object on save.
Data in transit
Production traffic is served over HTTPS/TLS. Sensitive encryption and export work runs on the server, not in browser code that would expose server secrets.
Row-level isolation
Profiles and document metadata are protected by Postgres row-level security policies scoped to the authenticated user. A normal user session can select, update, or delete only its own profile and document records.
Private document storage
Uploaded files live in a private vault bucket. Storage policies require the first path segment to match the authenticated user's ID, so files are owner-scoped and are not served through public URLs.
Encrypted exports
Portfolio exports can be generated as encrypted PDF packages. When you choose a password-protected export, the PDF is encrypted with AES-256.
What we store and what we do not
We are deliberate about what we ask for, because the safest data is data we never had.
| Category | What we store | What we do not store |
|---|---|---|
| Bank and investment accounts | Institution name, account type, beneficiary notes, and limited identifying details. | Online banking credentials, full passwords, or seed phrases. |
| Insurance policies | Carrier name, policy type, beneficiary names, and planning notes. | Claim portal credentials or passwords. |
| Physical security | A pointer to where combinations and access codes are kept. | Safe combinations, gate codes, or alarm codes themselves. |
| Crypto and digital assets | Which exchanges or wallets you use and where recovery material is kept. | Seed phrases, private keys, or wallet passwords. |
| Password manager | Which password manager you use and where emergency access is set up. | Master passwords or master recovery keys. |
| Documents | Uploaded copies of documents you choose to place in the vault. | Original legal documents unless you upload a copy yourself. |
Access controls
A separate staff console is restricted to verified users on a server-held email allowlist. Authorized staff can review member and release information needed for support and Tier 3 review. Those reads use server-only paths; the service-role key and encryption key are not exposed to the browser.
Release tables are not available to normal browser roles. Release transitions and their audit entries are committed together in the database, and private release access is claimed on an explicit action before any approved package is loaded.
If you believe your account has been accessed without authorization, immediately.
Beneficiary verification
AscenVent uses named beneficiary links, tiered response windows, supporting evidence for Tiers 2 and 3, staff approval for Tier 3, and configured Premium co-sign thresholds. The owner can stop a request, and every emailed action requires an explicit confirmation rather than changing state when the link is opened.
The current product does not integrate government identity checks, KYC, death records, obituary databases, or court records. Internal evidence review is a safeguard, not a guarantee that a requester is who they claim to be. Keep your beneficiaries and contact details current, and contact us if a request looks unfamiliar.
Incident response
We maintain a breach-response policy for security incidents that affect user data. We investigate reported incidents, work to contain and understand them, and notify affected people and authorities when required by applicable law. Timing depends on what is known and what the law requires; this page does not promise a fixed notification window.
Read the full Breach Policy.
Roadmap, not current claims
The following protections are planned or under evaluation, but are not claimed as current controls:
- Formal SOC 2 examination.
- Zero-knowledge architecture for the highest-sensitivity fields.
- Cloud KMS or HSM-backed key management.
- Recurring independent penetration testing.
We will update this page when those milestones are actually reached.
Responsible disclosure
If you discover a security vulnerability, please disclose it responsibly by . Include a description, steps to reproduce it, and what data or systems you believe could be affected.
We will review good-faith reports and respond as the available contact information and investigation allow.