A 2026 Cloud Security Alliance research note surveying 235 large-enterprise security leaders found that 71% of their organizations have AI systems with access to core business platforms, including ERP, CRM, and financial systems. Only 16% of governors effectively govern that access. CPQ and CLM sit squarely inside that 71%.
They hold pricing rules, rate cards, discount approval matrices, and every clause in every active contract. When an LLM gets connected to that data without a security boundary around it, that exposure shows up fast.
I led the Salesforce and Vlocity CPQ and CLM transformation at T-Mobile in Bellevue, delivered through Mphasis. Before that, at Amazon, I was the technical product manager for an ML system that extracted rebate and penalty clauses across a $40 billion annual transportation contract portfolio with 95% accuracy. Both systems taught me the same lesson: the moment you connect a model to pricing or contract data, you’ve built a new attack surface, whether or not anyone called it that in the project plan.
What’s actually at risk
CPQ systems price a product for a specific customer, at a specific volume, with a specific discount authority. That pricing logic is the closest thing most revenue organizations have to a trade secret. If a competitor learns your discount thresholds or your rate card floor, they can underbid you on the next deal without knowing anything else about your business.
CLM systems carry the legal terms behind every signed and pending contract: liability caps, termination clauses, renewal terms, indemnification language, and often specific negotiated concessions. Feed that data into a general-purpose model without controls, and you’ve created a record of what your company will and won’t agree to, one that sits outside the systems built to protect it.
The 2026 State of the Internet report from Akamai found that 47.11% of enterprise AI conversations occur through personal identities rather than corporate-managed accounts and that 14.4% of corporate email AI conversations are linked to personal freemium subscriptions. That second number matters specifically for CPQ and CLM. If a rep pastes a pricing exception into a personal ChatGPT account to write a customer email, or a paralegal drops a contract clause into an unmanaged tool to reword it, that data can end up in a training pipeline the company never agreed to.
A framework that fits quote-to-cash
Three controls, in order of where they sit in the pipeline.
Secret scanning before the prompt. Before any quote, rate card, or contract clause reaches an LLM, scan it for the fields that should never leave the CPQ or CLM system: account-specific discount overrides, unredacted pricing floors, and named legal terms tied to a specific customer. Tokenize or redact those fields, run the model on the structure of the request, and rehydrate the real values only inside the system of record, not inside the model’s context window.
Role-based data boundaries, not system-wide access. Access to pricing tiers and discount authority is already role-gated in a mature CPQ deployment. An AI layer connected to that system needs the same boundary, enforced at the same granularity. A model helping a rep create a standard quote shouldn’t have the same data reach as one helping a deal desk approve an exception. Most organizations don’t carry that role logic into their AI integrations; they grant the AI layer a service account with broader access than any single human user has, because it’s faster to build that way.
Contract intelligence with an output gate. Any AI-assisted clause generation or contract review needs a check between what the model proposes and what gets written back to the CLM. That check should compare the proposed clause against the approved playbook language and flag any deviation for a human, the same way a legal redline would.
This is where the 95% accuracy figure from the Amazon clause-extraction system I worked on comes into play. Even at that accuracy, 5% of extractions were wrong, and on a $40 billion portfolio, that’s still real. We managed it by keeping a human review gate on anything that fell outside a confidence threshold.
Where this breaks down in practice
Most CPQ and CLM AI deployments I’ve seen skip the middle control. Teams scan for secrets at the data layer because security asks for it, and they build output review because legal insists on it, but the role-based boundary in the middle is treated as a configuration detail rather than a security control. It’s the one most likely to leak: a support agent’s AI assistant with the same data reach as a pricing analyst’s is a leak waiting for a normal, non-malicious prompt to trigger it.
The 50% reduction in contract creation time we achieved at T-Mobile came from automating structure, not from removing review. Templates, clause libraries, and approval routing got faster. The legal review gate on non-standard terms stayed exactly where it was. Speed and data boundaries aren’t in tension when the boundary is designed into the workflow rather than bolted on after a scare.
The takeaway
Before connecting an LLM to your CPQ or CLM system, map every field the model can read against who is already allowed to see it in your existing role structure. If the AI layer’s access is broader than any single employee’s, that’s the leak path, and it’s the first thing to fix before adding any new capability on top of it.
Sources cited:
