Security and privacy engineering

1How to read this page

Vega is a small company at pilot stage. We have no certifications, no external audit, and no security team. Publishing a page that implies otherwise would be the easiest thing on this list and the most damaging, so this page does something narrower instead: every claim below names the file in Vega's own source that implements it, and every gap we know about is listed in section 12 rather than left out.

If you are evaluating Vega for a company, sections 3, 5 and 12 are the ones to read first. If a claim here turns out to be wrong, tell us at help@tryvega.tech and we will correct this page and say what changed.

2Personal life is filtered out at ingestion

Every path that can write a capture runs a topical gate before anything becomes a work moment. Content the gate reads as health, personal finance, family and relationships, or personal interest is dropped and never becomes a session, a signal, a score or a graph node (lib/topicGate.ts).

The gate fails closed. If the classifier errors or times out, the content is dropped rather than kept — the code used to fail open on one path, a production incident traced stored personal-medical content to exactly that path, and the behaviour was changed (lib/topicGate.ts:14-27).

Building software about health, money or sport is work and passes the gate. Discussing your own health, money or family is personal and does not. The line is in the classifier prompt, and it is a classifier, so it is not perfect.

3There is no personal-information redaction

This section exists because it is the single most likely thing for a reader to assume from section 2, and the assumption is wrong.

Vega has three filters and none of them is a personal-information filter. The topical gate in section 2 decides whether a capture is about your own private life and drops the whole thing if it is; it does not look for personal data inside content it accepts. The secret redactor in section 6 matches credential shapes and replaces them; a person's name is not a credential shape. The anonymiser (lib/anonymize.ts) strips company names, people's names, codenames, geographies and amounts — but it runs only on the path that writes a public profile face or an anonymised training row, never on the ordinary stored record.

The consequence is set out in section 10 of the Privacy Policy: work content in Vega routinely contains other people's personal data, put there by the person who pasted it, and Vega does not detect it, cannot find it on request, and has no route to reach the person it belongs to. Building a detector is real work and it is item one in section 13.

4Raw prompt and response text is off by default

Vega's normal record of a session is a structured summary — a title, a short capsule, and derived signals. Keeping the verbatim prompt and reply is a separate, per-category, opt-in setting, and every category ships defaulted to summary-only, with the personal category defaulted off entirely (lib/types.ts:301-311).

There is exactly one place in the codebase that may authorise a raw write, and it denies by default. It denies when there is no seat, no category, an unknown category, a lookup failure, a category level that is not exactly raw, a missing encryption key, or a writing source that is not on a three-item allow list (lib/rawAuth.ts:66-118).

When a raw write is authorised, the text is encrypted with AES-256-GCM in the application before the row reaches the database, with a fresh initialisation vector per field and the authentication tag stored alongside, so tampering fails to decrypt rather than returning garbage (lib/rawCrypto.ts:20-24, 61-83). If the encryption key is missing or the wrong length, the server refuses to store the raw text at all rather than storing it in the clear (lib/rawCrypto.ts:35-48).

5Reasoning runs on a provider's API, not on Vega's machines

When you ask Vega a question about your own work, this is what happens. Vega resolves your seat from your session — never from anything in the request — and retrieves only your own moments and threads. Where you have opted into keeping verbatim text, it decrypts the turns behind those moments through the one owner-scoped read path, which is parameterised by your seat id and has no parameter through which another seat could enter (lib/askVega.ts). Then it posts that material to Anthropic's API to phrase the answer (lib/askVega.ts:1036-1039, model claude-sonnet-4-6), and the citations attached to the answer are resolved on Vega's side against what was actually retrieved, so an answer cannot cite a moment that is not yours.

What travels: your moment titles, contexts, work types and signals; the titles of your open threads; and decrypted excerpts of your own prompts and replies, capped at 600 characters per transcript turn (lib/askVega.ts:615) and shorter for a cited moment. What comes back goes to you alone. The coaching surface (lib/coachDeep.ts) has the same shape.

6Secrets are redacted before storage

Capture payloads are scanned for credential shapes and redacted before anything is written — provider API keys, GitHub and Slack tokens, AWS keys, bearer tokens, JWTs, PEM and OpenSSH private keys, Google API keys and OAuth secrets, and password-assignment lines (lib/safety.ts:11-45).

This is defence in depth, not a guarantee. It is pattern matching, it is tuned to prefer false positives over false negatives, and it cannot catch a secret that does not look like one. It is also only about secrets — see section 3. Do not paste credentials into a session you expect Vega to capture.

7The two pools, and what Vega may learn from

Everything Vega might learn from is either the content pool — the words you and the model wrote — or the structure pool, which is seat, date, model, tokens, work type, score, the nine signals, iteration count and fidelity, and nothing else. The engineering rules differ per pool and per act, and section 3 of the Privacy Policy is the full statement of them.

The wall that is actually enforced in code today is the seat-type wall: company seats never enter Vega's training set, under any plan, and a seat whose type cannot be determined is treated as non-personal and excluded (lib/trainingStore.ts:88-98). For personal seats, the only content-bearing training record is an anonymised rewrite of a session, never the original words, and it is written only when the account holder has granted that specific permission. The check on that path reads a seat flag which the database maintains as a pure function of the consent log and which no application code can write (sql/migrations/099_consent_records.sql), so the flag cannot drift from the decision; the general-purpose gate every future path must call, mayTrainOn() in lib/consent.ts, derives the same answer from the log directly and fails closed on every branch including a database error.

Three further training records are content-free by construction: where a moment sat in its session, which observable terminal events followed it, and which decisions a person made about it. Those carry no session text.

8Cross-person numbers have a floor of three

No number that describes more than one person is shown unless at least three people contributed to it. The floor is a single constant used by every surface that computes one — team views, team intelligence, team decisions and efficiency (lib/vega/kfloor.ts and its callsites; the canonical constant is ORG_AGGREGATE_K_FLOOR in lib/orgs.ts and migration 040 hard-codes the same floor in SQL).

Below the floor the surface states the reason and renders nothing. It does not render a zero, and it does not render a smaller number.

Per-person rows on team surfaces carry recency, not volume, because a count beside a name reads as a ranking however it is sorted.

9Deletion and retention

Deleting your account destroys your personal seat and the work hanging off it through the database's own cascade rules, behind a typed confirmation. It is deliberately designed so that one person closing their account cannot destroy their company's data: company seats are released rather than deleted before the login is removed (app/api/account/route.ts:9-31).

Four things are deleted on a clock today, by a maintenance sweep (lib/orphanSweep.ts:300-325, lib/captureRefusals.ts:321-327):

10Access, logging and analytics

Product surfaces are authenticated and scoped to the seat that owns the data. Owner-only material — cited moments, raw text, growth scores, coaching, captures — is never assembled into a manager, team, public, recruiting or benchmark payload.

Vega staff actions on customer data are written to an append-only log that is content-free by contract: it whitelists the fields each action may record, so a caller cannot put a prompt, a summary, an email address or a magic link into it, and email addresses are hashed before they reach it (lib/adminAudit.ts:1-12, 32-62). Opening the internal capture view is one of the logged actions.

Consent is its own record and it is append-only at the database, not a flag: a grant is a row, a withdrawal is another row, and the effective answer is derived from the history every time it is asked (sql/migrations/099_consent_records.sql). Update, delete and truncate all raise for every role including the service role, so a consent record cannot be quietly edited by anyone, including us.

Vega runs no third-party analytics, no advertising or marketing trackers, no session recording and no heat mapping. There is no such dependency in the application at all — the only cookies Vega sets are a login session and four display preferences (theme, density, accent, reduced motion).

11The inspectable boundary — what you can see about who sees you

The design goal is that at any moment a person can see who can see what about them. This is where that stands, split into what is built and what is not, because the difference is the whole value of the claim.

Built. The privacy settings screen carries a "who can see any of this" panel with three live rows drawn from real state: Vega staff, with the access described in section 10; your team, showing whether your company's prompt visibility is on or off at that moment; and the public internet, showing whether your profile is live and how many items are on it (components/rebuild/settings/PrivacySection.tsx:189-229). Every change to the company visibility setting is written to a company audit log that any member can open and that is protected against edits and deletes in the database. Your public profile lists every fact you approved. Your export produces your own record and names inside itself what it leaves out.

Not built. Vega does not log reads of your work by other members, so it cannot tell you which of your moments a named teammate has actually opened. The staff log records that a page was opened, not which rows were on it, so it cannot tell you whether a specific moment of yours was read. There is no per-item answer to "who can see this one" — only the three category rows above. And nothing exists for a third party who appears inside your content, because Vega cannot identify them (section 3).

What would close it. One surface and one log: a per-item visibility inspector, reachable from any moment, that lists every audience which can currently reach that item and why; backed by a read-side access log that records team and staff reads with the entry written before the content renders, on the same fail-closed pattern the internal capture view already uses. Until both exist, "you can always see who can see what" describes three category rows, and this section is written so that nobody reads it as more than that.

12What Vega does not have

This is the complete list as of the effective date, not a selection.

• No certifications. No SOC 2, no ISO 27001, no penetration test report, no external security audit.
• No personal-information redaction. Section 3. Names, addresses, contact details, identifiers and health or financial details inside work content are stored as written.
• No zero-retention agreement with our model provider. Session text is sent to Anthropic under its standard commercial terms — at capture, and again at query time for every answer Vega gives you. There used to be a second provider, OpenAI, receiving the sanitised capsule for a search vector; that path was deleted on 19 August 2026 and embeddings now run inside Vega's own servers. One provider fewer is a real reduction and it is not the same thing as a retention agreement, which Vega still does not have. See the subprocessor list.
• No read-side access log and no per-item visibility inspector. Section 11.
• No signed Data Processing Agreement on offer. A draft exists and is with counsel; it is not something we can currently execute.
• No retention limit on content. Four short clocks exist (section 9); the content itself has none.
• No customer-visible access log. The staff action log exists and no customer can read it.
• No customer-selectable data residency. Everything runs in Tokyo. Section 17 of the Privacy Policy explains what that means for a European or Turkish user.
• No per-account encryption keys and no key rotation path. One key, held by us.
• No paid tier, and therefore no code that enforces the paid-content wall. The rule is stated in the Privacy Policy and is currently true only because no seat is paid.
• No benchmark, and no control that records an opt-in to one. Section 8.
• No delete path into the training store. A withdrawal is recorded and queued, not executed. Nothing is written there today, which is the only reason that is survivable.
• No organisation-level privacy controls. Every privacy setting belongs to the individual. A company administrator cannot turn capture off for their own company, and cannot see or change a member's settings.
• No self-hosted or on-premise option.

13What we are working on, in order

Stated so that this page can be checked against reality later, not as a commitment or a delivery date.

• A personal-information detector on the ingest path, and a decision about what it does when it fires — refuse, redact, or store and mark.
• Zero-retention terms with our model providers, which is now the difference between what section 5 says and what a customer expects it to say.
• A delete path into the training store, before that store is ever configured.
• A read-side access log and the per-item visibility inspector in section 11.
• A retention clock for content, with the number shown in settings.
• Row-level logging of staff reads, and database-level immutability on the staff log in production.
• Per-account key derivation and a rotation path.

14Reporting a vulnerability

Send it to help@tryvega.tech. We will acknowledge within five business days. We do not currently run a bug bounty and cannot offer payment. We will not pursue anyone who reports a finding in good faith, does not access, modify or retain data belonging to another person beyond what is needed to demonstrate the issue, and gives us a reasonable chance to fix it before publishing.