Security & trust
The trust posture, said plainly — and never rounded up.
The isolation, audit, and sensitive-data handling a regulated product needs are native to the platform — not a layer you bolt on after your first security review. Here’s exactly what holds, and where the boundary is.
The posture
The boundary, drawn before you have to ask.
Tenant isolation is enforced structurally at the data layer. Credentials are validated at the edge before any application code runs. Every public surface terminates TLS and every storage surface is encrypted at rest. The partner data-plane inference path runs inside the Vectros perimeter — the same posture on every tier.
Sensitive-data handling
Three separate mechanisms protect a sensitive field.
They operate at different points in the data lifecycle. Redact-at-write protects history; read-time masking protects live reads; search-exclusion protects retrieval — three independent guarantees, not one restated.
Redact-at-write
destroyed before persist
A sensitive field’s value is redacted out of the retained version history and the structured change-diff before anything lands in durable history. This is not reversible masking — it’s destruction. No scope, credential, or later request can recover it, because it was never written there.
Read-time masking
hidden unless the token reveals it
A token without the explicit reveal scope sees the field obscured. A token deliberately granted reveal authority sees the cleartext. This is the runtime access control on sensitive data still present in live rows.
Search-exclusion
never enters the index
Sensitive fields are excluded from the search index at index time — never embedded, never tokenized. No query, semantic or keyword, can surface a sensitive value or use it as a matching signal, because it isn’t in the index to match against.
The trust story
Said plainly, and never rounded up.
Three properties carry the trust posture: a version history built to survive an auditor, isolation that fails closed as a platform property, and surfaces hardened by adversarial review.
Tamper-evident audit & version history
Every write to an audited model accrues an immutable version record — built to survive an auditor.
- What changed, who changed it, and the prior content — with sensitive fields already redacted.
- Deletions leave a tombstone.
- Tamper-evident: a SHA-256 state-continuity chain makes out-of-band alteration detectable.
- Heavy history moves to a write-once, retention-locked store (default ~7-year horizon), dispositioned only through a policy-aware path — never silent auto-expiry.
Isolation as the guarantee
Every application context is a mandatory, fail-closed partition derived from the credential — never a wildcard.
- Probing with another customer’s id returns the same “not found” as an invented id — errors aren’t a discovery channel.
- Hybrid search inherits the same boundary.
- Filter inputs are allow-list validated, so a crafted filter can’t break out of the tenant clause.
- Isolation is a platform property — not row-level rules one forgotten WHERE clause from a leak.
Hardened by adversarial review
Partner-facing surfaces have been hardened through extensive adversarial security review.
- The review exercised tenant isolation, scope enforcement, key construction, the edge, the authorizer, and the webhook machinery.
- Do-not-regress constraints from that work are enforced mechanically in the codebase, so the fixes can’t silently erode.
Tamper-evident, not tamper-proof — the chain makes alteration detectable; it does not make the store physically immutable.
Where the boundary is
The honest caveats.
Being precise is the point. Evaluate these explicitly for a regulated workload.
Audit history is tamper-evident, not tamper-proof.
The chain makes out-of-band alteration detectable; continuous automated verification isn’t part of the shipped surface.
In-perimeter inference is scoped to the partner data plane.
It’s not a whole-platform legal representation. The platform gives you a HIPAA-grade substrate; it doesn’t make your own application HIPAA-grade on its own.
You can fully delete a customer’s data.
Decommissioning a customer or a whole tenant runs a real, irreversible cascade — not a soft-delete flag. One-click erasure of a single person’s data on request (the “right to be forgotten”) isn’t built yet; it’s on the roadmap.
Reviewed, not certified.
We don’t hold a SOC 2 report or a third-party penetration test today — both are on the roadmap, and we don’t represent otherwise.
Some controls aren’t built yet.
Data residency and region-pinning, customer-managed keys, read-access logging, and configurable retention aren’t shipped today. Ask under NDA where each stands.
Compliance specifics are available under NDA
HIPAA terms, Business Associate Agreement coverage, attestation status, and the exact scope of the in-perimeter inference path. Drawing the boundary ourselves is part of the trust story.