BVECrew crew members are AI staff, supervised by people. Every one of them says so when asked. This page is the plain-language summary of how the platform is put
together, what it will and will not do with your data, and where we stand on certification.
Nothing here is aspirational; if it is not built yet, it says so.
Security architecture
BVECrew runs as a set of internal services (the client connector, Anchor;
the client portal, Front Office; the agency console, Back
Office; and the crew runtime behind them) plus, for Vault placements, a physical
appliance called Strongbox. Four properties hold across all of it.
01 / Transport
Mutual TLS between every internal service
Services authenticate each other with short-lived certificates issued by our internal
OpenBao PKI. No shared static secrets between services, no plaintext hop, and a certificate
that expires quickly enough that a stolen one is close to worthless.
02 / Redaction
Local-only redaction before any cloud model call
When a placement is allowed to use a cloud model at all, context is redacted on our side,
on the same host, before it leaves. We never send your data to a third-party DLP or
redaction API to have it cleaned. Confidential-policy and Vault-residency placements never
call a cloud model.
03 / Audit
Hash-chained, tamper-evident audit log
Every action a crew member takes, every approval a person gives, and every access to a
client's data is written to an append-only log where each entry carries the hash of the
one before it. Alter or delete a record and the chain breaks visibly. You can export your
placement's log.
04 / Approval
Four approval tiers, enforced in the runtime
Each action a role can take is classed R0 to R3 in its charter. The runtime, not the
model, decides whether an action runs, is logged, or waits for a person. Your overlay can
only tighten it.
Approval tiers
Every crew member carries a maximum risk class on its badge. Anything above that class is not
available to it at all. Within its class, this is what each tier means.
Class
Meaning
Who acts
Example
R0
Read-only
Runs unattended. Logged.
Reading a ticket queue, checking a dashboard, drafting a summary for a person.
R1
Reversible internal writes
Runs unattended. Logged and reversible.
Updating an internal ticket field, filing a note, moving an item between internal queues.
R2
External output, sent after human approval
Queued for a person. Sent only after approval.
An email to a customer, a reply on a public channel, an invoice reminder.
R3
Irreversible / production, always human-approved
Always approved by a person. Two-person rule available.
A refund, a production change, a filing, anything that cannot be undone.
Some roles also require client approval before specific actions regardless of class. Those are
listed as "checks first" on each role's sheet on the crew page.
Sheet 06a / Residency
Residency levels
Residency is where your data and your crew member live. Three levels, and every placement
picks one on the order form.
Level 1KeyedYour storage, your keys.
Level 2TenantRuns inside your own cloud account.
Level 3VaultNothing leaves your building.
Read the full residency comparison.
Under Vault residency the Strongbox appliance is on your premises and nothing leaves your
building: no cloud model, no remote storage, no telemetry beyond what you allow.
AI disclosure policy
Every BVECrew staff member is AI-operated and supervised by a person, and it says so. It
identifies itself as an AI staff member in its profile, in the signature of anything it sends,
and in plain words whenever anyone asks. It does not claim to be a person and it is never
configured to. A client cannot switch this off in an overlay.
The full statement, including what to expect when you interact with one, is at
/legal/ai-disclosure.
Subprocessors
The complete list. We keep it short on purpose.
Subprocessor
What for
Applies to
Cloudflare
DNS, CDN, Access (identity-gated portals) and Tunnel (no inbound ports on our hosts).
Platform edge. Does not process placement data.
Your chosen model provider
Language-model inference on context we have already redacted locally.
Standard-policy placements only. Never Confidential-policy placements, never Vault
residency. You pick the provider on the order form; changing it is a subprocessor change
with notice.
Your own cloud account (Tenant residency) and your own premises (Vault, Keyed connector host)
are your infrastructure, not our subprocessors.
Data deletion and certificates
Each client gets a dedicated encryption key. Everything we hold for you, including backups,
is encrypted under it. At contract end, after your export window, we destroy that key.
Without it the data is permanently unrecoverable, everywhere it was ever copied. This is
crypto-shredding, and it is how we can delete backups without hunting for every one.
We then give you a signed deletion certificate identifying the placement, the key
identifiers destroyed, when, and by whom. It is your proof for your own auditors and
regulators. For Vault placements the on-site shred runs before the appliance leaves your
building.
Certifications
SOC 2
In progress
Evidence automation is built. A third-party audit has not yet been engaged. We do not
claim SOC 2 compliance and will not until an auditor's report exists.
Other certifications
None claimed.
[CERTIFICATION: pending -- list only certifications that actually exist, with report dates]
Vertical compliance packs (tax, financial services, retail) map controls to the regulations
those buyers answer to. They are control sets, not certifications.
Reporting a vulnerability
If you find a security issue in BVECrew or any Black Vault Engineering Group LLC service, tell us before
you tell anyone else and we will work it with you. Good-faith research within scope will not
be met with legal action.
Include what you found, how to reproduce it, and how to reach you. We acknowledge reports
within a stated window and keep you informed until it is fixed.
[STATUS: pending -- acknowledgement window] (placeholder -- HUMAN_ACTIONS: set the acknowledgement SLA for vulnerability reports)