.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
How to Train AI Agents on Proprietary Knowledge Without Giving It Away IP Protection Strategies for SaaS Companies
Every SaaS company with valuable customer data now faces the same uncomfortable question: How do we make an AI agent useful enough to understand our proprietary knowledge without turning that knowledge into a reusable asset for someone else?
The stakes are commercial as much as technical. A support agent that can use a customer’s product catalog, policies, contracts, and case history can resolve work that once required a trained employee. A revenue operations agent can qualify leads using the company’s own playbooks. A compliance agent can apply internal controls with a consistency that a generic model cannot match. Yet each of those gains creates a new obligation: preserve the customer’s control over the data, the SaaS company’s control over the product, and both parties’ ability to prove where knowledge went.
Our view is clear. SaaS companies should keep raw proprietary knowledge out of broadly reusable model weights, use permissioned retrieval as the default way to ground agents, reserve fine-tuning for tightly scoped behavior improvements, and sell autonomous proprietary-knowledge agents primarily by verified resolution. An annual platform commitment should fund the protected knowledge layer, but the primary meter must track the work the agent completes.
The core IP decision is what never enters the model weights
“Training on proprietary knowledge” describes several very different technical choices. Treating them as one choice leads companies to overuse fine-tuning, underinvest in access controls, and make promises that their architecture cannot support.
A large language model can answer a question from private information in at least three ways. It can retrieve approved documents at the moment of a request. It can be fine-tuned on examples that teach a narrow behavior. Or it can absorb raw material through continued pretraining or broad model training. Only the first approach reliably keeps the source material outside the model’s learned weights.
That distinction matters because model weights are difficult to inspect, isolate, and unwind. Research presented at the 2021 USENIX Security Symposium demonstrated that adversaries could extract individual memorized training examples from language models through queries. NIST’s July 2024 Generative AI Profile likewise identifies confidentiality, training-data integrity, and indirect prompt injection as material risks across the AI lifecycle.
The practical design choice is therefore not “RAG versus training” in the abstract. It is a decision about which parts of the customer’s knowledge remain outside the model and under ordinary software controls.
| Knowledge approach | What changes | What remains under direct customer control | IP risk if poorly implemented | Recommended role |
|---|---|---|---|---|
| Permissioned retrieval | The agent receives selected document passages at query time | Source files, permissions, retention, and document deletion | Unauthorized retrieval or bad output filtering can expose content | Default design for proprietary facts and policies |
| Fine-tuning on curated examples | The model learns task patterns, formats, and preferred decisions | Training set can be narrow, redacted, and tenant-specific | Examples may be harder to remove once learned | Use for behavior, not raw knowledge |
| Continued training on raw corpora | The model absorbs a large body of customer material into weights | Very little, after training is complete | Memorization, weak deletion, and unclear reuse boundaries | Avoid for tenant knowledge |
| Prompt, cache, and tool logs | The agent stores temporary working context outside weights | Retention settings, encryption, and access logs | Sensitive copies persist longer than intended | Treat as regulated production data |
The table points to a simple operating rule: teach agents how to work; retrieve what they need to know. A legal-support agent can be fine-tuned to produce a preferred issue-spotting format, for example, while retrieving the client’s current contract clause library only when an authorized user asks for it.
Major model providers increasingly offer contractual commitments that support this architecture. OpenAI states that it does not train on business data by default across its API and enterprise products. Microsoft states that Azure-hosted model prompts, completions, embeddings, and fine-tuning data are not used to train foundation models without customer permission. Amazon Bedrock states that fine-tuning data is used only to create the customer’s custom model and not to train base Titan models or distribute data to third parties.
Those commitments are necessary, but they are not enough. A “no training” promise does not prevent a poorly permissioned retrieval system from showing a sales representative the CFO’s board materials. It does not prevent a malicious document from injecting instructions into the agent’s context. Nor does it determine whether a SaaS company can delete all customer-derived artifacts when a contract ends.
Permissioning, not a no-training promise, is the real control
An agent should never decide what a user is entitled to see. Authorization must happen before retrieval, outside the model, using the same identity and entitlement system that governs the source application.
Consider a multi-tenant billing platform. A customer success manager may be allowed to see account health, renewal dates, and open support cases. That manager may not be allowed to see payroll data, internal legal memos, or another customer’s usage records. If the agent retrieves documents first and asks permission questions later, the architecture has already failed.
NIST’s July 2024 guidance warns that indirect prompt injection can arise when malicious instructions are placed in data likely to be retrieved by an AI-enabled application. The risk grows when the agent can call tools, browse repositories, or write to downstream systems.
The protected knowledge layer therefore needs five non-negotiable controls:
- Entitlement-aware retrieval. Filter documents by tenant, user role, geography, matter, project, and document classification before selecting passages for the model.
- Separate trusted instructions from untrusted content. A PDF, ticket, email, or knowledge-base article is data, not an instruction source for the agent.
- Least-privilege tool access. Give the agent narrowly scoped service credentials instead of a shared administrator token.
- Short retention and deletion evidence. Set explicit retention periods for prompts, retrieved passages, embeddings, caches, and evaluation datasets, then retain proof that deletion occurred.
- Continuous adversarial testing. Test for cross-tenant retrieval, prompt injection, secret exposure, and unauthorized tool calls before launch and after major changes.
A company that follows these controls can make a stronger promise than “we do not train on your data.” It can say: “Your data remains in your controlled knowledge layer; the agent receives only the minimum authorized context required for the current task.”
That promise is easier to sell, easier to audit, and easier to defend after an incident.
Monetizely’s 5-Step Pricing Framework places these decisions in an order that protects both adoption and margin: define the company’s goals and customer segments; build packages that match those segments; choose the pricing metric; set the actual price points; then make the model work through billing, data, and sales operations. As discussed in Monetizing Agentic AI, the sequence matters because a pricing metric cannot repair a package built for the wrong buyer.
For proprietary-knowledge agents, Step 1 starts with a sharper segmentation question than classic SaaS: whose knowledge is being used, and what job does that knowledge let the agent complete? A 50-person software company asking an agent to draft answers from a public help center has a different need from an insurer asking an agent to adjudicate policy-service requests across claims, billing, and policy systems.
Package design follows from that distinction. Small customers may need a secure connector, a bounded workflow, and a standard resolution definition. Enterprise buyers may require identity integration, region-specific deployment, approval controls, audit exports, multiple knowledge domains, and named implementation support. Selling both groups the same “AI add-on” produces either shelfware at the low end or discount pressure at the high end.
A protected knowledge layer should therefore be packaged as a core product capability, not buried as a professional-services exception.
| Package component | Standard protected-agent offer | Enterprise protected-agent offer | Why it belongs in packaging |
|---|---|---|---|
| Data connection | Approved connectors and scheduled indexing | Custom connectors, private networking, and regional controls | Determines what knowledge the agent can use |
| Access model | Role-based access and standard audit logs | Fine-grained entitlements, delegated administration, and exportable logs | Determines who can see what |
| Knowledge operations | Document refresh, basic source citations, and deletion workflow | Quality monitoring, policy review, evaluation suite, and named governance reviews | Determines whether the agent remains trustworthy over time |
| Agent scope | One bounded workflow | Multiple workflows with controlled tool access | Determines the value the buyer receives |
| Commercial commitment | Annual platform commitment plus prepaid outcome allowance | Annual platform commitment plus contracted resolution volume and true-up rules | Funds fixed protection while scaling with completed work |
The commercial implication is important. Security controls are not merely internal cost centers. They are part of the product a serious buyer is purchasing.
The Agentic Monetization Spectrum, or AMS, clarifies the pricing metric by rating an agent on three dimensions. First, zero-human ability asks how much work remains with a person: small when the person still performs most of the task, medium when the agent executes and a person reviews, and large when the agent completes the work. Second, operational domain asks whether the agent handles one task, an end-to-end workflow in one function, or work across several functions. Third, the output/cost ratio asks whether value rises roughly with inference cost, outpaces it by a meaningful margin, or dwarfs it. The more autonomous, broad, and valuable an agent becomes, the less credible a seat becomes as the core unit of value.
A proprietary-knowledge agent that resolves customer, claims, compliance, or operations work typically lands beyond the point where a named user is the natural anchor. The human may configure, review exceptions, and approve risky actions. The agent, however, completes the repeatable work.
The score explains a non-obvious result. A protected knowledge layer does create fixed costs, but that does not make per-seat pricing the answer. It makes a platform commitment plus outcome pricing the right architecture: the platform commitment covers the fixed protected environment, while verified resolutions measure the agent’s delivered work.
The market already shows four broad approaches: per-resolution, platform-plus-consumption, per-seat, and flat access. Each reflects a different level of agent autonomy and a different willingness to expose buyers to variable spend.
The evidence supports a clear distinction. Copilots such as GitHub Copilot and Cursor still enhance a person’s work, so a seat remains understandable. Customer-facing and operations agents such as Fin and Sierra are paid for work completed, because their buyer is not purchasing more human assistance. The buyer is purchasing fewer unresolved cases.
Salesforce is especially instructive because it exposes the transition. Its current price architecture offers action-based, conversation-based, resolution-based, flat-access, and per-user paths. That flexibility may help a broad platform serve many use cases, but it also illustrates why SaaS companies should not copy a menu of meters without a point of view.
Monetizely’s position is that proprietary-knowledge agents should not begin with a menu. They should begin with a verified definition of completed work.
Cost-based meters surrender price precisely when the product improves
Token, credit, and API-call pricing may protect gross margin during an early product phase. They are useful internal cost measures. They are weak long-term value measures for agents that use proprietary knowledge to complete business workflows.
The reason is economic. If the customer pays mainly for inference, the vendor’s revenue falls as model routing, caching, retrieval quality, and model prices improve. The customer still receives the same resolved claim, compliant report, qualified lead, or closed support case. In fact, the outcome may improve as the agent gains better data and stronger workflows.
A support agent illustrates the problem. Assume the agent uses $0.15 of model and retrieval cost to resolve a case that would otherwise consume $6 of support labor. If system improvements lower cost to $0.03, a token-linked price will face pressure to fall with cost even though the avoided labor remains close to $6. A resolution price, by contrast, can retain a stable share of the value while the vendor expands margin through better engineering.
That does not justify charging for vague claims of “AI value.” Resolution must be objectively defined. Intercom’s July 2026 documentation, for example, defines a resolution as a case where no further help is requested after the last AI answer. Zendesk’s August 2026 documentation similarly defines automated resolutions as customer requests resolved by an AI agent without escalation to a human agent.
For a proprietary-knowledge agent, the definition should be specific to the job:
- A support resolution: the issue is answered from approved sources and no human takes the case within an agreed window.
- A claims resolution: the agent gathers required facts, applies the stated policy rules, and produces an approved disposition.
- A compliance resolution: the agent completes evidence collection, identifies exceptions, and produces a review-ready record.
- A revenue-operations resolution: the agent verifies qualification criteria and creates a complete, accepted handoff.
The company must measure the work in a way that finance can invoice and the customer can audit. Without that discipline, outcome pricing becomes a sales slogan rather than a commercial system.
A resolution meter should be primary, but no serious SaaS company should pretend that all costs are variable. Protected knowledge operations require fixed investment before the first resolution occurs: connector maintenance, identity integration, tenant isolation, evaluation infrastructure, logging, policy updates, and implementation.
The answer is not to retreat to seats. It is to create an annual platform commitment that pays for the protected operating environment and then sell prepaid resolution volume with a transparent true-up.
A strong commercial design contains four parts:
An annual protected-agent platform commitment. This funds the knowledge connection, identity controls, audit trail, administration, and baseline support.
A prepaid allowance of verified resolutions. The commitment gives the buyer budget certainty and gives the vendor a base level of contracted volume.
A resolution definition attached to the order form. The definition should state the workflow, system of record, exception rules, reopening window, and treatment of human escalations.
A monthly usage report and an annual true-up. The report should show resolution counts, confidence thresholds, source systems used, escalations, and disputed units.
This architecture also makes IP protection part of the value story. The buyer is not paying a generic “AI platform fee.” The buyer is paying for an agent that can safely operate inside its own knowledge base, under its own permissions, with an audit record that supports a real business process.
Enterprise buyers will scrutinize the contract. They should. Yet the SaaS company’s renewal position will ultimately depend on evidence produced by the product itself.
A protected-agent agreement should state the data rules plainly.
The contract establishes the legal boundary. Product telemetry proves that the boundary held.
That proof should be visible in an executive account review. A customer should be able to see what repositories were connected, how many documents were excluded by policy, how often the agent escalated, which resolution types drove value, and whether any access-control exception occurred. A renewal conversation then becomes a discussion of verified work and controlled risk, not a debate about whether the model may have learned too much.
What SaaS leaders should do next
Adopt a company-wide rule that raw customer corpora do not enter shared model weights. Make any exception a board-level product and legal decision, not an engineering shortcut.
Choose one bounded workflow where resolution can be measured from a system of record. Start with work such as support deflection, evidence collection, account qualification, or policy-service requests rather than an open-ended enterprise assistant.
Build the protected knowledge layer as a priced product capability. Assign its roadmap, operating budget, and reliability targets to product leadership rather than hiding it inside implementation services.
Make verified resolution the primary commercial metric from the first enterprise design partnership. Use a platform commitment for fixed protection costs, but avoid letting seats become the value anchor for autonomous work.
Create a joint product, security, finance, and customer-success review for every major agent launch. Require the group to approve the data path, resolution definition, gross-margin model, and customer evidence package before sales scales the offer.
Footnotes
- Monetizing Agentic AI: https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- OpenAI, “Enterprise Privacy,” updated January 8, 2026: https://openai.com/enterprise-privacy/
- Microsoft, “Data, Privacy, and Security for Azure Direct Models in Microsoft Foundry,” accessed September 3, 2026: https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy
- Amazon Web Services, “Encryption of Custom Models - Amazon Bedrock,” accessed September 3, 2026: https://docs.aws.amazon.com/bedrock/latest/userguide/encryption-custom-job.html
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, July 26, 2024: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- Carlini et al., “Extracting Training Data from Large Language Models,” 30th USENIX Security Symposium, August 2021: https://www.usenix.org/system/files/sec21-carlini-extracting.pdf
- Intercom, “Fin AI Agent Outcomes,” July 30, 2026: https://www.intercom.com/help/en/articles/8205718-fin-ai-agent-outcomes
- Sierra, “Outcome-Based Pricing for AI Agents,” December 10, 2024: https://sierra.ai/uk/blog/outcome-based-pricing-for-ai-agents
- Salesforce, “Agentforce Pricing,” accessed September 3, 2026: https://www.salesforce.com/agentforce/pricing/
- GitHub, “About Billing for GitHub Copilot in Organizations and Enterprises,” accessed September 3, 2026: https://docs.github.com/en/copilot/concepts/billing/organizations-and-enterprises
- Cursor, “Pricing and Plans,” accessed September 3, 2026: https://cursor.com/help/account-and-billing/pricing
- Cognition, “Devin Self-Serve Plans,” accessed September 3, 2026: https://docs.devin.ai/admin/billing/self-serve
- Zendesk, “About Automated Resolution Tiers,” updated August 24, 2026: https://support.zendesk.com/hc/en-us/articles/9570369117338-About-automated-resolution-tiers