Protect Company IP With AI: Keep Know-How Out of Shared Models

To protect company intellectual property when using AI, decide which knowledge may leave your control, then enforce that decision with contracts, architecture and permissions rather than policy memos alone. Keep trade secrets, playbooks and client knowledge in systems you own, let agents retrieve them only at the moment of a task, and confirm in writing that no vendor trains on or retains them. The rest is routine operations: review access, log what the agent touches, and rehearse how you would revoke it.

Key takeaways

• Most leaks come from convenience, such as pasted documents, broad connectors and unread default settings, not from attackers.
• Sort your knowledge into protection levels before choosing tools, so the most sensitive material never reaches a shared model.
• Retrieval from a store you control is easier to govern and to delete than training a model on your documents.
• Vendor terms on training, retention, subprocessors and deletion must be written down and reviewed, not assumed.
• Narrow permissions, activity logs and a recurring review keep an agent's reach matched to its role.

Where does company know-how actually leak?

Leaks rarely look like theft. They look like convenience. An employee pastes a client proposal into a public chat tool to tighten the wording. A team connects a note-taking assistant to every meeting. A vendor's default setting keeps conversation history longer than anyone read in the terms. None of this is malicious, and each case moves know-how outside your control.

Four routes are worth mapping first:

• Prompts and uploads: staff paste documents into tools the company has not approved or configured.
• Vendor retention and training: a provider stores inputs, or uses them to improve its models, under terms nobody reviewed.
• Connectors: an agent is wired to a drive, CRM or wiki with far broader access than its role needs.
• Outputs: answers, drafts and summaries carry confidential material to people or channels that should not see it.

The OWASP Top 10 for LLM Applications names sensitive information disclosure as one of the recurring risks in this kind of system, which matches what operations teams see in practice. For the wider strategic picture, see protecting company know-how as AI agents grow more capable.

Which knowledge deserves which level of protection?

A single rule for all company information fails in two directions. Either it blocks useful work on harmless material, or it lets sensitive material travel as freely as a press release. A short classification gives you a rule per level.

Use this decision guide for each body of knowledge, such as a pricing model, a delivery playbook or a client file:

• Public or marketing material: may be used with approved shared tools.
• Internal, low sensitivity (meeting notes, general process documents): approved tools only, with no-training and limited-retention terms confirmed.
• Client confidential: only in environments covered by contractual confidentiality, with access limited to the client team and answers drawn by retrieval.
• Core know-how (pricing logic, methods, formulas, source code, unreleased strategy): stays in systems you control, and an agent sees only narrow, task-level excerpts, or nothing.

To place an item, ask three questions. Would a competitor gain an advantage from it? Do we owe a duty of confidentiality to a client or partner? If it spread, could we ever pull it back? Two yes answers usually mean the top level.

The classification also helps with trade secret protection itself. Legal protection for trade secrets generally depends on the company taking reasonable steps to keep them confidential, so a documented, applied classification is useful evidence. Ask your counsel how that applies in your jurisdiction.

Why does retrieval protect know-how better than training?

There are two broad ways to make an AI system know your business. You can train or fine-tune a model on your documents, which bakes patterns into the model itself. Or you can keep the documents in your own store and let the agent retrieve the relevant passages for each task. AWS prescriptive guidance compares these options, and the governance difference is clear.

With retrieval, the knowledge stays in a place you own, with its own access rules. You can remove a document and it stops being available. You can restrict a passage to one team. You can see which passages were fetched for which answer.

With training, knowledge becomes part of a model's weights. Removing one document later is hard, access rules do not travel with it, and if the model sits with a vendor, you have placed your most valuable material in a system you may not be able to inspect or fully withdraw from.

Retrieval is not automatically safe. Retrieved passages are still sent to the model at the moment of the task, so the provider's terms on retention and training still matter. That is why architecture and contracts work together. A one-page map of where each piece lives helps; the AI stack architecture map shows how to draw it.

What should a vendor agreement say about your data?

Marketing pages are not contracts. Before any tool touches client or core material, get written answers to a short list, from the vendor or from the agreement itself.

• Is customer content used to train or improve models, by default or through a setting someone could change?
• How long are inputs, outputs and logs retained, and who at the vendor can read them, including support staff?
• Where is data processed and stored, and which subprocessors are involved?
• Can you export and delete everything, including indexes and embeddings built from your documents, and receive confirmation of deletion?
• What happens to your data and configuration when the contract ends?
• What are the vendor's duties to tell you about an incident, and within what timeframe?
• Are staff using personal accounts alongside the company account, and can the company account be enforced?

Exit terms matter as much as entry terms. If your playbooks live in a format only one vendor can read, protection and dependence become the same problem. Read how to avoid AI vendor lock-in with business agents before you sign.

How do permissions and logs limit what an agent can expose?

Even a well-contracted agent can leak if it can reach everything. The principle is old and sound: give each agent the least access its role needs, deny by default, and check authorization on every request. The OWASP Authorization Cheat Sheet describes these ideas, and they apply directly to agents and the tools they call.

In practice:

• Give the agent its own identity, separate from any employee, so its access can be changed or removed without side effects.
• Start with read-only access and add write or send abilities one at a time, each with an owner.
• Scope connectors to specific folders, client records or wiki spaces, not whole systems.
• Require human approval before the agent sends anything outside the company or shares material across client boundaries.
• Log which sources the agent retrieved and which actions it took, so a question about an answer can be traced.

Prompt injection deserves a mention. A document or web page the agent reads can contain instructions that try to make it reveal or forward other material. Narrow permissions limit the damage, because an agent that cannot reach the playbook cannot be tricked into sending it. Access also drifts over time, so schedule a recurring check. The steps are in how to run a permission review for your AI agents.

An illustrative scenario: a client playbook and a contractor

This is an illustrative scenario, not a real case. A small advisory firm has a client onboarding playbook that took years to refine. It wants an agent to draft onboarding plans, and it brings in a contractor for a few weeks to help with setup.

The firm does the following:

• Moves the playbook into a company-owned store with separate sections for method, templates and client-specific notes.
• Classifies the method as core know-how, so the agent retrieves only the step relevant to the current task and never the whole document.
• Limits the agent's read access to the active client's folder, so one client's notes cannot appear in another client's plan.
• Gives the contractor access that ends on a fixed date, following time-boxed rules for contractor access, and removes it at handover.
• Reviews the retrieval log monthly and checks that nothing outside the intended folders was read.

Nothing here depends on a clever tool. It depends on knowing what is valuable, where it lives and who, or what, may read it.

How does a managed approach handle this?

Be Human designs, implements and operates agents whose identity, memory, channels, tools and permissions stay under the company's control. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Know-how is kept in stores the company controls and reached by retrieval, with access scoped to the role. Managed operations can include monitoring, permission review, integration maintenance, incident response and controlled improvements, so protection continues after launch instead of ending at setup. The NIST AI Risk Management Framework is a useful reference for the governance side of this work.

Take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Does using an AI tool automatically put our trade secrets at risk? No. Risk depends on what you send, what the vendor's terms allow, and who can access the tool. Approved tools with confirmed no-training and limited-retention terms, combined with a classification that keeps core material out, can be used with reasonable confidence.

Is fine-tuning a model on our documents a safe way to teach it our business? It can be appropriate for some material, but it is harder to govern than retrieval. Knowledge in model weights is difficult to remove and does not carry access rules. For sensitive or client-specific content, retrieval from a store you control is usually the easier choice to defend.

Should we ban public AI tools outright? A ban without an approved alternative tends to push use out of sight. A better approach is to offer an approved tool, state which classification levels it may handle, and explain why the rest stays out. Staff follow rules that still let them do their work.

Who inside the company should own this decision? Assign a named executive, ideally the person responsible for risk or operations, to own the classification and vendor terms, with legal counsel reviewing contracts. Without one owner, each team decides alone and the gaps appear between them. The role is described in executive sponsor for an AI project.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.