How to Protect Product IP in an Agentic Age

How do we use AI without leaking our product IP?

Every product leader with confidential logic, client data, or a roadmap worth protecting is asking a version of it. The answer is a routing rule, not a ban.

You protect product IP in an agentic age the same way you protect it anywhere else: decide what can leave, then make the safe path the easy path. Redact the rest, split it, or route it to a private model. The goal is not to stop using AI. It is to make sure the wrong information never leaves the building.

The short answer. Five moves cover most of it:

Classify before you send. If you could not publish it tomorrow, it does not go to a public model.
Obfuscate the rest. Redact identifiers, split the prompt, or use synthetic stand-ins.
Route by sensitivity. Sensitive work goes to a private or offline model, generic work goes to a public one.
Automate the safe path. A local model gateway can do the redaction, with deterministic rules underneath.
Put it in the vendor contract. The agreement should ban training on your data, define how long data is kept, and require no human review by default.

Why do product IP leaks happen?

When a roadmap lands in a public chat tool, the person who pasted it is usually not careless. They are efficient. The safe option was slower, and the fast option looked harmless. Thomas Gilbert’s behavior engineering model, from Human Competence (1978), says to fix the environment before you blame the person. It is the same framework behind the six-box team diagnostic.

Security bans fail for the same reason. A rule that says “never paste sensitive information into an LLM” asks every person to win a judgment call, every day, under deadline pressure. And security owned by “the team” leaks, for the same reason diffusion of responsibility makes “the team owns it” a recipe for nobody owning it. The leaks that actually hurt are rarely sophisticated attacks. They are someone in a hurry. The fix is to make leaking hard and protecting easy: routing rules, redaction tools, and a private model that is one command away.

How product IP leaks through a third-party LLM

Three points in a normal LLM workflow can expose product information.

The prompt. Anything you type can carry product logic, client names, pricing, or the internal shorthand that only makes sense inside your company.

The context window. Agents and retrieval pipelines pull documents into the request. A benign question can drag your API design or pricing model along with it. The OWASP Top 10 for LLM Applications, maintained by the OWASP GenAI Security Project, names prompt injection and sensitive information disclosure as two of the highest-risk failure modes, because the context is exactly where that information sits.

The vendor’s data pipeline. What the provider does with your prompt and context after the response. Once data enters a third party’s training pipeline, you lose practical control over it. You cannot unpublish a model’s weights. The rules here are being written now, and they are worth tracking: the EU AI Act regulates high-risk and general-purpose models, ISO/IEC 42001 gives you an AI management system to certify against, and NIST’s AI Risk Management Framework ships a generative AI profile for exactly this kind of data-governance risk.

Three leak points: what you type, what retrieval pulls in, and what the vendor trains on. Everything past the dashed line is out of your control.

What can you safely send to an LLM?

Nothing you cannot afford to lose. Before any prompt, classify the information. Could you publish this tomorrow without a second thought? If yes, send it anywhere. If no, it does not go to a public model.

This single rule removes most of the risk, because the leak path is a routing error, not a sophisticated attack. Make the classification a checkbox in the tool, not a judgment call in someone’s head.

How to obfuscate product information before you send it

When the work must use a public model, change the data before it leaves.

Redact the identifiers. Client names, internal codes, and product names become placeholders. The model can still reason about the shape of the problem without knowing who it is for.

Split the prompt. Break a sensitive workflow into pieces that are individually meaningless. The full picture never exists in a single request.

Use synthetic stand-ins. For evaluation and ideation, generate fictional data that mirrors the structure of the real data. You test the pattern, not the secret.

Automate the redaction. A small language model on your own hardware can do the redaction for you. Run it as a prompt gateway between the user and the public harness: it strips client names, codes, and pricing, rewrites internal shorthand, and only forwards a sanitized prompt. Layer deterministic rules underneath, because a model can miss a name it has never seen. Client lists and regex for ID formats catch what the model does not, and the gateway stops the request when a redaction looks uncertain. This is the environment fix from the top of the post, made concrete. Nobody wins a judgment call, because the tool already won it.

The tooling is real and moving fast. NeMo Guardrails applies input, retrieval, and output rails that mask sensitive data before it reaches the model, and Meta’s Purple Llama ships Llama Guard and Prompt Guard for input and output filtering. The same gateway pattern closes leak point two: scrub what agents retrieve before it lands in the context window.

When to use a private or offline language model

The strongest protection is to not use a public model for sensitive work at all. A self-hosted model runs on your infrastructure, and no data crosses the boundary.

Large models are not the only option. Small language models (SLMs), open-weight models like Llama, Mistral, and Qwen, now run on ordinary hardware and cover a real share of product work: classification, extraction, drafting, summarization. For those tasks a private small model is often fast enough, cheap enough, and fully inside your perimeter. Tools like Ollama and the Hugging Face model hub make this a laptop install, not a data-center project. When the data cannot leave, offline is the only answer that closes the question completely.

The practical pattern is hybrid. Public frontier models for generic, high-value work. Private local models for anything that touches product logic or client data. Sensitive to private, generic to public.

The routing rule in practice: sensitive to private, generic to public. The gate in the middle is rule one, never send what you cannot afford to lose.

What should your AI vendor contract include?

Whatever leaves must be covered in writing. The vendor contract should specify no training on your data, defined retention, and no human review by default. These clauses exist in the enterprise tiers of the major providers. OpenAI’s enterprise privacy commitments, for example, state no training on your data by default and retention controls you own. Ask for the same terms before you send anything, not after. For regulated and client-confidential work, a data processing agreement with those three clauses is the floor, not the ceiling.

How to keep ideation cheap and fast

Protection does not mean paralysis. As small open-weight models improve, the cost of the private route keeps falling. An SLM on a single GPU, a local embedding model, and a thin policy layer can cost less than the enterprise seat you already pay for. Ideation stays cheap because most ideation does not need the frontier model.

The teams that win in the agentic age are not the ones that block AI. They are the ones that route it. Sensitive to private, generic to public, and nothing sent that cannot be lost.

What is the one prompt your team sends that you would not want published? If you can name it, that is where your protection starts.

Questions or pushback? s@spencervaradi.com.