Protecting Company Know-How as AI Agents Grow More Capable

To protect intellectual property when you use AI, keep your trade secrets and process knowledge in memory that your company owns and controls, and let agents reach it only through scoped, logged access. The model can be rented and replaced. The know-how must not be. As agents become more capable, they can do more with what they read, so the rules around that knowledge matter more, not less.

Key takeaways

• Know-how is usually protected by how you handle it, so access rules, logs and contracts are part of the protection, not an afterthought.
• Keep confidential knowledge in company-owned memory that the agent retrieves from, rather than baking it into a vendor's model or a vendor-only format.
• Classify knowledge by sensitivity and decide, for each class, what an agent may read, draft and send.
• Give each agent the least access its role needs, review that access on a schedule, and keep the evidence.
• Plan the exit from day one: you should be able to export, restore and move your memory to another model or provider.

What counts as know-how, and how does it leak?

Know-how is the knowledge that lets your company do something better than a competitor holding the same tools. It includes pricing logic, supplier terms, the exception rules your senior people apply without thinking, formulations, the order in which you qualify a lead, and the checklist behind a clean delivery. Much of it is not registered anywhere. It is protected, if at all, by being kept confidential.

In many jurisdictions, trade secret protection depends in part on whether the company took reasonable steps to keep the information secret. That makes everyday handling a legal matter as well as an operational one. This article is operational guidance, not legal advice, so involve your counsel when you set the rules.

In agent projects, leaks rarely look dramatic. They tend to look like ordinary convenience:

• Staff paste internal documents into a consumer chat tool because it is quick and nobody offered an approved alternative.
• Vendor terms allow inputs to be retained or used to improve their products, and nobody read the clause.
• The agent's memory sits in a proprietary format that cannot be exported, so leaving the vendor means leaving the knowledge.
• An agent has broad read access and surfaces a confidential document to someone who should not see it.
• Hostile text inside an email or web page tells the agent to reveal or forward information. This is called prompt injection, and the OWASP Top 10 for LLM Applications lists it as a leading risk.
• A contractor or former employee keeps access that nobody remembered to remove.

None of these needs a clever attacker. They need a missing decision. The rest of this article is about making those decisions on purpose.

Why do more capable agents raise the stakes?

A more capable agent reads longer documents, keeps track of more context, uses more tools and acts with less supervision. Two things follow. First, each piece of your knowledge becomes more useful to the agent, so you will be tempted to hand over more of it. Second, an agent that can act has more routes by which information can leave: an email draft, a shared file, a call to an outside service.

There is also a strategic reason. As strong models become widely available, they start to look like a shared utility. What separates one company from another is what it brings to the model: its procedures, its history, its judgment about exceptions. That is exactly the material an IP strategy should protect. For a wider view of this idea, see Superintelligence and Intellectual Property: Protect What You Know.

The practical conclusion is not to withhold knowledge from agents. An agent with no context is not useful. The conclusion is to decide where the knowledge lives, who and what may reach it, and what happens when you change providers.

Where should company knowledge live?

The safest default is company-owned memory: a store that you control, in a format you can export, with access rules, version history and logs. The agent retrieves the relevant pieces when it needs them for a task. The knowledge stays in your store. The model sees only what the task requires.

This differs from fine-tuning, where knowledge is trained into a model's weights. AWS guidance on retrieval versus fine-tuning describes the trade-offs, and for confidential facts retrieval has practical advantages:

• You can remove or restrict a document and the change takes effect on the next retrieval.
• You can restrict by role, so a sales agent does not retrieve what a finance agent can.
• You can log what was retrieved and for whom.
• You can swap the model without losing the knowledge.

Fine-tuning still has uses, such as shaping tone or a narrow behavior. It is a poor home for facts you may later need to withdraw or restrict. For the lock-in side of this choice, read Superintelligence Vendor Lock-In: Keep the Gains In-House.

Not all knowledge deserves the same treatment. Use this decision guide:

• Public or low-sensitivity material, such as published product descriptions and FAQs: available to the agent broadly.
• Internal procedures and playbooks: company memory, available by role.
• Confidential material, such as pricing logic, supplier terms and customer-specific rules: company memory, restricted by role, every retrieval logged, and a person approves anything the agent sends outside the company.
• Core differentiators, such as a proprietary formula or method: kept out of agent memory by default. Give the agent a description of what the method produces, and include the method itself only when an accountable owner decides it is worth the exposure.
• Personal data: governed by data protection rules and treated separately, with its own access and retention decisions.

What is a practical plan to keep know-how inside company memory?

You do not need a large program. You need a short sequence that one accountable person can run. Treat the steps below as a plan for the first agent, then repeat it for each new role.

• Step one: name an owner. One person is accountable for what knowledge the agent may use. Without a name, every decision is deferred.
• Step two: inventory the knowledge the role needs. List the documents, rules, spreadsheets and unwritten habits the agent would require to do the job. Ask the people who do the work, not only the managers.
• Step three: classify each item using the guide above. When unsure, choose the more restrictive class and revisit it later.
• Step four: place the approved knowledge in company-owned memory. Use formats you can export, keep version history, and record where each item came from.
• Step five: scope access by role and task. Deny by default and grant only what the role needs, in line with the least-privilege principle described in the OWASP authorization guidance. Give the agent its own credentials rather than a person's login.
• Step six: log and review. Record what the agent retrieved and sent, and review permissions on a schedule. How to Run a Permission Review for Your AI Agents, Step by Step shows the method.
• Step seven: prove you can leave. Back up the memory, restore it into a clean environment and check that it works. AI Agent Backup and Restore: What to Save and How to Test It explains what to include.

An illustrative scenario: a distribution company wants an agent to draft replies to customers asking about delivery terms. The team lists what the agent needs: standard delivery terms, a regional exceptions table and the rules for when a manager must approve a discount. Standard terms are public, so the agent can read them freely. The exceptions table is confidential, so it is stored in company memory, readable only by the customer-service agent role, with each retrieval logged. The discount rules stay out of the agent's reach entirely. The agent only learns that discount questions go to a named manager. Replies that mention exceptions are drafted by the agent and approved by a person before sending. The agent is useful, and the most sensitive logic never leaves the people who own it.

What should contracts and vendors commit to, and how does Be Human handle it?

Technical controls work best when the contract agrees with them. Before you rely on a vendor or build partner for any agent that touches confidential knowledge, ask for written answers to these questions:

• Are your inputs, outputs and memory used to train or improve any model, and can that be turned off in the agreement itself?
• How long is your data retained, and how is it deleted when you ask?
• Who owns the memory, the prompts, the workflows and the tool configurations the vendor builds for you?
• In what format can you export all of it, and how quickly?
• Which subcontractors and which regions touch your data?
• What access do the vendor's own staff have, and how is it logged?
• What happens to your knowledge and credentials when the engagement ends?

For a deeper check on how to test what a supplier tells you, see Superintelligence Vendor Evaluation: Evidence, Questions, Red Flags. The NIST AI Risk Management Framework is also a useful reference for structuring these governance conversations in plain terms.

Be Human designs, implements and operates AI agents whose identity, memory, channels, tools and permissions remain under the company's control. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and a success criterion that can be observed. Managed operations can include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so the access rules described above are kept current rather than set once and forgotten.

If you want to find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI vendor train its models on my company's data? It depends on the product, the plan and the contract, and the defaults are not the same everywhere. Read the data-use terms, get the answer in writing, and prefer arrangements where training on your inputs is excluded in the agreement itself.

Is a prompt or workflow my intellectual property? Often it is treated as confidential business information, but how much protection it gets varies by jurisdiction and by how you handle it. Keep prompts and workflows in a repository your company owns, state ownership in the contract, and ask your counsel how it applies to you.

Should we ban employees from using public AI tools? A ban with no alternative usually pushes the usage out of sight. It works better to provide an approved agent or tool, explain which classes of knowledge may be used with it, and make the approved route easier than the unapproved one.

How often should we review who and what can reach our knowledge? Review whenever the agent's role, tools or users change, and on a regular schedule even when nothing seems to have changed. Check that access still matches the role, that departed people and finished contractors are removed, and that the logs show nothing unexpected.

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