Skip to main content
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.
Coverbase uses AI to read evidence, draft assessments, extract contract clauses, and surface risk. Because those outputs feed real risk decisions, we govern the AI the same way we govern the rest of the platform: with deliberate model selection, testing, human oversight, and strict data handling.

Model selection and hosting

Enterprise-grade models

We run Anthropic Claude models (the Sonnet, Haiku and Opus families) and Amazon Titan embeddings through enterprise model hosting (AWS Bedrock) in our own AWS account, rather than calling consumer endpoints.

No training on your data

Customer data sent to the models we use is not used to train those foundation models. Your data is used to serve your requests, not to improve a third party’s model.
Two details worth knowing when you map this to a residency or data-flow review:
  • Cross-region inference. Most Claude calls use Bedrock’s global cross-region inference profiles, so AWS can serve an individual inference request from capacity in an AWS region other than the one Coverbase runs in (see Data residency).
  • Web research. Features that research a vendor on the public web, such as control evaluations with web search and company and financial lookups, send search queries built from what they are looking up (for example the vendor’s name and the topic) to external web search providers, Tavily and Perplexity. To avoid repeating the same lookup, a query and the public web results it returned can be cached in Coverbase’s AWS account for up to seven days. Refreshing a vendor’s company and financial intelligence searches again rather than reading the cache.
Bedrock model-invocation logging is configured for metadata only (model, timing, token counts), so prompt and response text is not written to those logs.

Testing and evaluation

AI behavior is tested, not assumed. We treat model-driven features as systems that must be measured before and after they change.
  • Evaluations. Model-driven features are exercised against evaluation suites so we can measure output quality and catch regressions when prompts or models change.
  • Confidence signals. Where the model produces a judgment, we surface internal confidence signals to reviewers so low-confidence outputs get extra scrutiny.
  • Pre-release validation. Prompt and model changes go through the same reviewed secure-development pipeline as the rest of the platform.

Human oversight

Human in the loop

AI generates and proposes; people decide. Assessment scoring, findings, and analyst commentary remain reviewable and editable by your team before they become part of the record.

Explicit confirmation for AI writes

Through the MCP server, every AI-initiated action that creates, updates, or deletes data requires explicit confirmation: the assistant cannot silently mutate your data. See MCP security.

Guardrails and data handling

  • Permission inheritance. AI assistants connected through MCP act with the connected user’s permissions and cannot exceed them. See MCP permissions.
  • Scoped context. User-provided context is bounded before it is sent to a model (inputs are truncated to conservative limits), and prompts are structured to keep instructions and data clearly separated.
  • Tenant boundary preserved. Model-driven features operate within the same per-organization isolation as everything else; AI cannot reach across tenants. See Tenant isolation.

Redacting personal data before model calls

Organizations with the third-party lifecycle features can turn on Redact personal data before model calls on the Agent Ledger page. It is off by default.
  • What is redacted. Email addresses, phone numbers, IBANs, US tax IDs, and the full names of your organization’s users and your vendors’ contacts are replaced with placeholders such as [[PERSON:1a2b3c4d5e6f]] before the request reaches the model. The placeholder is a keyed hash (HMAC) under a random secret held for your organization and never returned by any route, so the same person gets the same placeholder across calls, and a placeholder cannot be reversed by guessing values, even for short ones such as phone numbers or tax IDs.
  • What comes back. The model is told to reproduce placeholders verbatim, and the response is restored before anyone sees it. Only placeholders the redactor issued are restored.
  • Enforced in one place. Redaction runs in the connection to the model provider, not in each feature, so every model call your organization makes passes through it: the model request types for invoking a model, conversing, streaming, counting tokens, guardrails, and knowledge-base generation.
  • Fail closed. If Coverbase cannot read whether redaction is on for your organization, the call fails rather than going out unredacted. A model request type redaction does not cover fails while redaction is on, so a new kind of call cannot slip past it.
  • What is not redacted. The contents of images and attached documents (for example a PDF sent to the model as a document, or a file the model provider reads from storage itself), and the search query of a knowledge-base retrieval, which runs against your organization’s own knowledge base. Bank and tax identifiers stored on supplier records are sealed per field (see Field-level encryption) and never reach a prompt in clear, whether or not redaction is on.
Each Agent Ledger row records how many personal details were redacted for that action.

The Agent Ledger and agent policies

The Agent Ledger records every action an AI agent takes on your data: which agent, what it did, to which record, what it read and cited, its confidence, which models it called, the redaction count, and what a person decided. Recording never blocks the action, and a failed action is recorded as failed. Anyone who can read organization settings can export the actions matching a filter, up to 50,000, as a CSV prepared in the background for an audit. Agent policies say what agents may do without a person, and each is checked where the agent acts, against the current setting. Two are enforced today: re-timing monitoring plans from Radar signals (off by default) and proposing diligence reuse at the Front Door (on by default). With a policy off, the agent does not act, and the ledger records what it held back. A policy with no agent behind it stays off and cannot be switched on, so a switch never promises a behavior nothing performs. Accepting risk or closing an issue is locked: it always needs a person.

Learning from your reviewers

An organization can let its own reviewers’ corrections calibrate its control evaluations. It is off by default and applies to that organization only.
  • A daily job turns each evaluation a reviewer overturned in the last 180 days into an example for that control. An admin can switch any example off.
  • With learning on, a control’s evaluation receives up to five of its enabled examples and the organization’s evaluation guidance, truncated, escaped and marked as reference data rather than instructions.
  • With learning off, evaluations use the baseline prompt unchanged.
  • Nothing learned from one organization reaches another organization’s evaluations, and nothing is used to train a foundation model.

Transparency

What we log and don't retain

AI tool calls are logged to your audit trail with user identity, parameters, and outcome. We do not retain the prompts, conversation context, or assistant responses from MCP sessions. See MCP security and privacy.

Agent runtime authorization

How an agent’s outside actions are decided at the moment it acts, attributed to the person who delegated the task, and recorded on the Agent Ledger.