Skip to main content

​
How do you make sure only approved code can access keys or run the policy engine?

Each secure instance proves what code it is running by presenting a measurement hash. Key wrapping and access policies are tied to that measurement. New instances must prove they match the expected code before they can unlock keys or participate in signing. This prevents tampered code from getting access and allows safe autoscaling.

​
How are software upgrades handled without compromising control?

Upgrades follow a staged path: build, verify, test in a small canary, then roll out. Builds are reproducible, checksums are published, and attestation checks are enforced. Customer environments can require co-approval and a PIN for an approved measurement. If something looks wrong, rollbacks are documented and pre-tested.

​
What prevents UI tampering or label spoofing from causing a bad signature?

Approvals are based on a verified intent and an enclave-compiled payload, not on labels in the UI. The engine validates the raw destination, asset, amount, and calldata, then re-simulates the call before allowing any signature. Hash-chained audit logs make selective tampering or censorship detectable.

​
What Software Supply Chain (SLSA) level do you meet?

In practice, our supply-chain controls are designed to meet the higher end of SLSA (Level 3+). All code and infrastructure definitions live in GitHub with strict branch protections, mandatory peer review, CI-enforced tests, and staged rollouts from staging to production with full change logging and rollback plans. For the enclave and policy-engine components, we use deterministic, reproducible builds from an open build specification and publish build hashes to a public blockchain so customers can independently verify they are running the expected binary. We also apply formal verification techniques for critical components rather than relying only on testing or traditional audits. If you need it, we can provide a control-by-control mapping to the SLSA version their security team uses and arrange third-party attestation.

​
Do you support mTLS and IP allowlisting for API clients?

Yes, we use mutual authentication at the application layer, which in practice is stronger than classic certificate-based mTLS and easier to operate. Each API user registers a public key with PrimeVault, keeps the private key in their own secure environment or KMS, and signs every API request. The platform verifies the signature before processing the call, and we can optionally support fully customer-encrypted payloads so PrimeVault cannot inspect the contents. Additionally, you can restrict network access with IP allowlisting under Settings → IP Whitelist, allowing only requests from your specified server IPs to be accepted by our API gateway. In combination, signed requests, optional end-to-end encryption, and IP allowlists provide the same or stronger guarantees than traditional mTLS. If a regulator or internal policy explicitly requires certificate-based mTLS, we handle that as an enterprise deployment requirement and work with your security team to design the exact setup they need.