Security & architecture: no one, not even us, has custody of your buyers
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.
- Intel TDX confidential compute
- Attested GPU TEE AI
- Cosign + Rekor supply chain
- Zero PII in custody
Status
- Per-tenant hardware TEE Live
- Attestation endpoint Live
- BYOK / CMK Available
At a glance
- Every tenant runs in its own Intel TDX confidential-compute enclave, the host, the cloud operator, and HiveSilo cannot read it.
- Hardware attestation you can query: DCAP-verified, measurement-pinned, checked before any data flows.
- Reproducible, signed builds pinned to the measured image, what was reviewed is provably what is running.
- Your keys: BYOK across the major cloud KMS providers; HiveSilo holds only SHA-256 fingerprints.
- Zero PII custody by architecture, the shared platform scores anonymous signals; identity never leaves your enclave.
- Verify all of it at trust.hivesilo.com, attestation, signatures, transparency log, daily signed status.
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.
Intelligence without custody, in one view
The custody boundary
The custody boundary: intelligence without custody, in one view
A buyer’s browser on your own website sends a non-PII behavioral signal into your hardware-attested confidential enclave. CRM and ad-platform dispatch run from inside that enclave, under your keys. HiveSilo sits outside the PII path entirely, connected only by a thin attestation and scoring line: it sees the signal, never the identity, and only a sealed result comes back. Customer PII never crosses the custody boundary line.
Your trust domain
PII · CRM · your keys
Buyer’s browser
Your own first-party traffic
Your attested enclave
Per-tenant confidential VM · TEE
HiveSilo cannot see in or decrypt
Your keys · your trust domain
Attestation verified
your keys
Your CRM / ad platforms
Dispatched from inside the enclave
Customer PII never crosses this line
Outside the PII path
HiveSilo
Attestation & scoring service
Sees the signal — never the identity
General notes
- 1. Intelligence without custody.
- 2. The intelligence reads the signal, never the identity.
- 3. Removes the additional HiveSilo-held PII custody surface by architecture.
- Drawing
- HS-SEC-01
- Title
- The custody boundary
- Revision
- 2.0 · 2026-07-04
- Status
- Live
We assume the operator is hostile and the breach is inevitable
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.
Remove the operator from the trust boundary
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.
Never take custody of PII
The shared platform processes anonymous behavioral signals only. Raw contact details, addresses, and IPs stay sealed enclave-side under your keys. This removes the additional HiveSilo-held PII custody surface by architecture.
Fail closed, prove everything
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.
Make the claims independently checkable
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 your clients’ personal data in the first place. That is the design goal of everything below. Read: the AI-era data liability
Out of scope & residual risk
Scope & redaction
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
- The confidential-compute cloud vendor
- The model vendors
- Signal definitions, counts, weights, and scoring methodology
- Patch-level software versions
- Internal network topology
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.
A dedicated hardware enclave per tenant, on Intel TDX
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. HiveSilo processes non-PII signals outside the PII path; the resulting intelligence is delivered into that boundary, where the identity join, CRM dispatch, and the Privacy Center all execute under the customer’s keys.
How you know the audited code is what is running
Four steps: a reproducible signed build produces a measurement (MRTD); the enclave boots against that measurement; your verifier queries the attestation endpoint and receives a hardware-signed answer. The final verification step carries the accent check mark.
Reproducible build
signed, logged
Measurement
MRTD pinned
Enclave boot
hardware-attested
Your verifier
query, don’t trust
Full detail, 6 controls
- 01
Per-tenant enclave (Intel TDX)
Live
Each customer runs in a dedicated confidential-compute enclave on hardware TEE. CPU and memory are hardware-encrypted and isolated from the host, so the identity join, CRM dispatch, and all handling of your own PII happen inside your enclave, with your keys. Scoring itself runs on non-PII signals, outside the PII path. Intelligence without custody.
- 02
Real-time attestation (DCAP, MRTD pinning)
Live
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.
- 03
Attested GPU TEE AI inference
Live
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 a hardware-attested confidential boundary. The model runs on non-PII signals, outside the PII path. Confidential compute extends to the model, not just the database.
- 04
Private runtime memory & sealed secrets
Live
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.
- 05
Verifiable crypto-backend disclosure
Live
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.
- 06
Encryption everywhere it runs
Live
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.
Sealed envelopes, modern primitives, keys you can hold
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.
- 01
Tier-B envelope encryption (X25519 + HKDF + AES-256-GCM)
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.
- 02
Sealed intelligence envelope, HS to enclave
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.
- 03
Bring Your Own Key / CMK
Available
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.
- 04
Key rotation with rollback safety
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.
- 05
Fail-closed replay protection
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.
You can verify exactly what is running in your enclave
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.
Full detail, 8 controls
Signed, logged, attested images
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.
Reproducible builds, pinned measurement
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.
Fail-on-HIGH/CRITICAL CVE gate
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.
Hardened minimal base image
Enclaves run on a hardened, minimal, digest-pinned base image with a deliberately small attack surface, kept continuously patched against operating-system-level vulnerabilities.
Continuous dependency remediation
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.
Transparency-log monitoring
We continuously monitor the public transparency log for our enclave’s signing identity, so any unexpected or unauthorized image entry is detected automatically.
Anti-tamper image inspection
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.
Reproducible across rebuilds
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.
A live Trust Center, a public verifier, and an NDA-gated evidence room
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.
- 01
Public Trust Center
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
- 02
Public verifier for signed daily status
Live
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.
- 03
NDA-gated procurement evidence room
Live
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.
- 04
Customer-verifiable attestation health
Live
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 →
Built under adversarial assurance
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.
Verification that does not go stale
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.
We prove the intelligence is real without revealing how it works
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.
Kernel-level isolation, scoped authority, tamper-evident evidence
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.
Full detail, 6 controls
- 01
Tenant isolation (kernel-level RLS)
Live
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.
- 02
RBAC & egress allowlist
Live
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.
- 03
Data residency & fail-closed kill-switch
Live
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
- 04
WORM audit + runtime receipts
Live
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.
- 05
Master-graph governance
Live
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.
- 06
Formal verification of critical paths
In progress
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.
Recovery is rehearsed, not hoped for
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.
Full detail, 4 controls
- 01
Tested disaster recovery
Live
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.
- 02
Rehearsed rollback
Live
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.
- 03
Append-only audit through recovery
Live
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.
- 04
No data loss on key rotation
Live
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.
Autonomous actions stay inside the boundary, and every decision is accountable
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.
Full detail, 4 controls
- 01
Fails closed with explicit abstention
Live
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.
- 02
Per-decision kill-switch
Live
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.
- 03
Per-decision runtime receipts
Live
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.
- 04
Action stays inside set boundaries
Live
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.
The agents work inside your enclave, not on your data from outside
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 does not. The HiveSilo model runs on non-PII signals outside the PII path, and the agents that act on the result run inside your own enclave, so the intelligence works without anyone, including the model vendor, gaining custody.
Dual-attested execution
Model keys release only after both the enclave and the GPU attest. AI and LLM intelligence run on attested NVIDIA GPU TEE inference, on non-PII signals outside the PII path, so no HiveSilo model reaches into your identity data.
Air-gapped agents in your CVM
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.
Anonymous scoring, never identity
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
Defense that is shared across the network and runs every day
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.
Full detail, 4 controls
- 01
Multi-signal bot defense
Live
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.
- 02
Cross-tenant immunity
Live
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.
- 03
Merchant-site hardening
Live
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.
- 04
Continuous, automated security checks
Live
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.
Every input is governed, attributed, and quarantined when it misbehaves
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.
Full detail, 6 controls
- 01
Agent-interaction control (AEO)
Live
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.
- 02
Resilient ingest with dead-letter quarantine
Live
A production-grade first-party ingest pipeline streams your own traffic events to the non-PII scoring layer, 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.
- 03
Tamper-evident tracker integrity audit
Live
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.
- 04
In-enclave form-submit attribution
Live
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.
- 05
Hardened service-to-service auth
Live
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.
- 06
Signal-coverage governance gate
Live
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.
Leads and conversion value leave the enclave under your keys, never ours
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.
Full detail, 4 controls
- 01
In-enclave CRM dispatch with your credentials
Available
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.
- 02
Sealed intelligence, opened only enclave-side
Live
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.
- 03
Closed-loop ad conversion value
Available
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.
- 04
Privacy-gated cross-tenant benchmarks
Live
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.
Fits your identity stack, honest about its certifications
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.
Full detail, 7 cards
SAML single sign-on
Available
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.
SCIM provisioning
Available
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.
Compliance posture
SOC 2 Type I: engaged with a licensed CPA firm; onboarding and evidence review in progress. SOC 2 Type II: follows issuance of Type I. No report, opinion or certification has been issued. We do not display certifications we have not earned, and we will name the firms and publish results once those engagements complete, never before.
GDPR DPA & right to be forgotten
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
Incident-response SLA
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.
Observability with your tooling
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.
Verify, do not take our word
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.
The architecture, layer by layer
At a glance
One reference table for the security reviewer, mapping each layer to its control and its honest status.
The eight layers of the HiveSilo security architecture
A vertical stack, hardware at the bottom: hardware TEE, then attestation, supply chain, data isolation, keys, runtime governance, evidence, and operations and resilience at the top. Each layer links to its section on this page.
- 1 · Hardware TEE, per-tenant Intel TDX enclave
- 2 · Attestation, DCAP, MRTD-pinned, queryable
- 3 · Supply chain, reproducible, signed, logged
- 4 · Data isolation, kernel RLS + tenant salting
- 5 · Keys, BYOK, envelopes, fail-closed rotation
- 6 · Runtime governance, abstention, kill-switch
- 7 · Evidence, WORM audit, non-PII receipts
- 8 · Operations, rehearsed recovery & rollback
All statuses on this page are machine-rendered from the claims registry and cross-checked against the signed evidence chain · statuses rendered from the reviewed claims registry · registry v2.0, human-reviewed 2026-07-04
| 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.
See the full platformThird-party corroboration, as a schedule you can hold us to
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 I | Engaged with a licensed CPA firm · onboarding and evidence review in progress | This page + Trust Center |
| SOC 2 Type II | Follows issuance of Type I · no report, opinion or certification has been issued | 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.
Security & architecture, common questions
FAQ
What is confidential compute and why does it matter here?
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. HiveSilo processes non-PII signals outside the PII path; the resulting intelligence is delivered into that boundary, where the identity join, CRM dispatch, and the Privacy Center all execute 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.
Can I verify what is actually running before any data flows?
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.
Who holds the encryption keys?
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.
How is one tenant isolated from another?
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.
Is the AI given custody of our customers’ identities?
No. AI and LLM intelligence run on attested NVIDIA GPU TEE inference on non-PII signals, outside the PII path; 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.
You name Postgres and Intel TDX, what happens when a CVE drops?
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.
Can our security team pen-test HiveSilo?
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.
What is your incident-notification commitment?
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.
How do we hear about sub-processor changes?
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.
What is your real compliance status?
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.
Document version 2.0 · last substantive change 2026-07-04 · statuses render live from the claims registry (v2.0, reviewed 2026-07-04)
Changelog
- 2.0 · 2026-07-04, live-claims infrastructure (registry-rendered badges, drift CI, daily canary), custody / layer-stack / attestation diagrams, at-a-glance summary, residual-risk and redaction-policy blocks, per-layer verification paths, independent-verification schedule, four security-questionnaire FAQs, table of contents and print edition.
- 1.1 · 2026-07-04, sitewide honesty and template pass: copy precision, Open Graph assets, unified footer and legal pages.
- 1.0 · 2026-06-28, initial publication of the CISO architecture page.
Bring your security team. Verify the architecture, then talk.
For enterprises acquiring UHNW and VHNW clients, the only safe vendor is one that cannot expose your clients’ personal data in the first place. Request a private security briefing, or send your CISO straight to the live Trust Center.