Security & data handling
Symvanta is graph-first by design. We parse your repositories into a knowledge graph and, by default, discard the source. This page covers how that pipeline works, what we encrypt, where we run, the permissions we request, and how we handle incidents.
Every repository you connect flows through the same four steps. The output we keep is the graph: symbols and the relationships between them.
Stored source is an optional, paid add-on. It is never on unless you explicitly turn it on. When you do, Symvanta retains your indexed checkout in that same in-memory store, isolated to your workspace, so raw-file tools (read_file, grep, tree) work for CI, chat, and headless agents. It is never copied to a persistent disk, and turning the add-on off stops those tools from serving it. Even with it on, your code is never shared across tenants and never used to train models.
When an agent makes uncommitted edits queryable with index_working_tree, those file contents are indexed into a short-lived revision that is reclaimed within a few hours and scoped to your workspace.
Every connection is encrypted with TLS 1.2 or higher: your browser to the app, your agent to the MCP endpoint, our services to GitHub, and our internal service-to-service traffic.
Sensitive secrets (OAuth client secrets, per-tenant GitHub credentials, and 2FA recovery codes) are encrypted with AES-256-GCM before they are written to the database. The encryption key lives in the runtime environment, separate from the database, so a database read on its own does not expose those secrets.
The three columns that can carry code (nodes.source_snippet, project_files.search_text, and project_files.identifier_lines) are encrypted per value with AES-256-GCM before they are written. By default the data key that protects them is a Symvanta key: an envelope key in AWS KMS wraps it, and the unwrapped copy lives only in the running process. Pro and Enterprise workspaces can replace that key with their own.
On Pro and Enterprise you can point Symvanta at a key you control: AWS KMS, GCP Cloud KMS, Azure Key Vault, or an HTTPS key endpoint you run yourself. Symvanta generates a data key for your workspace, asks your key service to wrap it, and stores only the wrapped blob. To read your code Symvanta must ask your key service to unwrap that blob. The unwrapped key is held in memory for ten minutes at a time and then dropped, so revoking access makes the workspace unreadable within ten minutes. Every unwrap is a real call to your key service, which means it lands in your own audit log (CloudTrail, Cloud Audit Logs, Azure Monitor, or your endpoint's log), and Symvanta shows you the same list in the workspace.
kms:Encrypt, kms:Decrypt, and kms:DescribeKey on that key alone. Add a condition on the encryption context so the credential works only for your workspace and key reference. Symvanta needs the key ARN and the access key. An alias is not accepted, because an alias can be repointed at a different key without Symvanta seeing it.roles/cloudkms.cryptoKeyEncrypterDecrypter on that key alone. Symvanta needs the key resource name and the service account JSON.wrapKey, unwrapKey, and get key permissions on it. Symvanta needs the key URL, the directory (tenant) ID, and the application ID with its client secret.POST {base}/v1/wrap with {dek: base64, context: {symvanta_tenant, key_ref}} answers {wrapped: string}.POST {base}/v1/unwrap with {wrapped, context} answers {dek: base64}.GET {base}/v1/health answers 200.Authorization header. The endpoint must be HTTPS on a public host and must not redirect: Symvanta treats a 3xx as a refusal.Revoking the credential or disabling the key at your key service cuts Symvanta off. Within ten minutes the tools that read source return an error, indexing refuses to start, and your team sees a banner in the workspace. Restoring access brings the workspace back within the same ten minutes; nothing is lost in between.
Symvanta rotates the workspace data key once a year, and you can rotate it on demand. A rotation wraps a new data key with your key service and re-encrypts the workspace under it in the background, with progress shown in the workspace. The old key is retired once that finishes.
A revocation drill has Symvanta refuse its own unwraps for ten minutes without touching your key service, so you can watch the workspace fail closed and confirm the behavior on your own schedule.
Under the customer key: the three Postgres source columns and Qdrant payload.body. Not under it: project_files.search_tsv and project_files.identifiers (not written at all when strict mode is on), summaries text, the vectors, Redis answer and summary caches, messages in flight, logs, git clones on disk (unless strict mode is on), backups beyond those columns.
Strict mode is a per-workspace switch. With it on, Symvanta skips the plaintext search derivations and deletes the repository checkout after every index run. Identifier and full-text search fall back to slower tiers, and the raw-file source tool is unavailable: it answers source_unavailable_strict_mode, so the agent reads the file from your own clone.
Symvanta runs on Hetzner in Germany, so your data is processed and stored in the EU. The platform is built from a small, well-understood set of datastores:
None of these datastores is reachable from the public internet. They sit on a private network behind a firewall that only admits the application tier, so the graph and embeddings cannot be queried directly from outside.
The AI features (symbol summaries, semantic-search embeddings, and graph answers) run on open models: Gemma 4 for text and Nomic Embed Code for vectors, on GPU workers Symvanta operates in the EU. Your code is never used to train or fine-tune any model.
The full list of vendors that touch production data, and what each one handles:
We request the minimum each integration needs, and you can see the full list before you approve it.
You connect Symvanta through a GitHub App, installed only on the repositories you choose. The App requests:
Per-tenant GitHub credentials are encrypted at rest. The optional automated-fix add-on additionally requests permission to open pull requests: it opens draft pull requests for your review, and merging is always your call. GitHub shows you the exact permission list on the installation screen before you approve, and you can revoke access at any time from your GitHub settings.
If you sign in with Google we request only the openid, profile, and email scopes, used solely to create and authenticate your account. We don't request access to Drive, Gmail, Calendar, or Contacts, so we have none. See our Privacy Policy for the full detail on Google user data.
mcp:read).Production is monitored continuously with metrics and error tracking, so anomalies surface quickly. If you believe you have found a vulnerability, email security@symvanta.com with the details and we will work the report promptly. Please give us a reasonable window to remediate before any public disclosure.
If an incident affects your data, we will investigate, contain it, and notify affected customers without undue delay, consistent with applicable law.
Disconnect a repository and its graph is removed. Request account deletion by emailing info@symvanta.com and we remove your data within 24 hours. For self-hosted requirements, an on-premise deployment keeps the entire pipeline inside your own infrastructure.
We'll walk through architecture, data flows, and access controls in as much detail as you need.