Security-by-design for the control plane.
OVAAL sits between your product and the providers that execute regulated services, so the control plane is built with access controls, audit logging and incident-response processes from the start. This page is the public overview. Deeper evidence is shared on request, and the most sensitive material under NDA.
How the control plane is secured.
Five principles shape every part of the platform. We describe the approach here; specific configurations and thresholds are documented in the materials we share under NDA.
- Non-custodial by default. Signing authority stays end-user-side. OVAAL and the partner do not hold end-user keys or funds. Custody, where applicable, sits with the partner or an authorised provider. See the non-custodial architecture for how this works.
- Least-privilege access controls. Human and machine access is scoped to what each role needs. Delegated access is time-boxed and revocable. Administrative access requires multi-factor authentication.
- Audit logging by design. Each material action produces an event record, so an instruction can be traced from authorisation through to receipt. Audit-log export is available to partners.
- Key management discipline. Production secrets are held in managed key stores, kept out of source control and logs, and rotated on a defined schedule. The detail is documented under NDA.
- Segmentation and isolation. Production environments are isolated, and access paths are controlled and monitored. The threat model that informs this is shared under NDA.
Security assurance.
Our security program is independently reviewed and documented. Compliance documentation, security evidence, and the latest review reports are shared with partners under NDA.
| Programme | Status | Notes |
|---|---|---|
| Smart-contract review | Active | Independent review of the proof-rail contracts. Reports shared with partners under NDA. |
| Penetration testing | Active | Independent testing programme. Reports available under NDA. |
| Responsible disclosure | Active | Published reporting channel and coordinated-disclosure process. |
What you can see, and when.
Trust documentation is tiered. The overview is open; working evidence is shared once we know who we are talking to; the most sensitive material requires an NDA.
| Tier | What you get | Access |
|---|---|---|
| Public | This security overview: principles, security assurance, disclosure process. | Open |
| On request | DPA template, completed security questionnaire, sample audit-log export. | After a request, with basic qualification |
| Under NDA | Penetration-test reports, threat model, and key-management documentation. | NDA-only |
We keep detailed threat models and control thresholds off the open page on purpose. Ask and we will share the right tier for where you are in the process.
Incident response.
A defined process governs how we detect, triage, contain and communicate security events, and how that work is shared with affected partners.
- Detection and triage. Events are assessed against severity criteria, with clear ownership for response.
- Containment and remediation. A documented playbook guides containment, fix and verification.
- Partner communication. Affected partners are notified in line with the incident terms in the DPA and MSA. A joint incident runbook is agreed with partners in paid tiers.
Responsible disclosure.
If you believe you have found a security issue, email [email protected]. A PGP key is published at /.well-known/pgp-key.asc.
We aim to acknowledge a report within one business day and to share a triage assessment and remediation plan after we have reviewed it. We coordinate disclosure with the reporter and recognise researchers who report responsibly.
Walk through it with our team.
Book an architecture review and we will cover the security model, the responsibility split, and which trust documents fit your stage. Prefer to read first? The integration brief is a one-page PDF.