Security at Vektrum
Vektrum is authorization infrastructure. This page describes what data we store, how credentials are secured, and how the audit and access control layers are designed for tamper-evidence and auditability.
Vektrum has not obtained SOC 2, ISO 27001, PCI, or any other formal certification. The controls described here are designed for those goals but have not been independently audited. Institutional clients should request our security documentation for due diligence.
What Vektrum stores
Deal metadata
Deal title, parties (contractor and funder IDs), total amount, milestone definitions, status, and conditions. This is the core governance record.
Hash-chained audit log
Every action taken on every deal — release authorizations, approvals, status changes, admin overrides, and partner confirmations. Each entry includes a hash of the previous entry, making retroactive tampering detectable. Append-only: no UPDATE or DELETE path exists at the application layer. A database trigger enforces this at the DB layer.
Release conditions
The pass/fail state of all 10 conditions at the exact moment a release was authorized. Permanently logged, cannot be altered.
Partner webhook delivery outcomes
For each outbound webhook: delivery timestamp, HTTP response code, retry count, and whether the partner confirmed or failed the release.
API key prefixes (SHA-256 hash only)
The full plaintext API key is never stored after issuance. Only the SHA-256 hash is stored for lookup. The key prefix (first 12 characters) is stored for display purposes only.
What Vektrum never stores
Fund balances or cash positions
Vektrum is authorization infrastructure, not a ledger for real money. Funded balance in Vektrum tracks authorization capacity — actual funds are held by Stripe or your institutional payment partner.
Contractor bank account numbers or routing numbers
Stripe Connect holds contractor banking details for Stripe-rail deals. For external-rail deals, your payment partner holds this information. Vektrum stores no banking credentials.
Full API keys after issuance
Partner API keys are shown once at issuance (vkp_<64-hex-chars>). After you close the issuance dialog, the plaintext key cannot be recovered from Vektrum. Only the SHA-256 hash is retained.
Webhook signing secret handling
Outbound partner webhook signing requires a retrievable signing secret — the signature for each delivery is computed at request time, so the secret cannot be one-way hashed. This is different from API keys, which are hashed at rest and shown once at issuance.
- Server-side only. Webhook signing secrets are never sent to client code. They are read by the signer process running on the server and are not exposed in any browser-visible response.
- Restricted access. The secret is stored in the partners table with row-level security. Only the partner's administrative session and Vektrum's server-side signer process can read it; no public or contractor session can.
- Issuance. Partners receive their secret once at creation. They can request rotation on demand via the admin dashboard.
- HMAC-SHA256 signing. Every outbound webhook is signed with HMAC-SHA256 over the request body and delivery timestamp. Verified deliveries reject signatures older than 5 minutes.
Roadmap
Encrypted-at-rest secret storage backed by a KMS (e.g. AWS KMS, GCP KMS) is on the security roadmap. Today the secret is protected by row-level security and database-level access controls; future releases will add envelope encryption with a managed key service. We do not currently claim KMS-backed storage.
API key security
Key format
vkp_ prefix + 64 hex chars = 68 chars total
Storage
SHA-256 hash stored — plaintext shown once and discarded
Recovery
Not possible — rotation issues a new key and invalidates the old one immediately
Rotation authority
Admin + active MFA session required to issue or rotate
Because only the SHA-256 hash is stored, a compromised Vektrum database does not expose partner API keys. An attacker with DB read access cannot derive the original key.
Webhook security
X-Vektrum-Signature: t=<unix_ts>,sha256=HMAC-SHA256(<ts>.<body>, secret)
All outbound webhooks are signed with HMAC-SHA256 using a partner-specific signing secret. The signature covers both the timestamp and the raw request body, so any modification of the payload invalidates the signature.
Replay protection: Partners should enforce a 5-minute (300-second) tolerance window on the t timestamp. A webhook delivered more than 5 minutes after its timestamp should be rejected as a potential replay attack.
Signing secrets are distinct per partner and rotatable on demand from the admin dashboard. Rotation takes effect immediately — the previous secret is invalidated.
Access control
Platform operations, partner management, audit export, manual overrides. All write actions require active MFA (AAL2). Admin cannot trigger milestone releases.
Fund deals, approve milestones, trigger releases. MFA required for release actions. Can only see deals they are the funder on.
Create deals, submit draw packages, upload documentation. Cannot approve or release. Can only see their own deals.
Row-level security: Enforced at the database layer via Supabase RLS policies. Users can only query rows for deals they are a participant on. Admin actions bypass RLS only via the service-role client, which is never exposed to the user session.
MFA: Admin and funder roles require TOTP second-factor authentication (AAL2) for all write actions that affect fund movement or governance state.
Audit log
Append-only by design
A database trigger fires on any UPDATE or DELETE on the audit_log table and raises an exception (SQLSTATE 23001). There is no application-level path to modify or remove a logged entry.
Hash-chained entries
Each audit entry includes a hash of the previous entry. Retroactive insertion or modification of historical entries would invalidate the chain from the tampered point forward.
Actor attribution
Every entry records actor_id, actor_role, and system_source. Admin write actions are dual-logged to a separate admin_audit_log with a written justification.
Exportable per deal
The full audit log for any deal can be exported via the admin API (GET /api/admin/deals/:id/audit-export) in JSON or CSV format. Export events are themselves logged.
Server-side enforcement
The 10-condition release gate is evaluated atomically on the server. Client state is display-only — no client-side flag can bypass or influence the gate result. The gate runs in a single server-side call before any fund reservation or Stripe transfer is initiated.
For security inquiries, vendor due diligence packages, or penetration test scope discussions, contact operations@vektrum.io.