- Four leak paths: retrieval oversharing, training on inputs, prompt and log retention, over-broad agent access. Four controls, one per path.
- Oversharing is the dominant path because it needs no attacker: a correct answer to the wrong asker is already the incident.
- IBM's 2025 breach report found 13% of organizations had breaches involving AI models or applications; 97% of those lacked proper AI access controls.
- Controls beat policies because controls are inspectable: you can test retrieval with a low-clearance account today.
AI data security for company knowledge means closing the four paths AI systems actually leak through: oversharing at retrieval, provider training on inputs, sensitive text retained in prompts and logs, and over-broad access held by agents. Each path pairs with one control: permission-aware retrieval, written no-training terms, content-blind logging, and least-privilege agent identities. Security is those pairs, verified.
What does AI data security mean for company knowledge?
It means the security of company knowledge once AI systems can read and answer from it, which is a different problem from securing the storage. Encryption and network controls still matter, but the new risk surface is the answering path: what the model can reach, what it emits, and what gets retained along the way.
The base rates say this surface is under-governed. In IBM's Cost of a Data Breach Report 2025, 13% of organizations reported breaches involving AI models or applications, and 97% of that breached group lacked proper AI access controls. The controls below exist so that number stops being surprising.
How do AI tools leak company data?
Through four paths, in descending frequency: an assistant overshares at retrieval because the index ignores permissions; a provider trains on inputs because nobody checked the terms; prompts and logs retain sensitive text longer than the documents they quote; and an agent carries broader access than its task needs. Note what is absent: exotic model attacks.
How AI oversharing happens covers the first path's mechanics in detail, and it deserves the attention: oversharing requires no attacker, no exploit, and no mistake beyond connecting a source whose permissions had drifted. The other three paths are quieter and cheaper to close, which is exactly why they get skipped.
Risk one: oversharing at retrieval. What stops it?
The control is permission-aware retrieval: resolve the asker's identity and clearance before searching, and search only the cleared subset. The wrong version is an output filter after generation, which censors text the model has already read. The right version keeps unauthorized documents out of the model's context entirely.
Verify it the direct way: create a low-clearance account, ask for a named sensitive document, and watch the refusal. Then run the same test through an agent, because agent paths sometimes bypass the checks a chat interface enforces.
Risk two: training on inputs. What stops it?
A written commitment from whoever runs the model, scoped to your product and tier. These now exist across the major providers and take minutes to collect. The Amazon Bedrock FAQ puts it in one line: "your content is not used to improve the base models and is not shared with any model providers."
The catch is scope, not sincerity: commitments attach to specific offerings, and consumer products are often excluded. Bringing your own model key means the commitment is made to you directly rather than inherited through a vendor. File the clause with the rollout record, next to the checklist result.
Risk three: prompts and logs. What stops it?
Content-blind logging: record who accessed which object under which rule, and keep document text out of the log. An audit trail that quotes the documents it audits becomes a second, less-protected copy of your most sensitive data, readable by everyone with log access. Retention policies for prompts deserve the same scrutiny.
Ask each vendor two questions: what exactly appears in your logs, and how long do prompts persist anywhere. Then confirm the log's integrity is verifiable, because an editable audit trail fails at the one moment it is needed. The NIST AI Risk Management Framework frames this as measurable, manageable risk: security you can demonstrate, not describe.
Risk four: over-broad agent access. What stops it?
Least privilege, applied to agents as first-class identities: each agent gets its own key, its own clearance scoped to its task, and its own line in the audit log. An agent using a human's login inherits everything that human can read, and everything it does gets attributed to someone else.
The four pairs compose into an architecture, and a secure AI brain for company knowledge describes it end to end. Before rollout, run a pre-rollout safety checklist against all four controls at once. AIVM Brain, from AIVM, the company behind Brain, ships the four controls by default and is free to start.