Written to be checked

Request payloads are schema-validated at the boundary. File and import handling validates content before it is processed, and imports are size-capped.

All database access is parameterized. User input is never concatenated into SQL, and table and column identifiers coming from configuration are passed through an identifier allowlist.

Authorization is enforced at defined server-side enforcement points. The browser is never the authority on what a user may see; hiding an element in the interface is never the control.

Outbound connection targets are constrained, and redirect handling is controlled, so the platform cannot be induced to connect to arbitrary internal addresses.

Rate limits and abuse budgets apply to authentication and other sensitive endpoints. Background work runs through a managed job queue rather than unbounded request-time processing.

No third-party penetration test has been performed. Security review to date is internal: automated dependency scanning, static analysis, and mandatory tests covering tenant isolation. We will say so rather than imply otherwise.

Passwords are stored using scrypt with per-user salts. Plaintext passwords are never stored or logged.

Yes. An unverified account cannot be used.

Password recovery responses do not reveal whether an address exists. Reset, verification and invitation tokens are single-use, carried in URL fragments, and consumed and cleared immediately. They are never written to logs, analytics or persistent browser storage.

Roles govern access within an organization, and permissions are enforced server-side on every request rather than assumed from the session.

MFA is not implemented today. This is the largest identity gap in the platform and it is on the roadmap. If MFA is a hard requirement for your organization, tell us before you buy rather than after. We would rather lose the deal than have you discover it in month two.

SSO and SCIM provisioning are not implemented. They are expected to arrive with, or shortly after, MFA.

Sessions expire on a configured lifetime and are revalidated server-side.

Every tenant-owned record is scoped to its organization. Isolation is covered by mandatory automated tests rather than by convention, so a change that breaks it fails the build.

No, and this is deliberate. Every connector issues read queries and schema lookups only; no code path writes, updates or deletes anything in a connected system. A read-only account is sufficient, and is the account we would rather you used.

Yes. Evaluating an interaction requires holding it. Transcripts, the evaluations derived from them and the resulting workforce performance data are stored in Merivex's database, isolated per organization. A durable object-storage archive for transcripts older than the plan's hot history window is being introduced as a second tier; the storage provider is named in the subprocessor register and is not yet live. Any quality product that analyses conversations holds them; a vendor claiming otherwise is describing something else.

Data subject export is a supported operation, produced as a structured archive, with the request recorded in audit history.

Deletion issues real deletes across interactions, derived evaluations, coaching plans, pattern evidence, executions and the memory built from them, not a hidden flag on a row that stays in the table. Deletion is supported down to a single person's data and up to an entire organization.

Retention is a plan-level entitlement. Each plan carries a maximum history window (12 months on Starter, 24 on Growth, custom on Enterprise). A retention policy cannot be configured to keep interaction or evaluation data longer than that window; every configured retention run is clamped to it; and a daily sweep applies the ceiling to organizations on a bounded plan even when they have never enabled a policy of their own. Policies can be previewed before they execute, and every execution is recorded in audit history and an append-only deletion ledger.

Administrative actions are written to an append-only audit log, scoped per organization.

A full draft DPA exists — controller/processor terms, SCCs for international transfers, a technical-measures annex and a subprocessor annex — and is in legal review. It is not yet available for signature. If you need one in place before connecting data, contact us and we will tell you the honest timeline.

Connection credentials are encrypted with AES-256-GCM before storage, and are never returned to the browser, not to an administrator, and not in an API response.

The credential encryption layer accepts multiple keys so that a new key can be introduced and old material decrypted during rotation.

Traffic to the application and API is served over TLS. Outbound connections to customer databases verify TLS certificates by default; private certificate authorities are supported explicitly rather than by disabling verification.

Storage-level encryption is provided by the managed hosting platform. Merivex does not additionally encrypt transcript content at the column level, and customer-managed encryption keys are not offered today.

Secrets and credentials are excluded from application logs. Configuration is schema-validated at startup, so a misconfigured deployment fails to start rather than starting insecurely.

Yes. Interaction content is sent to a third-party inference provider to be analysed. The provider is named in the subprocessor register below. This is the single most important disclosure on this page for a regulated operation, which is why it is not buried.

The provider is configurable to any OpenAI-compatible endpoint, so a self-hosted or in-tenant model endpoint is supported at the deployment level. Selecting a provider per customer organization is not yet available. Ask us if you need it.

Merivex does not train models on customer data. Content is sent for inference only. We do not control the retention terms of the upstream provider, so we will not make claims on their behalf. The provider is named below so you can assess them directly.

They do not hold privileged access. Each agent is restricted to an explicit set of tools and explicit memory read and write scopes, and operates inside the same tenant isolation and authorization model as a human user, with no bypass.

A dedicated verifier agent challenges conclusions and flags claims the cited evidence does not support. Every evaluation cites the interaction and the turn it came from, so a conclusion can be checked by a person rather than trusted.

A validated backup of the production database runs automatically every day, in addition to the backups taken by the managed database platform. The job asserts that the dump was produced and is well-formed rather than assuming it succeeded. Copying those validated dumps into separate object storage is implemented behind a configuration flag and is not yet enabled.

A restore drill is scripted and has been exercised locally. It has not been rehearsed as a timed production exercise with a documented recovery objective, so no RTO or RPO is claimed.

No formal incident response plan is documented. Merivex is a very small team; incident handling today is direct and undocumented. Writing this down is a near-term task and we will not pretend it is finished.

There is no contractual notification window in place yet, because the DPA that would carry it is still in preparation. Our stated intent is to notify affected customers without delay and with specifics rather than reassurance.

There is no staffed security operations centre. Alerting is automated; response is business hours by a small team.

No. Merivex holds no third-party security certification, and nothing on this site should be read as one. If your procurement process requires a certification as a hard gate, we do not meet it today and will tell you so at the first conversation rather than the last.

Automated dependency alerting is enabled on the repository, and dependency updates for known vulnerabilities are raised automatically.

Yes. See the disclosure policy below. Reports go to a monitored address and reporters acting in good faith will not be pursued.

No paid bounty programme exists. Reports are still welcome and will be credited if you would like.

Yes. The register below lists every third party that may process customer data.

No. Merivex is an early-stage company without a dedicated security function. Security is handled by engineering, which is the honest answer for a company of this size.