Security and Governance

VAULTE · Last updated 22 July 2026

What protects your data and constrains what the system may do on your behalf. This page describes controls that are implemented. Where something is not yet in place, it says so.

Tenant isolation

Every record carries the organisation it belongs to, and every query is scoped to it. Row-level security is enabled on governed tables and access is granted only to the service role — anonymous and end-user database roles have no read path to customer data.

Email resources are additionally owner-scoped: access requires that the authenticated user owns the resource. Membership of the same organisation, an administrator role, or knowledge of a message identifier are each insufficient on their own. This is verified by an isolation suite that runs twelve hostile access attempts against the real schema.

Authentication

• Sign-in by emailed magic link, with signed session tokens.
• Passkey registration and authentication are supported.
• Sessions are bound to a device and can be revoked.
• Protected routes fail closed — an unauthenticated request is rejected or redirected, never partially served.

Authorisation

Roles determine which surfaces and actions are available. Founder-level policy and approval functions are separated from customer-tenant functions, and no agent process holds simultaneous unrestricted access to email, payments, deployment, and secrets.

Secrets

Integration credentials are stored using envelope encryption (AES-256-GCM) bound to the owning organisation, so a ciphertext moved between tenants will not decrypt. Secrets are held server-side only and are redacted from any content passed to a language model.

Payments

• Payments are processed by Stripe. Card details never reach our systems.
• Webhook signatures are verified; an unsigned or mis-signed request is rejected.
• Test-mode and live-mode events are isolated — a test event cannot activate a live account and vice versa.
• A paid account is provisioned only from a verified webhook event, never from a browser returning with a success parameter.
• Replayed webhook events cannot record the same payment twice.

Constraints on autonomous action

Limits are enforced in application code, not by instruction to a language model. Each intended action is recorded with its policy decision before the external call happens, so what was permitted is answerable afterwards without re-running anything.

Some actions are refused outright and cannot be authorised through the in-product approval queue:

• contacting a recipient after they have opted out;
• guaranteeing a commercial outcome;
• sending without an evidence-backed rationale;
• starting fulfilment before payment is verified;
• sending from a mailbox that has not passed configuration checks;
• acting on content identified as an attempted prompt injection.

Other actions — transactions above your ceiling, discounts above your cap, custom scope, contract changes, legal or security concerns — are queued for your decision with the evidence attached.

Untrusted content

Replies, websites, documents and provider data are treated as adversarial input. Content is stripped of credentials, scanned for instruction-injection patterns, and fenced so a model receives it as data to analyse rather than as instructions to follow. Suspected injection is quarantined and refused.

Emergency stops

A global stop halts all autonomous operation immediately. Scoped stops halt one mailbox, campaign, market, offer, customer, workflow, or integration while everything else continues. Stops are data, not deployments — they take effect on the next action, and the system can also arm them on itself when deliverability, dispute, quality, or duplication signals cross a threshold.

Audit history

Governed actions are recorded with actor, action, target, and metadata. Approval decisions, policy changes, and stops are attributable and timestamped.

Incident handling

Failures are classified by severity. Security and systemic incidents halt the affected systems, are escalated immediately, and are not resumed on the system's own judgement. An incident is not closed because a fix was deployed — closure requires the affected workflow to succeed, regressions to pass, and monitoring to confirm stability, with that evidence recorded.

Where an issue affects you, we will tell you what is affected and provide a workaround if one exists. We will not tell you it is resolved until validation has actually passed.

Data export and deletion

You may export your data at any time. After termination you may request deletion; we will confirm when it is complete. Records we are legally required to retain (for example transaction records) are kept for the required period and no longer.

What we do not claim

We hold no third-party security certification. We are not SOC 2, ISO 27001, or HIPAA certified and do not claim to be. We do not offer a contractual uptime guarantee at current price points. If your procurement requires a certification we do not hold, tell us before you buy.

Reporting a vulnerability

Email hello@vaultehq.com with “Security” in the subject. Please give us reasonable time to investigate before public disclosure. We will acknowledge receipt and tell you what we find.