Skip to content

Security and access

Production control without hidden production actions.

Synvolv is designed for sensitive operational and commercial context. Access, approvals, data collection, execution and audit are explicit at every layer — and where something is not yet true, this page says so.

The access model

Nothing is granted by being connected. Authority is added one rung at a time and every rung is revocable.

  1. 01ShadowReads
  2. 02Approved actionsActs with approval
  3. 03Synvolv GatewayIn the request path
How authority is granted, rung by rung
Read and write are separate
Observation runs on read-only access. Production-action permissions are a different grant entirely, made when the team is ready and not before.
Every action is previewable
A natural-language request becomes a typed plan with exact scope, thresholds, approvers, execution method and rollback path — reviewed before anything executes.
Role-based access
Fixed roles, no custom roles yet. A viewer is read-only, and each write has its own permission.
Audit logs
State changes and grants are logged with the person who made them.
Minimal GitHub permissions
"permissions": {
  "contents": "read",
  "metadata": "read",
  "issues": "write",
  "pull_requests": "write"
}
API keys
Keys can be created and revoked. There is no one-step rotation yet.

Shadow mode

See what Synvolv would decide before it can touch anything.

Shadow mode is read-only. Synvolv reads a copy of what production already does, replays your next change against it, and shows which customers would move, which would stay, and why. Nothing changes for your users until you approve it.

Shadow reads from

  • GitHubGitLabGitHubthe pull request: what is about to change
  • OpenTelemetryProduction telemetrywhat ran, for which customer
  • StripeHubSpotCustomer identityplans, entitlements, contracts
  • BraintrustEvaluation / outcome signalshow it scored, how it resolved
  • Configuration historyprompts, models, tools and rules over time

Connect what you already run. Availability is confirmed per connector during setup.

Shadow

Synvolvread-only copy

Reads a copy of what production already does. Writes nothing back.

  • Review changes.
  • Replay historical scenarios.
  • See affected customers.

No write path to production

Would have decided

  • AcmeMoveinside threshold
  • Meridian HealthStayprovider policy
  • VelaReviewnot enough replay coverage

Your data

The least Synvolv can hold and still be useful is the amount it should hold.

YOUR STACKapp · telemetry · model providerTLS · PUBLIC ENDPOINTSSYNVOLV · AWS US-EAST-1request metadataquestions asked of Ask Synvolvprovider keys · AES-256-GCMAPI keys · hashedprompt bodies · never stored
Hosting
AWS us-east-1, in one region — or your own VPC, or self-hosted.
In transit
TLS on public endpoints.
Stored secrets
Provider keys are encrypted with AES-256-GCM. API keys are stored hashed.
Your provider keys
On the Gateway, your model-provider keys are stored encrypted and used per request.
Prompt content
The gateway stores metadata only, never prompt bodies. Ask Synvolv keeps the questions asked of it.
Deletion
Soft delete only. There is no account-deletion path yet.

The boundary we will not blur

Metadata-only mode can analyse cost, latency, errors, loops, usage, customer attribution and configuration drift. It cannot reliably judge semantic quality. That needs content access, redacted content, evaluation datasets, existing evaluation results, or customer-hosted evaluation — your choice which, and a real decision rather than a default.

What a security reviewer asks.

Answered plainly, including the ones where the answer is no.

Is any of this independently verified yet?

No. The controls above are real and we will walk you through them in the architecture review, but nothing on this page is third-party attested today. Treat it as a description of how the system is built, not as an audit.

What access does the first engagement actually need?

A read-only credential against a trace source you already emit, and the field that identifies the account on a request. That is enough to produce the first customer-impact review. No gateway change, no code in the request path.

Is Synvolv in the request path?

Not to start. Shadow mode reads what your telemetry already records. Synvolv Gateway sits in the request path, and only if you choose it.

Can Synvolv change anything in production on its own?

No. Every production action is a separate, scoped, revocable grant that a person approves, and the review reports a status rather than merging or deploying. Your branch protection decides what a held check means.

Can we self-host, or run this in our own VPC?

Yes. Synvolv runs in your own VPC or self-hosted, and we support both.

Who at Synvolv can see our data?

Access is role-based and least-privilege, and during beta every engagement is run with our team, so a named person is working with you rather than an anonymous support queue. We will tell you who that is.

How do we report a vulnerability?

Email security@synvolv.com. During beta there is no public bug-bounty programme; reports go to a person, not a triage queue, and you will get a reply.

Find out who it changes before your customers do.

Request a reviewJoin the private preview

It starts read-only, in shadow mode. Nothing changes in production until a person approves.