Trust
Security and EU data residency
You connect production agents to Vidimus. Here is where the data lives, how customers are kept apart, and how you can check our evidence yourself.
- Last updated
- Scope
- Document status
At a glance
- Customer data
- Stored in Frankfurt in the EU.
- AI processing
- Models hosted in the EU write and grade the tests and check the documents.
- Tenant isolation
- Row-level security on every customer table: a member’s requests reach only their own organisation.
- Audit trail
- The database refuses edits from every role, ours included. Each entry is chained to the one before, and the chain is checked every night.
- Evidence packs
- Signed and verifiable offline with the register line and our published key.
- Two-factor authentication
- Any member can turn it on, and an organisation can require it for every member.
- Support access
- No standing access. You grant it, it expires on its own, and every use is logged.
Documents for your vendor review
These are the documents a security or third-party risk review usually asks for. They state the same facts as this page.
- Data processing addendum
The Article 28 terms under which we process personal data for you, as a processor.
- Sub-processor list
Every third party that processes data for the service, what it does and where the data sits.
Informational. The contract and the DPA govern.
Where your data lives
Customer data is stored by Supabase in Frankfurt (eu-central-1). Every server function runs in Vercel’s Frankfurt (fra1) region, and an automated test fails if that setting is removed. Static files and the session check that runs before each page may be served from the Vercel edge location nearest the visitor. Vercel is a US company, so transfers are covered by Standard Contractual Clauses.
Our own AI calls go to Mistral AI (EU), and model-call monitoring runs in Langfuse (EU region). Both are covered by our data processing addendum. Emails sent through Resend (region provided on request) carry identifiers and counts, never prompts, replies or evidence documents.
Your agent
Reached through the interface it already exposes.
Vidimus application
Every server function runs in Frankfurt. Vercel is a US company. Transfers to it are covered by Standard Contractual Clauses.
Customer data
Frankfurt.
AI processing
Writes and grades the tests and reads your documents.
Model-call monitoring
Error monitoring
Email
Region on request. Resend receives identifiers and counts only and never prompts, replies or evidence documents.
Standard Contractual Clauses
The transfer mechanism in our data processing addendum.
Tenant isolation
Every request made for a signed-in member passes through row-level security, so it reaches only that member’s organisation. Composite foreign keys bind child rows to their parent’s organisation, whatever code writes them. Server code that needs wider access, such as test runs, scheduled jobs and some product actions, uses a service account that bypasses row-level security. That code scopes every query to one organisation. Policy tests run on every change and check that a member of another organisation sees nothing.
- Row-level security
- Every customer table carries an organisation id, enforced in the database.
- Cross-customer links
- Child tables are bound to their parent’s organisation.
- Policy tests
- A member of another organisation sees nothing, and this is checked in the database on every change.
- Evidence-pack files
- Stored under each customer’s own path, with the same membership check on read.
Integrity of evidence
Each evidence pack is a numbered version that cannot be changed: a re-issue is a new version. The SHA-256 of the PDF is recorded at issue and signed with Ed25519, using a key held in our vault, and a content fingerprint is printed on every page.
Our public keys are at /.well-known/vidimus-signing-keys.json, and retired keys stay listed. Give your auditor the PDF and its line from your evidence register: the hash and the signature check offline with no account.
How an evidence pack is verified
Artefact
A numbered version that cannot be changed.
Content hash
The hash of the PDF, recorded when the evidence pack is issued.
Signature
Made with a key held in our vault.
Published key
Retired keys stay listed.
Verification
From the PDF and its register line, the hash is recomputed and the signature checked against the published key. Members can also verify in the product.
Review decisions, control overrides, membership changes and evidence-pack exports go into an audit trail that nobody can edit afterwards, not even our own service account. Each entry is chained to the one before, the chain is checked every night, and its status is printed in every evidence pack.
- Audit trail
- Decisions, overrides, membership changes and exports.
- Immutability
- Database triggers refuse any change from every role, our own service account included. Rows are deleted only when an agent or a whole organisation is deleted.
- Chain
- Each entry is linked to the one before, per organisation.
- Chain check
- The result is shown in Settings and printed in every evidence pack.
- Export
- Members can read and export the trail, and each export is itself recorded.
Access and authentication
Each member is an owner, an admin, a reviewer or a viewer. One tested matrix says which role may perform each action, and the database enforces it again.
- Roles
- One matrix is tested against the written policy and enforced again in the database.
- Separation of duties
- A Needs review result is settled by a reviewer who did not start the run. The database enforces it.
- Passwords
- Checked against known leaks when a password is set or changed.
- Second factor
- Any member can add an authenticator app, and an organisation can require it for every member.
- Internal console
- Everyone needs a second factor to reach it, with no exception.
- Support access
- You grant it from Settings for a limited time. It expires on its own. Every grant is in your audit trail, and every use is in your support access log.
Application security
Every response carries strict security headers, every input is checked against a typed schema, and the code is scanned on every change.
- Content Security Policy
- Scripts run only with a nonce issued for each request.
- Transport and framing
- HSTS, frame denial and a restrictive Permissions-Policy.
- Input validation
- API routes, server actions and configuration are checked against typed schemas.
- Rate limits
- Sign-in and the public forms are rate-limited in the database.
- Code scanning
- Static analysis and secret scanning on every change, and dependency updates checked every week.
- Agent credentials
- The credentials you give us to reach an agent are stored in a vault. The application keeps only a reference.
- Application logs
- Logs hold identifiers only and never prompts, agent replies or secrets.
- Error monitoring
- Request bodies, headers, cookies and personal data are removed before sending.
Sub-processors
Processing is governed by our data processing addendum. We tell customers at least 30 days before any sub-processor is added or replaced.
Self-hosted deployment
On the Enterprise plan and on request, the same application runs on your infrastructure, with inference through Mistral’s EU platform, a Mistral self-deployment or vLLM running Mistral’s model weights. It is also how Vidimus reaches an agent that never leaves your network.
Certifications
Every control on this page runs in the product today.
Certifications: none held yet. ISO/IEC 27001 preparation is on the roadmap. Meanwhile we answer your security questionnaire: send it to us.
Responsible disclosure
Found a vulnerability? Write to security@vidimus.fr. We reply within two business days and take no legal action against good-faith research. Test only against your own organisation.
Data-protection requests: contact@vidimus.fr