Trust & Security

At a glance

1. Deployment and tenant isolation

• One deployment per client. In Couver’s cloud each client has its own virtual machine, storage volumes, backup bucket and keys; no database, index or storage is shared between clients.
• On-premises the software runs on the client’s own server, inside the client’s network and controls.
• Offline installs run every model on that server and send nothing.
• The hosting provider for Couver’s cloud holds ISO/IEC 27001, 27017 and 27018, SOC 2 Type II and CSA STAR Level 1; these cover its infrastructure, not Couver. The provider is named in the annex.
• What the software sends Couver: never document content, search words or personal data (information about the people who use it, such as names, email addresses, or what they search and open); only the licence check-in below, where one is used. The search index’s and the models’ own usage reporting is switched off.
• Licences (on a server the client runs): a signed licence file with an expiry date, renewed with a new file; or, where the server reaches the internet, Couver may use a periodic online check-in instead. A check-in may send the licence and install identifiers, the software version and usage counts (such as the number of people, files and storage used), and nothing else. If a licence has been expired, or could not be checked, for 30 days, search and reading stop until it is renewed. Couver deletes nothing: the client’s data stays on its server, and exports and the audit log stay available.

Who does what

2. Data handled and where it lives

• What is stored: copies of the files the client connects (for the document viewer and exact reads), the text and tables read from them, a search index, accounts, and logs. Source systems are read, never written to.
• Where: in Couver’s cloud, all of it on encrypted block storage attached to the client’s server, none on the server’s own disk; on-premises, on the client’s server.
• Choosing what is read: each source’s setup chooses folders and leaves others out before anything is copied; nothing is processed until the client starts it or turns a schedule on.
• Deletion follows the source: a file deleted at the source is removed at the next sync; removing a source deletes its copies, index entries and stored credential.
• Never used elsewhere: client data isn’t used to develop or test the software, which is tested with public and made-up documents, and isn’t shared between clients.
• Taking it out: what Couver Evidence read can be exported per file or in bulk: text (Markdown or plain text), tables (CSV or Excel), fields (CSV or JSON), and the audit log (CSV). The source documents stay where they are.

3. AI: models, sub-processors and agents

• Where the models run:
  • Offline (local models): every model runs on the client’s server, and nothing is sent out.
  • Cloud and hybrid (the server on the client’s premises, with AI models in the cloud): only what each task needs goes to the model providers named in the annex, with each one’s region and retention: page images for reading scans and charts, the start and end of a document for its summary and fields, and page text with document titles and file names or folder paths for search. Any one model can be replaced by a local one.
• No training: Couver does not use client data to train or improve models, and the terms of the model providers Couver uses exclude training on it; this is a commitment in the annex. Each provider’s retention is in the annex.
• Model changes: Couver changes models only in a release, named in its notes; if a provider retires a model, Couver replaces it in a release. What the models produced (text, summaries, the search index) is deleted with the rest at the end.
• Answers are grounded: every result cites the page, table or passage it comes from, and the viewer opens the original at that place, so a person or an agent can check it. Search and reading accuracy are measured on public benchmarks before changes to them.
• Agents act as their person: an assistant connected over MCP (Microsoft Copilot, Claude and others) or with a token can only search and read, sees only what its person may see, and stops when the person is disabled, loses access, or the token or app is revoked. Owners choose which assistant apps may connect; tokens expire and can be limited to certain sources.
• Copies for an agent’s workspace: if the client allows it, an agent can take a copy of a file its person may open into its own workspace, such as its code sandbox at the assistant’s provider. The link is checked against the person’s access, works for minutes and is in the audit log; the copy is then held under the assistant provider’s terms. Owners can turn this off.
• Prompt injection: text in a document can’t give an agent more access here, because the tools only search and read, with the person’s own access. Couver Evidence also tells agents to treat text in files as evidence, not instructions. What an assistant then does is up to the assistant, so check its answers against the cited source.
• What is logged: every search and read an agent makes, under its person and the agent’s name. The conversation itself stays with the assistant, under the terms between its provider and the client or the person using it.
• New sub-processors are announced in advance, and the client may object (annex).
• Governance: this page, the annex and each release’s notes are the record of which models are used and how; no AI management certification (such as ISO/IEC 42001) is held.

4. Encryption and key management

• In transit: HTTPS (TLS) for every connection to the server, and to models on other machines.
• At rest:
  • In Couver’s cloud: the catalog, search index, file copies and newest backup sit on block storage encrypted with AES-256 by the hosting provider.
  • On-premises: the server’s disk is encrypted with the client’s standard (BitLocker or LUKS), a requirement of the installation.
• Encrypted by Couver as well: credentials for connected services (in the catalog, with a key kept outside it and rotatable), and backups before they leave the server (with a key pair per client, its private key held offline).
• Passwords and tokens are stored only as hashes; where Couver passwords are used at all, they are hashed with scrypt.

5. Identity and access management

• Single sign-on through the client’s directory over OpenID Connect, with the directory’s MFA and conditional access; password sign-in can be turned off entirely.
• Directory sync: with Microsoft 365 or Google Workspace connected, groups are read every 5 minutes; people moved, disabled or deleted there are moved, disabled or signed out here. With other directories, each person’s sign-in is renewed with the directory in the background every hour, and someone blocked there is signed out at the next renewal.
• Roles: owners, administrators and readers; no one can change an account at or above their own role. Administrators run the system without seeing contents outside their own groups.
• Least privilege: groups decide which sources and folders each person searches; for connected services, the service’s own file permissions also apply to readers and administrators, and files they can’t open are never named to them. Owners see every connected file by default, as they run the deployment; the client can hold owners to the service’s permissions too. OneDrive files stay private to the people OneDrive shares them with, owners included.
• AI agents use per-person tokens or the client’s approved apps: an agent can only search and read, never more than its person, and stops when its person is disabled or loses access. Owners decide which assistant apps may connect.
• Administration can be limited to the client’s office network.
• Sessions end after 14 days unused or 30 days in all; the session cookie is HttpOnly, SameSite and, over HTTPS, Secure. Sign-in attempts are rate-limited and throttled.
• Couver’s own access:
  • In Couver’s cloud Couver runs the server, so it holds administrative access to it, by SSH key only: to install releases, keep backups and alerts working, and fix problems. That access reaches the whole server, the client’s data included. Couver uses it only to run and support the service on the client’s instructions, never to read documents for any other purpose. Sign-ins to the server are recorded in its system log.
  • On a server the client runs (on its premises or in its own cloud account) Couver has no standing access. The client’s IT installs releases and runs the server commands. To diagnose a problem, it sends Couver a support bundle (versions, errors, storage, backups and file counts, none of the client’s documents), which it can read before it leaves. If more is needed, the client’s IT shares its screen, or grants Couver access for a time and removes it afterwards.
  • Couver’s administrative accounts (the cloud console, source code, email and domain) are protected by MFA, and Couver’s devices are encrypted, lock themselves and are kept up to date. Couver reviews its access to each client’s server at least yearly and whenever someone’s role changes; owners review their people in People & access.

6. Logging and monitoring

• Audit trail: every sign-in, search, document opened or exported, change to access and change to how the server runs, with the person (or their named agent), time, and the address and client it came from.
• For the client’s security team: filtered and exported in the product (CSV), and written as it happens as JSON lines for a log shipper, or sent to a syslog server, for the client’s SIEM.
• Tamper-evident: each entry is chained to the one before it by a hash, so an entry changed or removed shows.
• Retention: 365 days by default, set per client. Search words can be kept, hashed or not kept, as the client chooses.
• Operations: alerts for failed backups, low disk, and failing models or connectors go to a channel the client chooses.

7. Application and software security

• Every change runs a full automated test suite, including the access-control tests that check who can see what through every way in (the app, the API and AI agents), plus a browser test suite.
• In the pipeline: secret scanning over the code’s whole history, dependency vulnerability audits, container image scanning, and dependencies pinned and updated weekly.
• Changes are made in version control, pass the automated suite, and reach a client only in a versioned, signed release with notes; a server verifies a release before installing it, every upgrade takes a copy of the data first, and an upgrade can be rolled back. Upgrades are scheduled with the client. Offline sites receive the same signed release on a disk.
• Fixing vulnerabilities: Couver aims to release a fix for a critical vulnerability within 7 days of confirming it, for a high one within 30, and for others with the next release. Couver aims to acknowledge reports to security@couver.ai within 2 business days.
• Hardening: only the HTTPS front door is reachable from the network; the application, search index and models listen on the server itself. Each client’s server is its own network, and server administration is by SSH key only.
• In the browser: a content security policy that runs only the server’s own scripts, HSTS, no framing by other sites, no type sniffing, requests from other sites refused, and no third-party scripts.
• In the code: database queries are parameterised; dependencies are pinned in lock files shipped with each release, which list every component.
• Clocks: the server’s clock is set by the operating system’s time service; the audit trail records UTC.
• Reviews: security reviews of the code are carried out internally; a third-party penetration test is planned (see Compliance).

8. Business continuity

• Backups run daily (configurable), to a second disk, a network share or encrypted off-site storage, keeping the number of generations the client sets.
• Restore drills run automatically (monthly by default): the newest backup is restored and checked, and a failure raises an alert.
• Recovery point: up to 24 hours of changes, with daily backups.
• Recovery time: in Couver’s cloud, the target is to restore search within one business day, on a new server from the newest backup. On a server the client runs, as soon as that server or a replacement is available, restored from the newest backup with Couver’s guidance. The client’s source documents stay where they live, and file copies are fetched again after.
• If Couver can’t continue: if Couver stops trading or ends support for Couver Evidence, the client’s agreement provides for a licence that doesn’t expire and, in Couver’s cloud, for its data and backups to be handed over. Each install runs on its own server, and the deployment guide and its server commands describe how to run it.

9. Incident response

• Couver keeps a written incident runbook: notice and record, contain (an account, every session and agent connection, a credential or the whole server can be cut off at once from the server), assess from the audit trail, notify, recover and review in writing with the client.
• Couver notifies the client of a personal-data breach without undue delay and within 48 hours, with what happened, the data and people affected, the measures taken and a contact point, so the client can meet its own regulatory deadlines. Details are in the annex.

10. Data retention, return and deletion

• Logs, links and sessions expire on the schedules in the annex; backups rotate out with the generations kept.
• At the end of the contract, for a server in Couver’s cloud, Couver returns the client’s exports on request, destroys the server, its volumes, backups and per-client keys, and confirms the destruction in writing, within 30 days. A server the client runs stays under its control.

11. Support and availability

• Support by email on business days, 08:00–17:00 Central Africa Time (UTC+2), Monday to Friday, Namibian public holidays aside. Response targets:

  Severity	Example	First response
  Critical	Search or sign-in down for everyone; a suspected security incident	4 business hours
  High	A source not syncing, a feature failing for many people	1 business day
  Normal	Questions, one person’s problem, requests	2 business days

• Availability of servers in Couver’s cloud: a target of 99.5% a month, scheduled maintenance announced in advance aside. On-premises, availability follows the client’s server and network.
• A suspected security incident is treated as urgent outside support hours too (section 9).

12. Compliance

• Data processing agreement: the data-handling annex (processor terms, sub-processors, retention, data-subject requests, breach notification).
• SOC 2: not yet held. Couver will consider an independent audit as clients need it; until then this page, the annex and the questionnaire set out its controls.
• Penetration test: an independent test, including the AI agents’ ways in, is planned; the summary will be shared under NDA once done.
• People: administrative access to client servers is limited to named Couver staff, listed in the annex. Anyone given access signs a confidentiality agreement, is background-checked where the law allows, and is trained in these practices before access, and their access ends the day they leave.
• Policies: this page, the annex and the incident runbook are reviewed at least yearly, and when a release changes what they describe.
• Hosting: the hosting provider’s certifications cover the cloud infrastructure, not Couver (ISO/IEC 27001, 27017, 27018; SOC 2 Type II; CSA STAR Level 1).