For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt. This page is also available in markdown by appending .md to the URL.
Your vendor data, assessment evidence, contracts and supplier identifiers are protected in transit and at rest, isolated to your organization, masked from anyone who does not need to see them in full, and held only as long as you need them.
Encryption
In transit
All connections use TLS 1.2 or higher, with certificates from recognized authorities. There is no unencrypted surface: the API, the dashboard, the vendor portal and the MCP server are HTTPS only.
At rest
Customer data is encrypted at rest with AES-256 across every store: the transactional database, object storage, search indexes, block storage and backups. Encryption is enforced at the infrastructure level rather than left to the application.
Field-level encryption
Some data is worth stealing on its own, so it is not stored in a readable column even inside an already-encrypted database. Supplier bank account identifiers and tax registration numbers are sealed individually with AES-256-GCM, under a dedicated key held separately from the database.- Authenticated encryption. Each value set is sealed as a single envelope carrying its own nonce, so a ciphertext cannot be tampered with undetected or replayed onto another record.
- Versioned keys, rotatable without a migration. Every envelope records the key version it was sealed under, so the key can be rotated while previously sealed rows keep opening under the version that wrote them.
- One decryption path. Exactly one module can open an envelope, and it is reached only by a caller holding the elevated banking scope or by a validation path that genuinely needs the raw value. Nothing else in the platform can decrypt.
- Blind matching. “Is this the same account we already hold?” and “did this account change?” are answered with a one-way HMAC fingerprint over the normalized identifiers, so change detection never decrypts anything and a fingerprint reveals nothing about the value behind it.
Role-based masking
Encryption protects the stored value. Masking is what governs whether anyone sees it, on screen, in an export, or in a webhook payload. A sensitive identifier is represented by its last four characters and nothing else everywhere except an explicitly scoped read. That rule is enforced in one place that every consumer passes through, so adding a new report, integration or event cannot quietly add a new leak.
Institution-identifying fields that a reviewer actually needs to sanity-check a change, such as the bank name, SWIFT/BIC, bank code and branch code, stay readable. The account identifier does not. A reviewer can therefore approve or reject a bank-detail change on the evidence that matters without ever being shown the account number.
Separation of duties is enforced on the same data. A service account, which is what every API key authenticates as, can request a change to supplier bank details, and by default cannot approve one: approval stays with a person. Bypassing that queue requires a separate, admin-minted, revocable scope that no key carries unless an admin deliberately grants it. See API key scopes.
Beneficial-owner and officer data
Personal data about a third party’s officers and ultimate beneficial owners is handled as a distinct, higher-sensitivity class rather than as ordinary vendor data.- Off by default. Officer and beneficial-owner screening is not enabled unless your organization deliberately turns it on, because screening a person means holding watchlist assertions about a named private individual.
- Sourced, not guessed. Only people named in a corporate registry filing are eligible as subjects, and only where their link to the vendor was accepted rather than merely plausible.
- Its own permission. Screening results are a separate access-control resource with its own read, update and export permissions, so a compliance reviewer can be given the screening queue without vendor edit rights, and a vendor owner can hold the vendor without the ability to close a sanctions match. There is no human create or delete; matches are written by the pipeline.
- Classified and cascading. Identity attributes sent to a screening provider are classified as personal data, and every artifact cascades on subject deletion, so retiring a subject is a delete rather than an orphaned row.
- Erasure reaches the provider. A monitored profile is personal data held at a provider on Coverbase’s instruction. Deleting a vendor, merging one away, or dropping it out of monitoring queues the profile’s retirement at the provider too, and an unreachable provider delays that rather than dropping it.
Tenant isolation
Coverbase is multi-tenant, and isolation between tenants is enforced in depth rather than at a single boundary.- Every record is org-scoped. Each object carries the ID of its owning organization, and that scope is enforced at the data-access layer on every read and write, not only at the API edge.
- Credentials are single-org. An API key authenticates to exactly one organization; everything it reads or writes is implicitly scoped to that org. A request can never reach another tenant’s data by changing an ID. See API conventions.
- AI access inherits the boundary. MCP tool calls run with the connected user’s permissions and cannot escalate beyond what that user could do in the UI. See MCP permissions.
- Your documents are never pooled. The one deliberately shared dataset, the document library, is built exclusively from documentation Coverbase collects itself. Documents your organization uploads, and documents vendors send you through an assessment portal, are never added to it.
A resource ID that does not belong to your organization is treated as not found (
404), the same response as an ID that does not exist, so existence in another tenant is never leaked.Key and secret management
Managed keys with automatic rotation
Encryption keys are AWS KMS customer master keys held in Coverbase’s account, with automatic key rotation enabled. Keys are separated by purpose rather than shared: distinct keys for the database, object storage, search, block storage, the secrets store, and individual integration credential stores.
Secrets never live in the database
Application secrets and per-organization integration credentials are stored in a managed secrets service (AWS Secrets Manager), one secret per credential rather than one shared document, under a key prefix scoped to the owning organization. The database holds a pointer and metadata; the value is never in a column, in source control, or in a config file. No route ever returns a stored credential.
Customer-managed keys. Coverbase does not currently offer bring-your-own-key against a KMS key in your own AWS account. Encryption keys are Coverbase-managed KMS CMKs, separated by purpose and rotated automatically, as described above. If a customer-managed key is a control requirement for your program, raise it with your Coverbase team at security@coverbase.ai so it is scoped rather than assumed.
Network controls
Organizations can lock down where API access is allowed to originate from.API IP allowlist
Restrict all public-API (
ak_... key) requests to a set of IPv4/IPv6 CIDRs. The control is fail-closed and uses the unspoofable load-balancer-provided client IP. See API IP allowlist.Data residency
The multi-tenant Coverbase production environment runs on AWS in the United States (us-east-1), across multiple availability zones. Customer data, backups and search indexes stay within that region.
The entire platform is defined as infrastructure-as-code and parameterized by region, so a deployment in another AWS region, including the EU, is a configuration of the same stack rather than a rebuild. Programs with a specific residency obligation should raise it during evaluation: contact security@coverbase.ai and we will tell you what is available on what timeline rather than leaving it open.
Subprocessors that process customer data are assessed before onboarding and reviewed on a recurring basis, and the current list is available on request. See Security governance.
Retention and deletion
- Retention. We retain customer data for the life of your subscription and the period defined in your agreement and our privacy policy.
- Deletion. On contract termination, customer data is deleted in line with the agreed terms. You can also delete or archive records yourself through the dashboard and API throughout the engagement, and deletion cascades to the dependent artifacts rather than orphaning them.
- Backups. Deleted data ages out of backups according to the backup-retention schedule.
- Export before exit. Everything is retrievable before you leave, through the Export API, bulk document download, and per-assessment evidence packages. See Contract terms and exit.
Privacy policy
See the Coverbase Privacy Policy for how we handle personal data, including data-subject requests.