AI data security: four places company knowledge can escape

A fictional team prohibits model training on its documents, then gives an assistant a tool that can email them outside the company. The training commitment may still hold while the information leaves. AI data security starts by separating where a problem can occur, so each control addresses the right risk.

Four useful risk categories, not a ranking

The four categories below help you trace information from a source through an AI workflow. They are neither an exhaustive threat model nor a ranking of incident frequency. Application vulnerabilities, prompt injection, compromised accounts and ordinary human mistakes can cross several categories.

Keep encryption, account security and infrastructure controls in scope too. AI-specific safeguards do not replace them. Our narrower question here is what happens once a tool can use company knowledge.

1. Retrieval gives someone information they should not receive

There are two different failures. The retrieval system may ignore an actual restriction. Or it may faithfully apply permissions that are already too broad. Fixing the first requires an enforcement change; fixing the second requires the source owner to correct the grant. A better prompt does not resolve either.

Scope retrieval to the acting user or service and inspect the information returned, including titles and citations. Test allowed and denied paths with fictional documents before relying on them for restricted material. The five-check access exercise supplies a complete fixture.

This reduces a defined exposure path. It does not establish protection across every connector, cached answer or future configuration.

2. A processor uses the data in an unintended way

Identify the service and account receiving the prompt, retrieved excerpts and attachments. Read the applicable terms and settings for model training, processing, retention and human access. A statement about one of these does not answer the others.

A customer-supplied model key changes part of the setup, but does not by itself prove who has a contract with whom or eliminate intermediaries. The knowledge application may still handle the request before it reaches the model provider. Map the actual route.

Keep a scoped policy or contractual commitment as that kind of evidence. A browser test cannot demonstrate whether a provider uses retained requests for training.

3. A copy outlives its intended purpose

Information can remain in an imported document, conversation, cache, export or activity record. Deleting the original file is not proof that every copy has disappeared. Identify the locations and their removal procedures before treating source deletion as the end of the workflow.

Minimize sensitive text in operational logs and restrict access to the records you need. OWASP’s logging guidance addresses excluding sensitive fields, protecting logs and retention. Omitting document text helps, but a revealing title, user identifier or query can still be sensitive.

A record can help explain an incident without proving that nothing happened outside its coverage. Retain enough context for investigation while limiting unnecessary data collection.

4. An agent can do more than its task requires

A briefing assistant that only needs to read documents should not automatically receive tools for sending email, deleting files or changing permissions. The risk is the combination of available operations, credentials and autonomy.

OWASP’s excessive-agency guidance distinguishes those three dimensions. Restrict the actual tools and downstream grants, and require suitable authorization for consequential actions. A friendly agent name is not an access boundary.

For the fictional email example, disabling the unnecessary send operation addresses an exposure path the no-training commitment never covered. It still leaves the reading permissions and retained copies to review.

Choose the next control from the data route

Start with one real proposed workflow and mark where information can be read, stored, forwarded or changed. If a document reaches an unintended recipient, determine whether the problem was a bad grant, a bypass, a retained copy or an enabled action before choosing a fix.

For HeyBrain, the privacy policy is a starting point for documented processing and retention. It is not a claim that every control described here is currently supplied by every account or integration.

Use the pre-launch review when you are ready to decide whether a particular scope can go live. The useful outcome is a risk matched to a specific control and owner, not a universal “secure” label.

Prepared by HeyBrain Editorial Team with AI assistance. Examples are fictional illustrations, not observed customer incidents or product tests. This correction retains the original publication date and removes unsupported security guarantees. Primary sources were checked on 13 October 2026.