For security teams
This is the architecture page for the security team. HiveSilo runs each customer in a dedicated, hardware-attested confidential-compute enclave, seals every sensitive payload with modern cryptography, ships only reproducibly built and signed images, and proves it can be verified independently. The promise is not a policy. It is enforced in hardware, in code, and in a supply chain you can inspect. Intelligence without custody.
At a glance
Written for the people who say no
This page is for the CISO, the head of security architecture, the privacy counsel, and the procurement reviewer who have to assume the vendor will eventually be breached and design accordingly. The architecture below is built on a single premise: a vendor you have to trust is a vendor that can hurt you. So we removed the trust requirement. Your sensitive data is sealed inside a hardware boundary that the cloud operator, the hypervisor, and HiveSilo itself cannot read, under keys you can hold, on images you can verify down to the measurement. Everything here is described at the status it actually holds, live, rolling out, in progress, or scheduled, because in a security review, an unverifiable claim is worse than a gap.
The threat model
Most security postures protect the perimeter and then trust everything inside it, the host, the hypervisor, the database admin, the vendor's own staff. For ultra-high-net-worth client data, that residual trust is the liability. Our architecture is designed to hold even when the surrounding infrastructure does not.
Confidential compute on hardware TEE means the cloud provider, the hypervisor, and HiveSilo cannot read enclave memory. The trust boundary collapses to silicon you can attest, not an organization you have to believe.
The shared platform processes anonymous behavioral signals only. Raw contact details, addresses, and IPs stay sealed enclave-side under your keys. You cannot lose, leak, or be subpoenaed for data you never held.
Where judgment fails, the system denies rather than exposes. Sensitive operations emit tamper-evident, non-PII receipts so that what happened is verifiable after the fact without revealing what was processed.
Attestation, signing, transparency-log entries, SBOMs, and measurement reproducibility are exposed so your team verifies our architecture rather than trusting our marketing. The Trust Center is live.
Why this is the existential control for your buyer
For an enterprise whose growth depends on the trust of ultra-high-net-worth clients, a single data incident is existential at once: legal, regulatory, and reputational. The only way to make a vendor relationship safe at that altitude is to make the vendor incapable of exposing the data in the first place. That is the design goal of everything below. Read: the AI-era data liability
Out of scope & residual risk
No architecture eliminates every risk, and pretending otherwise would disqualify this page with exactly the audience it is written for. This design does not defend against: a compromised buyer endpoint or browser on your own site; a malicious insider at your organization using legitimately granted access; a catastrophic TEE-class hardware vulnerability, mitigated by continuous patching and attestation-measurement rotation, not eliminated; and lawful process served on your own infrastructure, which holds your data because it is yours. What the architecture does guarantee is narrower and provable: HiveSilo, its cloud operator, and its staff are outside your data's trust boundary, and you can verify that claim rather than take it.
What we deliberately do not publish
Everything above is verifiable through attestation, signatures, and the evidence room without being scrapeable from this page. If we will not expose our own methods to a scraper, you can trust how we treat yours.
Confidential compute
Every customer runs in its own confidential virtual machine inside a hardware-attested Intel TDX trusted execution environment. CPU and memory are hardware-encrypted and isolated from the host. Scoring, CRM dispatch, the intelligence layer, and the Privacy Center all execute inside that boundary, under the customer's keys.
Each customer runs in a dedicated confidential-compute enclave on hardware TEE. CPU and memory are hardware-encrypted and isolated from the host, so scoring and all sensitive work happen inside your enclave, with your keys. Intelligence without custody.
Every enclave proves itself with hardware attestation (Intel TDX, DCAP-verified, measurement-pinned) over a dedicated attestation endpoint before any data flows. You can independently confirm you are talking to genuine, measured confidential-compute hardware running the expected image, not a claim on a slide.
AI runs on attested NVIDIA GPU TEE inference: the model only executes once both the enclave and the GPU prove their integrity, keeping AI processing inside the same confidential boundary as your data. Confidential compute extends to the model, not just the database.
Secrets are delivered to the enclave as sealed, hardware-bound material, never exposed to the host. Key material is zeroized the moment it is no longer needed, and a continuous, fail-closed self-test verifies the wipe actually happened so secrets never linger in enclave memory.
You can verify which hardened cryptographic backend your enclave actually loaded, confirmed on the attestation endpoint without ever exposing key material or weakening security logging. The crypto in use is a fact you can check, not an assumption.
Defense in depth on encryption: AES-256-GCM at rest for enclave Postgres and backups, TLS 1.3 in transit on every connection with auto-renewed certificates, and Intel TDX hardware memory encryption while data is being processed inside the enclave.
We name the hardware and standards because they are verifiable and they earn your trust: Intel TDX, NVIDIA GPU TEE, DCAP, AES-256-GCM, TLS 1.3. What we deliberately withhold is listed in the redaction policy above.
Verify this yourself: query the live attestation endpoint, documentation at the Trust Center.
Cryptography
Sensitive data does not travel in the open and does not arrive in a form anyone but your enclave can open. We use modern, named, auditable primitives, and we let you bring your own key so that custody of the keystone stays with you.
Cryptographic enforcement is implemented in hardened, memory-safe code, with performance-critical and safety-critical paths in Rust and WASM, and verified with fail-closed self-tests rather than asserted.
Sensitive data is sealed with modern authenticated encryption, X25519 key agreement, HKDF derivation, and AES-256-GCM, so only your enclave can open it. Tampered or wrong-key envelopes fail closed and are rejected.
Scoring results are sealed into your enclave with AES-256-GCM, HMAC-SHA256 integrity, AAD binding, replay-nonce protection, and clock-skew-corrected delivery behind a circuit breaker. The enclave verifies before it decrypts.
Encrypt enclave data with a key you control, supplied directly or fetched at runtime from AWS KMS, Azure Key Vault, or GCP Cloud KMS. We never hold your raw key, only a SHA-256 fingerprint for attestation. BYOK is available across the three major cloud KMS providers, and is activated per tenant.
Keys rotate without downtime: a dual-key window keeps prior data readable during rotation while wrong or unknown keys are rejected fail-closed. Rotation never risks data loss or exposure.
Replay attacks are blocked by a nonce store that fails closed: if it cannot verify a request is fresh, it refuses the request. No silent fail-open path exists; any availability override requires dual-control authorization and is receipted.
Verifiable supply chain
Confidential compute only matters if you can trust the image inside the enclave. So every enclave image is reproducibly built, cryptographically signed, recorded in a public transparency log, shipped with a bill of materials, and gated against known vulnerabilities before it can ship.
Every enclave image is signed with Cosign, recorded in the Rekor public transparency log, shipped with an SBOM and SLSA provenance, scanned with Trivy, and measured for MRTD reproducibility. You can verify exactly what is running.
Images build reproducibly to a known measurement, and the MRTD is pinned, so the attested enclave can be matched against the image you reviewed. Drift between what was approved and what is deployed becomes detectable.
No enclave image ships with a known high-severity vulnerability. The build pipeline fails closed on any HIGH or CRITICAL CVE, including in the base image, so production always runs a clean, current bill of materials.
Enclaves run on a hardened, minimal, digest-pinned base image with a deliberately small attack surface, kept continuously patched against operating-system-level vulnerabilities.
We run continuous, automated dependency security checks and remediate to zero open alerts, with every fix verified at the lockfile level. Supply-chain hygiene is an ongoing discipline, not a one-time audit.
We continuously monitor the public transparency log for our enclave's signing identity, so any unexpected or unauthorized image entry is detected automatically.
Before an enclave image is trusted, it is inspected by digest for integrity, binary hash, and a minimal, locked-down footprint, with evidence generated from the real image, never asserted on faith.
Because builds are deterministic, an independent rebuild yields the same measurement. The chain from source to running enclave is one you can re-walk yourself rather than take on trust.
Verify this yourself: search for our releases in the public Rekor transparency log, signing identity published at the Trust Center.
Verify, do not trust
The architecture above is only as good as your ability to check it without a sales call. So the verification surface is live today: a public Trust Center for posture, a public verifier for our signed daily status and public keys, and a procurement-grade evidence room your security team can open under NDA before you ever go live.
A live, customer-facing Trust Center presents HiveSilo's security posture in one place, so your team can review the architecture, the controls, and their honest status before a single conversation. Open the Trust Center
A public verifier exposes our signed daily status and public keys, so the daily proof chain is something you check with your own tools, not a screenshot we send you. Trust is provable, not promised.
An NDA-gated evidence room gives your procurement and security teams tamper-evident governance and compliance evidence to review before go-live, without ever exposing anything that should stay confidential to the public surface.
Each enclave publishes a live attestation health signal plus a runtime self-test that confirms sensitive key material is zeroized from memory, so you can confirm at any time that the exact, unmodified image is running on genuine confidential-compute hardware.
Verify this yourself: check our signed daily status with the published key, one curl, one openssl command, documented at the Trust Center. Deeper artifacts are available under NDA in the evidence room. And start with this very site: inspect our headers →
Engineering rigor
The codebase is held to an evidence-based, automated security assurance review, and every change to security-critical configuration is gated and verified before it can ship. Continuous, automated security and privacy monitoring is designed into the platform. This is a level of engineering rigor most companies our size never attempt.
Living posture
A traditional certificate is a snapshot, accurate the day it is issued and outdated the moment code changes. HiveSilo is different: our security posture is self-attested with evidence and refreshed on every change, backed by daily automated scans of the live surface, so what you review reflects the system as it runs today, not last year’s paperwork.
Proof without exposure
We show that the intelligence is real without revealing how it works, because the method is the asset we protect, for you and for us. You see the outcome, a buyer ranked Cold, Warm, Hot, or UHNW with a plain-language rationale; aggregate dashboards for traffic quality, automated-traffic share, and ad-spend protected; and a verifiable assurance record. You never see the signal definitions, the weights, or the models. If we will not expose our own methods to a scraper, you can trust how we treat yours.
Isolation & governance
Multi-tenancy is where most platforms quietly leak. Ours is isolated at the database kernel and salted per tenant, authority over change is scoped and governed, and the record of what happened is append-only and verifiable.
Strict tenant isolation is enforced at the database kernel with row-level security on Postgres 16, a dedicated DB role, strict tenant-context wrappers, and composite unique keys, plus per-tenant salting so the same visitor device produces different identifiers for every customer. Cross-tenant correlation is computationally infeasible, and the RLS policy is tested in CI.
Who can change a policy, override a control, or pull a kill-switch is itself governed by role-based access control. Outbound connectivity from the enclave is constrained to an explicit allowlist, so the enclave cannot reach destinations it was never authorized to contact.
Enclaves run in the region you require, so data residency commitments are honored by placement, not policy alone. An in-enclave kill-switch can halt all outbound CRM dispatch instantly and completely, with no fail-open path and a latched, receipted stop. Data residency
Sensitive operations emit hash-chained, tamper-evident receipts that contain no PII, payloads, tokens, or key material, written to append-only (WORM) storage. You get a verifiable audit trail of what happened without ever exposing what was processed.
Changes to governed, security-critical configuration are bound by a master-graph gate: a change must be committed and then re-anchored against the governance graph and landed as a tracked merge, so unreviewed drift in critical files is rejected rather than silently accepted.
Safety-critical properties, such as fail-closed behavior and boundary enforcement, are being brought under formal and property-based verification so that the guarantees hold by construction rather than by test coverage alone.
Deeper checks, the CI-tested row-level-security evidence and the receipt schema, are available under NDA in the evidence room.
Daily signed compliance and runtime proof chain
Compliance and runtime state is hashed and signed each day into an append-only, independently verifiable proof chain. The result is a continuously updated, tamper-evident record that the controls described here were actually in force, not a point-in-time snapshot that goes stale the day after the audit.
Resilience & recovery
A control that has never been exercised is an assumption. So recovery is a tested capability here: failure paths are rehearsed, rollback is practiced, the record of what happened cannot be edited after the fact, and a key rotation never costs you a single row.
Recovery is a rehearsed procedure, not a paragraph in a policy. The path from a failed state back to a verified, attested enclave is exercised on a defined cadence, so the time and steps to recover are known in advance rather than discovered during an incident.
Every deployment can be rolled back to a known, signed, measurement-pinned image, and that rollback is rehearsed rather than assumed. If a change misbehaves, the system returns to a previously verified state cleanly, without improvisation under pressure.
The audit trail is append-only and hash-chained, so a recovery, a rollback, or an incident extends the record rather than rewriting it. What happened before, during, and after a disruption stays verifiable, with no PII, payloads, or key material in the trail.
Keys rotate through a dual-key window that keeps prior data readable while wrong or unknown keys are rejected fail-closed, so a rotation never loses or exposes a single row. Rotating the keystone is a routine operation, not a recovery event.
Governance proof
Autonomy is only safe if it knows when to stop. The decision core is built to fail closed: where it is not certain, it abstains rather than acts, every decision can be halted on its own, and every decision leaves a receipt, so action stays inside the boundaries you set and nothing happens without an account of why.
The decision core does not guess at the edge of its competence. When confidence or policy conditions are not met, explicit abstention rules make it decline rather than act, so uncertainty resolves to inaction instead of an unsafe call.
Autonomy is governed at the granularity of the individual decision. A per-decision kill-switch can halt a specific action without taking down the platform, so a single autonomous path can be stopped instantly and completely, with no fail-open route around it.
Every decision emits a tamper-evident runtime receipt that records that it happened and within which boundaries, carrying no PII, payloads, or key material. The result is a verifiable account of each autonomous action, after the fact, without exposing what was processed.
Abstention, the per-decision kill-switch, and per-decision receipts work together so autonomous actions stay inside the boundaries you set and every decision is accountable. Authority is scoped, bounded, and provable, never open-ended.
Confidential AI
The hard part of AI in a regulated enterprise is custody: most AI architectures require shipping your data to a model that someone else operates. Ours keeps the model inside the same confidential boundary as the data, so the intelligence works without anyone, including the model vendor, gaining custody.
Model keys release only after both the enclave and the GPU attest. AI and LLM intelligence run on attested NVIDIA GPU TEE inference, keeping the model inside the same confidential boundary as your data rather than reaching in from outside.
The agents that act on your intelligence run inside your confidential virtual machine, behind the egress allowlist and the kill-switch, so they operate on sealed data under your keys and cannot exfiltrate it to an outside service.
We identify and convert your highest-value buyers from first-party traffic, computed entirely on anonymous behavior with zero PII. The model reads the signal, never the identity.
A promise you have to trust is a liability. A property you can verify is a control. We built the second kind.HiveSilo
Active defense
A confidential boundary protects what is inside; active defense keeps the bad traffic and tampering out, and keeps the merchant surface that feeds the platform hardened. These controls run continuously, not as a quarterly exercise.
Real-time, multi-signal bot defense protects your ad spend: confirmed invalid traffic is excluded from ad platforms and documented for refund claims, while legitimate humans on VPNs and private relays are protected from false positives.
When a new bot or attack pattern strikes one tenant, every tenant inherits the defense through privacy-preserving aggregates alone. Network immunity shares threat resistance, never data, and each tenant stays cryptographically isolated.
Daily checks of your site, headers, third-party script risk, consent timing, DNS, and exposed paths keep the surface that feeds the platform hardened. The lightweight beacon is non-blocking, read-only on the DOM, fail-open, cookie-free, and strict-CSP compatible, verified in CI.
Continuous, automated security checks run against dependencies, images, and runtime state, and recursive PII-boundary enforcement is gated on every change so personal data cannot slip into systems that should never see it. Security is enforced in the pipeline, every day.
Data-path integrity
The signals that feed scoring are first-party and zero-PII, but they still have to be trustworthy. From the on-site beacon to the ingest stream to the agents and crawlers that touch your data, the path is governed end to end, fault tolerant, and gated so nothing unclassified or malformed reaches the intelligence layer.
A runtime decision layer wired into live ingest governs, in real time, how your first-party data responds to AI agents and automated crawlers, so autonomous traffic does not distort your buyer intelligence.
A production-grade first-party ingest pipeline streams your own traffic events into the enclave for scoring, with no third-party data brokers in the path. It is fault tolerant: malformed or poison events are quarantined and explained rather than stalling the stream.
A built-in integrity audit continuously verifies the on-site tracker via path checks, so the measurement pipeline is tamper-evident and the lightweight beacon stays async and non-blocking, unable to affect the host site your buyers land on.
When a high-value visitor converts on your own forms, the moment is captured, attributed, and stitched to the full visit journey inside your enclave, turning anonymous first-party traffic into an attributed contact without exporting PII.
Worker-to-worker authentication is hardened with no shared static secrets, so internal service calls cannot be replayed or impersonated by a leaked credential. The trust between components is itself a control.
A strict governance gate requires every signal to be classified before it can reach scoring, so nothing unclassified silently enters the intelligence layer. We never reveal signal definitions, counts, or methodology, only that coverage is enforced.
Closed-loop activation
Intelligence is only useful if it acts, and activation is where most platforms quietly take custody. Ours does not. CRM writes and ad-conversion feedback happen from inside your enclave, with your credentials and hashed data, behind the same fail-closed boundary and kill-switch as everything else.
Qualified leads, with score, urgency, and an AI brief, are written straight into your CRM from inside your own enclave using credentials injected only into that boundary. The CRM adapters, including Salesforce, HubSpot, Follow Up Boss and others, are available and activated for your tenant.
Scored intelligence is delivered inside a cryptographically sealed envelope (AES-256-GCM with X25519 key exchange) and only opened inside your hardware-protected environment, where it is matched to the contacts your enclave already holds.
As leads turn into deals, your enclave can feed real conversion value back to Google Ads and Meta, including the Meta Conversions API, using hashed data, so your campaigns optimize toward people who actually buy, while HiveSilo never touches your customer data or your ad accounts. The conversion adapters are scoped and activated per tenant, and the bot and invalid-traffic exclusion keeps these channels clean.
Cross-account benchmarks pass hard mathematical privacy gates, k-anonymity, l-diversity, and differential privacy, plus a signed-manifest check, before any aggregate is ever shared. Network insight is shared, never customer data.
Every outbound path here is gated by the same fail-closed boundary and authorized-signer kill-switch described above: if a control is uncertain, dispatch defaults to blocking rather than acting.
Enterprise IAM & compliance
Enterprise security teams need the platform to fit their identity controls and need a compliance story they can defend. We support standard enterprise identity, and we state our compliance posture exactly as it is, no badges we have not earned.
Authenticate through your identity provider with SAML, so access follows your existing policies, conditional-access rules, and offboarding flows rather than a separate, ungoverned credential store. Available and activated for your tenant.
Provision and deprovision users automatically with SCIM, so joiners, movers, and leavers are reflected without manual steps and access is revoked the moment your directory says so. Available and activated for your tenant.
SOC 2 is in progress. We do not display certifications we have not earned, and we will name the firms and publish results once those engagements complete, never before.
We offer a GDPR Data Processing Agreement and support right-to-be-forgotten workflows. Because PII stays sealed enclave-side under your keys, erasure and access requests resolve where the data actually lives. See privacy
We commit to a defined incident-response SLA with clear notification timelines. The architecture is built so that the blast radius of any incident is constrained by the confidential boundary, not the size of a shared data lake.
Built-in observability and real-user monitoring give live visibility into measurement and platform health, with automated readiness checks and integrations for standard enterprise tools like Splunk and Datadog.
Attestation, signing, transparency-log entries, and the daily proof chain are exposed for independent verification. Bring your security team to the Trust Center and check the architecture yourself. Trust Center
Honesty is a hard rule here: every claim on this page is stated at the status it actually holds. Live means in production. Rolling out means built and shipping. In progress and scheduled mean exactly that. We would rather show you a gap than an unverifiable claim.
At a glance
One reference table for the security reviewer, mapping each layer to its control and its honest status.
All statuses on this page are machine-rendered from the claims registry and cross-checked against the signed evidence chain · live verifier unreachable at render — statuses shown from the reviewed registry · registry v2.0, human-reviewed 2026-07-04 · this render 2026-08-24T21:25Z
| Layer | Control | Status |
|---|---|---|
| Compute | Per-tenant Intel TDX confidential enclave | Live |
| Verification | DCAP attestation + MRTD pinning endpoint | Live |
| AI | Attested NVIDIA GPU TEE inference, dual-attested | Live |
| Crypto in transit | TLS 1.3 every hop, auto-renewed certs | Live |
| Crypto at rest | AES-256-GCM, enclave Postgres + backups | Live |
| Envelopes | X25519 + HKDF + AES-256-GCM, HMAC-SHA256 | Live |
| Key custody | BYOK / CMK, dual-key rotation, fingerprint only | Available |
| Supply chain | Cosign + Rekor + SBOM + SLSA, reproducible | Live |
| Build gate | Fail-closed on HIGH/CRITICAL CVE | Live |
| Isolation | Kernel RLS (Postgres 16) + tenant salting | Live |
| Authority | RBAC + egress allowlist + kill-switch | Live |
| Evidence | WORM audit + non-PII runtime receipts | Live |
| Ingest | First-party ingest + dead-letter quarantine | Live |
| Agents | Agent-interaction control (AEO) at ingest | Live |
| Signal coverage | Classify-before-scoring governance gate | Live |
| Service auth | Hardened worker auth, no shared static secrets | Live |
| Activation | In-enclave CRM dispatch, your credentials | Available |
| Ad feedback | Closed-loop conversion value, hashed in-enclave | Available |
| Benchmarks | k-anon + l-diversity + differential privacy gates | Live |
| Verification | Trust Center + public verifier + evidence room | Live |
| Observability | RUM + readiness, Splunk / Datadog integrations | Live |
| Crypto tier | Rust / WASM defense-in-depth crypto module | Live |
| Governance | Master-graph change gate | Live |
| Assurance | Formal / property-based verification | In progress |
| Identity | SAML SSO + SCIM provisioning | Available |
| Compliance | Controls mapped, GDPR DPA, RTBF, IR SLA | In progress |
Verify this yourself: compare the badges above to /api/trust/claims, the machine source they render from, or do it right here: If they ever disagree, a daily canary pages us first.
Independent verification, status
Self-attested evidence is where every young security company starts; independent reports are how it finishes. Here is exactly where that stands, dated milestones, no firm named before it is contracted, and every report publishing to the signed evidence room when complete.
| Milestone | Status | Where the output lands |
|---|---|---|
| SOC 2 Type II, readiness & auditor selection | In progress · auditor named here once engaged, never before | This page + Trust Center |
| SOC 2 Type II, observation window | Begins on engagement; start date published here when set | Report to the NDA evidence room |
| First independent architecture assessment | Scoped; firm + window published once contracted | Summary letter to the NDA evidence room |
| Coordinated client pen-tests | Accepted today under rules of engagement | Findings via responsible disclosure |
The rule for this table is the same as everywhere else on this page: milestones are dated as they occur and never announced early. An empty cell here is a schedule, not a secret.
FAQ
Confidential compute runs your workload inside a hardware-based trusted execution environment (TEE) where the CPU and memory are hardware-encrypted and isolated from the host, the hypervisor, and the operator. Each HiveSilo tenant runs in its own dedicated enclave on Intel TDX. Scoring, CRM dispatch, the intelligence layer, and the Privacy Center all execute inside that boundary under your keys. It matters because it removes the cloud operator, and HiveSilo, from the trust equation: even with full infrastructure access, your sensitive data cannot be read from outside the enclave.
Yes. Every enclave proves itself with hardware attestation (Intel TDX, DCAP-verified, measurement-pinned) over a dedicated attestation endpoint before any data flows. You can independently confirm you are talking to genuine, measured confidential-compute hardware running the expected image, not a claim on a slide. The active cryptographic backend is disclosed on the same endpoint, without ever exposing key material.
You can. With Bring Your Own Key, you encrypt enclave data with a key you control, supplied directly or fetched at runtime from AWS KMS, Azure Key Vault, or GCP Cloud KMS. HiveSilo never holds your raw key, only a SHA-256 fingerprint for attestation. Keys rotate without downtime through a dual-key window that keeps prior data readable while wrong or unknown keys are rejected fail-closed. BYOK is available across the three major cloud KMS providers, and is activated per tenant.
Each tenant runs in a dedicated confidential-compute enclave, and within the database, isolation is enforced at the kernel with row-level security on Postgres 16, a dedicated database role, strict tenant-context wrappers, and composite unique keys. Device fingerprints are tenant-salted, so the same visitor device yields a different identifier for every customer, making cross-tenant correlation computationally infeasible. The row-level security policy is tested in CI.
No. AI and LLM intelligence run on attested NVIDIA GPU TEE inference inside the same confidential boundary as your data; the model only executes once both the enclave and the GPU prove their integrity. The platform scores anonymous behavioral signals with no PII, and raw contact, address, and IP data stay sealed enclave-side. The intelligence reads the signal, never the identity.
The build pipeline fails closed on any HIGH or CRITICAL CVE, including in the base image, so a known-vulnerable image cannot ship. Critical fixes are targeted within 72 hours. Because builds are reproducible and measurement-pinned, every patch rotates the attestation measurement, your verifier sees the remediation happen rather than taking our word for it.
Yes, under coordinated rules of engagement agreed in advance, scope, window, and contacts are set with our security team, and findings run through the responsible-disclosure process. Summary letters of third-party testing are made available in the NDA evidence room as engagements complete.
We commit to notifying affected clients without undue delay and within 72 hours of confirming an incident affecting their scope, with the contractual figure and escalation path fixed in the DPA and MSA rather than in marketing copy. The architecture also constrains what an incident can touch: the confidential boundary, not a shared data lake, defines the blast radius.
The subprocessors page is the public record, and contracted clients receive advance notice of material sub-processor changes, 30 days before the change takes effect, with the right to object handled through the DPA. Nothing in the PII path changes quietly.
We state only what is verifiable. Our controls are mapped to recognized security frameworks. We do not display certification badges we have not earned. We offer a GDPR Data Processing Agreement, support right-to-be-forgotten workflows, and commit to a defined incident-response SLA. Anything not yet earned is described as in progress or scheduled, never as done.
For enterprises acquiring UHNW and VHNW clients, the only safe vendor is one that cannot expose your data in the first place. Request a private security briefing, or send your CISO straight to the live Trust Center.
Document version 2.0 · last substantive change 2026-07-04 · statuses render live from the claims registry (v2.0, reviewed 2026-07-04)