Are embeddings themselves sensitive data?

Treat them as derived data carrying the sensitivity of their source. Embeddings are not human-readable and inversion attacks that recover approximate source text from vectors are an active research area, so the security assumption that a vector is safely opaque has a shorter shelf life than most architectures. The more immediate point is upstream: producing the embedding required sending the source text to the provider, so the disclosure already happened at index time regardless of what the vector reveals afterwards. Classify at the moment the chunk is sent.

Does reranking send full document text?

Yes, that is how it works. The endpoint scores candidate documents against a query, which requires the candidate text. A retrieval configuration returning a large candidate set sends every candidate for every query, so document content leaves the boundary continuously during normal operation rather than once at index time. Measuring the candidate count and reducing it where answer quality permits is one of the few controls that lowers data movement without adding a component.

How do we classify a 40,000-document corpus without drowning in alerts?

Classify per chunk and report per corpus. The classifier evaluates every chunk before it is sent, and the operator receives a single report giving counts by classification, the documents contributing to each, and the items blocked. That converts an unreviewable alert stream into a remediation task with a defined scope. Block the highest-severity classes inline, such as credentials, and route the rest into the report for a data-owner decision about whether those documents belong in the index at all.

Does a private deployment remove the DLP requirement?

It removes the third-party disclosure, which is a meaningful part of the problem and not all of it. Regulated data still needs access control, audit evidence and retention handling wherever it is processed, and a private model deployment is a system processing that data. Internal misuse, over-broad retrieval and the absence of a per-decision record all persist. What changes is that the exposure becomes internal rather than a cross-boundary disclosure, which alters the regulatory analysis without eliminating it.

How do we get identity onto a batch job?

Carry the requesting human alongside the service credential. The job runs under a service account by necessity, and the record needs the person who scheduled or triggered it, propagated as an explicit field in the request. This is application and pipeline work rather than something a downstream control can infer. Without it, an audit reconstructs a large disclosure attributable to a cron entry, which fails the first question anyone asks about it.

What if the same model is reachable through several deployment paths?

Write policy against content and identity rather than destination hostname, and enforce it at a boundary every path crosses. A managed API endpoint, a Bedrock invocation, an Azure Foundry deployment and a private endpoint are four network identities for the same capability, and hostname-based controls cover them one at a time while new paths appear faster than rules get written. Routing all model traffic through a single enforcement point makes the deployment-mode question an infrastructure detail rather than a policy gap. The general practice is covered in LLM DLP.

Cohere DLP: The Embedding Pipeline Moves More Data Than the Chat Endpoint

An engineer runs an indexing job at 2am against a 40,000-document knowledge base. Every document is chunked and sent to an embedding endpoint. By morning the corpus has been vectorized, retrieval works well, and the AI usage dashboard shows a quiet night with a handful of chat requests.

That job moved more organizational content across the network boundary than the chat endpoint will carry in a year. An AI DLP programme that covers conversational traffic and ignores the embedding pipeline has instrumented the smaller half.

Cohere makes this concrete because its enterprise usage is weighted toward retrieval. I want to walk through the three endpoint families, what each moves, and where classification belongs.

Three endpoint families, three data profiles

The Chat endpoint carries what a user or an application asked, plus whatever context the application assembled. The volume is human-paced and the content is deliberate. This is what most AI DLP tooling was built to see.

The Embed endpoint carries whatever is being indexed. At corpus build time, that is the entire document set. At query time, it is the user's query. The batch profile is the interesting one, because indexing jobs run on schedules, process everything they are pointed at, and produce no per-item human review. Content excluded from a corporate DLP scan because it sat in a repository considered low-risk gets embedded along with everything else.

The Rerank endpoint carries the query plus the candidate documents to be scored. That means the document text itself leaves the boundary at query time, not just the vectors, and it does so for every candidate in the set rather than the one that eventually gets used. A retrieval configuration returning fifty candidates for reranking sends fifty documents to score one answer.

Sorting a Cohere deployment by endpoint family, and measuring the content volume through each, is the exercise that reorders most teams' priorities.

Why the embedding path escapes normal controls

Three properties combine to make it invisible.

It runs as infrastructure rather than as user activity, so it appears in job schedulers rather than in AI usage reports. Bulk processing compounds this: a single execution moves everything at once instead of producing a stream of reviewable events. The builders are usually a platform or data team solving a retrieval problem, at a point in the project where the security review has already happened against the chat interface.

The result is a data-movement path with the largest volume, the least human oversight and the lowest chance of appearing in an AI governance inventory. When an organization first classifies its embedding corpus, the finding is reliably that the index contains categories of data nobody intended to send anywhere.

Deployment mode makes hostname allowlisting fragile

Cohere models are reachable in several ways: the managed API, deployments through cloud marketplaces such as Bedrock and Azure AI Foundry, and private or VPC deployments for organizations that need the models inside their own environment.

That flexibility is a genuine advantage and it breaks a common control pattern. A network policy that allowlists a provider hostname governs one of those paths. The Bedrock route presents as an AWS endpoint. The Azure route presents as an Azure endpoint. A private deployment presents as an internal hostname. Same model family, four network identities, and a hostname-based control covers whichever one it was written for.

Policy that follows the request rather than the hostname is what survives a deployment-mode change. The classification and authorization decision should depend on what the content is and who is sending it, not on which DNS name the traffic happens to resolve to this quarter.

What Cohere DLP has to classify

The classes are the organization's own, applied at three different granularities.

For chat traffic, classification runs on the assembled prompt, which is the practice covered in prompt-level DLP.

For embedding traffic, classification runs per chunk before the chunk is sent, and the useful output is a corpus-level report rather than a per-request alert. Nobody can action 40,000 alerts. A summary saying that 1,847 chunks across 212 documents carried customer PII and 46 chunks carried credentials is a document that gets acted on, and it turns an indexing job into a scoped remediation task.

For rerank traffic, classification runs on the candidate set, and the finding that usually matters is a configuration one: reducing the candidate count from fifty to fifteen cuts the content leaving the boundary by seventy percent. Whether answer quality holds at the lower count is a per-corpus measurement, and the tuning change is available to any team that runs it.

The broader classification practice is covered in AI data classification.

The record

An indexing job needs a different record shape than a chat request, because the unit of interest is the batch.

decision_id: d-b31047, recorded at 2026-08-13T02:14:51Z
originating_identity: svc-index-builder, the service account the job ran under
requested_by: d.ferreira@example.com, the human who scheduled it
endpoint_family and batch_id: embed, idx-2026-08-13-a
items_submitted: 40,318, of which 46 were blocked
classifications: customer-pii on 1,847 chunks, credentials on 46, contract-terms on 903
policy: corpus-egress-v2, outcome: partial-block

The requested_by field carries the human who scheduled the job, which is what makes a batch attributable months later. A record showing only the service account attributes 40,000 disclosures to a cron entry.

DeepInspect

This is the gap DeepInspect closes across all three families. DeepInspect sits at the AI request boundary as a stateless proxy between your users, applications and agents and the model endpoints they call, including chat, embedding and reranking endpoints. Content is classified before the request is forwarded, policy is evaluated against the identity that originated it, and a per-decision record is written under your control. Enforcement is inline and fails closed.

DeepInspect is model-agnostic and deployment-mode-agnostic, which is what matters when the same model family is reachable through a managed API, two cloud marketplaces and a private deployment. The policy is written once against content and identity, and it applies regardless of which hostname the traffic goes to. It does not build your retrieval pipeline, tune your chunking, or manage your vector store.

If your embedding pipeline has never been classified, the first step is finding out what is already in the index. Book a demo today.