Vest works with the most sensitive documents a contractor has: bid numbers, means and methods, contracts. This page says where those documents live, who can reach them, which vendors touch them, and what we have not built yet. Everything on it is true today. What is not built yet is listed as such; we do not publish dates for roadmap items.
Vest runs in Amazon Web Services in the US East (Northern Virginia) region. Each company gets its own database. A query against your database cannot read another company's rows. Inside your database, row-level security policies check who is asking on every query, so a user sees only the projects they belong to even if a query forgot to filter.
Your files, the page images we render from them, and the text we extract live in private storage under a prefix for your company. That storage blocks all public access and refuses any request that is not over TLS. Nothing is ever served from it directly: every read and write uses a signed link that names one file, one action, and expires within the hour.
Your team. Sign-in is brokered through an identity provider, so Vest never stores a password. Each person has their own account. Access is granted per project by your admins and is enforced by our servers and by the database, not by the browser. If a person cannot open a project, Vest cannot search it or cite it for them. Remove someone and their access ends at once.
Our team. Two founders operate Vest. We reach our hosting account through single sign-on with short-lived sessions, and no server accepts SSH. Operator sessions on the application are recorded and kept for six months; operator sessions on the database are not yet recorded. We open a customer's documents only to run the service, to investigate a problem you report, or when you ask us to.
Sign-in events and admin actions (invitations, role changes, removals, downloads of a conversation) are written to a table the application can only append to; it cannot edit or delete a row.
In transit: we accept TLS 1.2 and 1.3 only and redirect plain HTTP. Connections from our services to the database and to storage are encrypted, and storage rejects any unencrypted request. At rest: the database, its automated backups, and every file in storage are encrypted at rest with AWS-managed keys. Encryption keys dedicated to each company, so that destroying your key makes your stored bytes unreadable everywhere including in backups, are not built yet.
When you upload a set, Vest renders each page to an image, reads the text (OCR), finds the drawings, schedules and callouts on the page, and stores the results in your database along with a searchable index. When you ask a question, Vest retrieves the relevant passages and page regions from your project and sends them, with your question, to a language model that writes an answer with citations. Every answer opens the exact page it came from, and Vest abstains when your documents cannot support an answer.
Your documents, questions and answers are never used to train AI models. Vest does not train models. Every provider is used through its business API, and each provider's published terms on training and retention are quoted, with a link, in the detailed subprocessor list in the pilot packet, so you can read them rather than take our word. Provider settings live in committed configuration, so a change to which providers see your data is a reviewed code change, not a switch someone can flip quietly.
Where an AI request is processed differs by provider, and some providers may process it outside the United States. The detailed subprocessor list says which. Storage, databases and backups stay in AWS Northern Virginia.
Vest also records the questions asked in your company, the passages retrieved, and the answers given, so we can find and fix wrong answers. Those records live in your database and, for the answering step only, in a tracing service hosted in the United States. Page images never leave for tracing.
Every third party that touches customer data, by category. We will tell pilot partners before adding one. The detailed version, which states what each vendor does for you, what it receives, and each provider's published terms on training and retention, is part of the pilot packet and is shared under the pilot agreement's confidentiality terms.
| Category | Vendors |
|---|---|
| Hosting, storage and databases | Amazon Web Services |
| AI models and document processing | Google Cloud, Microsoft Azure, OpenAI, Anthropic, xAI |
| Sign-in | WorkOS |
| Tracing | Langfuse |
| Google Workspace |
Source control, builds, this website and its pilot request form run on hosted services that hold no customer documents.
The database is backed up automatically every day and can be restored to any point in the last 7 days. Deletion protection is on, so the database server cannot be deleted by accident. Storage keeps every version of a file, and a deleted or overwritten file version is kept for 30 days before it expires. The restore procedure is written down and restores a copy beside the live system, never over it.
Your documents are yours. Deleting a project removes its rows, every stored version of every file under it, and the text we read from its pages, so nothing of it waits out the 30 days. When a pilot ends, we delete your company's database, files and quality-review records on request; copies in database backups then expire within 7 days.
A web application firewall in front of the product blocks addresses on our hosting provider's threat list and request shapes that match known exploits, and it limits how many requests and how many sign-in attempts one address can make in five minutes. Our hosting provider's threat detection watches our account, storage and database sign-ins and emails the founders on any finding of medium severity or higher.
Every change to our hosting account's setup and every read and write of storage is written to an audit trail that is kept for 400 days under a retention lock, with file validation so a missing or altered log file can be detected. Any change to the trail itself emails the founders. Alarms on errors, failed processing, database health and crashed services email the founders the moment they fire, at any hour. Application logs are kept for 30 days and storage access logs for 90 days. If we discover a security incident that affects your data, we tell you promptly after discovering it, with what we know and what we are doing.
Vest holds no certification today, and we will never claim one we do not hold. A SOC 2 audit and a CSA STAR Level 1 self-assessment are on our roadmap; we do not publish dates for either. Independent penetration test results, when we have them, are shared with pilot partners under NDA and noted here.
These are on our roadmap. We do not publish dates; ask us for the current plan.
Documents from government, federal and military projects, and security-restricted documents such as airport or utility security plans, carry legal requirements we have not built the protections for. They stay out of Vest for now, and pilot agreements say so.
Write to security@vest.build. We acknowledge reports promptly and keep you informed until the issue is fixed. Good-faith research that avoids other customers' data, avoids service disruption, and gives us reasonable time to fix a finding is welcome and will not be met with legal action. Our machine-readable contact is at /.well-known/security.txt. There is no bug bounty program today.
This page, saved as a PDF, is our security overview. Pilot partners also receive the detailed subprocessor list, the penetration test attestation letter when available, our pilot agreement with confidentiality terms, and written answers to any security questionnaire. Ask at security@vest.build.