Security Built for Regulated Markets
EthicVault is designed to satisfy the most demanding regulatory and infosec requirements in financial services — not as an afterthought, but as the foundation.
Zero Custody
The Friction Gate operates entirely within your deployment boundary. Audit logs, policy rules, and execution records are stored in your infrastructure — EthicVault never has custody of your data.
Tamper-Evident Governance
Every governance decision is cryptographically signed at the moment of execution and chained to the one before it, so any later alteration is detectable — giving regulators verifiable evidence of the disposition reached and the controls applied.
Deterministic by Design
The Friction Gate uses rule-based logic — not probabilistic ML models — to make governance decisions. The same input always produces the same output, making it auditable and explainable.
What is certified, what is designed, and what is not yet either
Our own white paper argues that claimed, implemented, measured, reported, independently verified, and production-ready are different statements that must never be collapsed. That rule has to bind us first.
“Trust rises when the evidence label is as precise as the technical claim.”
| Framework | Status | What this does and does not mean |
|---|---|---|
SOC 2 Type II AICPA | Architected for assessment | A Type II report requires an observation window over a live production system. The architecture and control set are built to enter one; the window opens with commercial release. We hold no SOC 2 report today, and none is available under NDA or otherwise. |
ISO 27001 ISO/IEC 27001 | Architecture aligned · ISMS drafting | The architecture is built against the ISO 27001 control set. The ISMS as a management framework — written policies, risk register, records — is still being drafted and is not yet in an auditable state. No certificate exists, no accredited body has audited any scope, and we do not claim a print-ready policy set today. |
GDPR Article 32 EU 2016/679 | Designed to | The architecture is designed against the Article 32 technical and organisational measures, and the zero-custody model is the main reason. Design intent is not a compliance determination, and no supervisory authority or auditor has assessed it. |
DORA EU 2022/2554 | Designed for | Built for the ICT risk-management obligations financial entities carry under DORA, including the evidence an Article 11 response has to produce. DORA binds financial entities, not us. We can supply evidence towards your obligation; we cannot discharge it. |
If any line above changes, it changes here first and in the same words. A status will never be upgraded on this page before the underlying artefact exists.
We do not run compliance theatre
A SOC 2 Type II report or a penetration test against a system that is not yet in live production would be a document, not evidence. Our whole argument is that claimed, implemented and independently verified are different words. We are not going to break that rule to decorate this page. The architecture is engineered for these audits; they begin when the system carries real traffic.
Artefacts a security review will ask for
Listed whether or not they exist yet, because the absence of one is itself something a reviewer needs to know early rather than late.
| Artefact | Status |
|---|---|
| Responsible disclosure policy Published at /.well-known/security.txt with a contact address and preferred language. | Available |
Data Processing Agreement Issued per engagement once the processing scope is defined. Not a standing document. | On request |
Service level agreement Shaped by deployment model and assurance obligations. See how we price. | Per engagement |
Sub-processor list The engine reads, evaluates, signs and then permits or blocks. Customer payload and personal data are never retained; what the WORM chain holds is cryptographic proofs and dispositions. The list is therefore minimal by architecture, and is published in full, with change notification, before any customer data is processed. | Zero-payload custody by design |
ISMS approach The administrative layer — HR, device management, standard access reviews — is run through a compliance-automation platform for coverage. The engine controls — the friction gate, zero-payload custody, the deterministic decision path — are authored by hand, because off-the-shelf cloud compliance templates assume a system that stores customer data and do not fit an architecture built not to. | Hybrid — automated + hand-authored |
Penetration test summary A test against a staging shell proves little. It runs against the production environment at general availability, and the summary and scope are published here. | Scheduled for GA |
Public status page A status page reports on a production service under SLA. It goes live with the first one. | At GA |
What holds today, and what is engineered for GA
These are properties of the engine as it stands, demonstrable now — three of them in the demonstrator itself.
Deterministic decision boundary
- No probabilistic model sits in the release decision path
- The same bounded request, policy state and evidence set produce the same disposition
- Every disposition carries the reason codes it can be checked against
Zero-payload custody
- Customer payload and personal data are never retained
- What the WORM chain holds is cryptographic proofs and dispositions, not content
- Customer data is never used to train or tune a model
Tamper-evident audit chain
- Hash-chained, append-only decision ledger
- Each record binds a SHA-256 certificate hash to the policy hash it was decided under
- Re-running a decision reproduces a byte-identical certificate
The platform controls below are designed and will be active when the system carries production traffic. They are listed as target architecture, not as controls operating today. SOC 2, penetration testing and the SLA are tracked in the assurance status above, not repeated here.
Transport & storage
- TLS 1.3 in transit, enforced with no downgrade
- AES-256 at rest across storage layers
- Tenant-isolated key management, with BYOK
Access & identity
- SSO via SAML 2.0 and OIDC for enterprise accounts
- Hardware MFA for privileged access
- Role-based access control on a least-privilege model
Resilience & operations
- Multi-region deployment with automated failover
- Examiner-ready regulatory export
- SIEM integration via webhook or syslog
No data leaves your environment without your explicit authorization.
The Friction Gate operates entirely within your deployment boundary. Audit logs, policy rules, and execution records are stored in your infrastructure — EthicVault never has custody of your data.
Our own gate failed four out of four, and here is what we changed.
Published because a disclosure policy with no record behind it asks you to take the posture on faith. This is the most important negative result in our prototype evidence, in the report's own words.
- What we assumed
That harmful behaviour would always arrive through a tool name we had already registered as restricted. The gate classified by name and denied what was on the list.
- What happened4 / 4
Four harmful actions whose effects were not represented in the restricted-tool registry bypassed the gate in every tested case. The report records this as a genuine prototype failure and states plainly that tool-name classification alone is not a sufficient execution-control boundary.
- What changed
A default-deny allowlist, effect-based egress control, and authority-bound release — the posture the report calls Phi-Invariant. Disposition binds to canonicalised arguments, target, authority, proof and policy version, not to a label.
- On regression0 / 4
The same four cases were re-run against the new posture. None bypassed.
The question the gate now asks
Not “is this tool name on a denylist?” but “is this exact effect, target, authority, evidence state and release path explicitly allowed?” The proposing agent does not get to classify its own action as safe.
Scope, stated as the report states it: this is regression evidence for four repeated cases, not universal exploit resistance. Prevention of unknown or zero-day harmful effects is listed as not supported. Independently authored attack variants, covert channels, and adversarial trace shaping remain untested.
Responsible Disclosure
If you believe you have discovered a security vulnerability in EthicVault systems, please disclose it responsibly. We commit to acknowledging valid reports within 48 hours and resolving critical issues within 14 days.
Report a Vulnerability