Last week brought a series of security incidents that made me think about the next chapter of PLM and how an excitement about new AI tools can potential bring risks in the existing PLM tech and architectures.
Connecting artificial intelligence to product lifecycle management (PLM) raises security questions about existing customizations, cloud services, and access to sensitive engineering data.
I watched Nate B. Jones’s video discussing vulnerabilities, compromised software releases, and the growing role of AI in both attacking and defending systems. I found it insightful because it connects familiar security problems with a change in how quickly software can be investigated.
For engineering and manufacturing companies, this deserves attention as they bring AI into existing PLM environments. An assistant can inherit access and dependencies built over many years, while making information easier to find and actions easier to execute.
We are entering this discussion with a complicated history. PLM implementations can include decades of customization, integrations maintained by different organizations, and software moved from company servers to cloud hosting. Adding AI means examining how these pieces work together.
There is also a reason to pay attention before adopting AI. Attackers can use AI to investigate an existing environment regardless of whether its owner has introduced an assistant. The security discussion has already changed on the other side of the connection.
Nate’s examples make the issue concrete. PHP published emergency fixes for vulnerabilities that, in some configurations, could allow an attack before application code runs. Security researcher Scott Helme documented eight weak eMudhra intermediate certificate keys, including one whose value was simply four. LiteLLM disclosed a compromised release of its AI integration software.
These events illustrate dependencies that can remain largely invisible during normal operation. They do not establish vulnerabilities in any particular PLM product. They do give us reasons to ask harder questions about the systems we are connecting.
Here are eight observations I would bring into that discussion.
Cloud PLM security depends on the architecture underneath
The phrase “our PLM runs in the cloud” tells me relatively little about how the application is maintained.
A customized installation running on cloud infrastructure might retain its own application version, database, and upgrade schedule. A centrally operated SaaS service can have a different maintenance model. In either case, we need to understand who updates each component and how isolation is enforced.
AWS’s shared responsibility model makes an important distinction between the infrastructure AWS operates and the responsibilities attached to the services customers use. Hosting an application on a major cloud platform leaves application responsibilities to be assigned.
For a SaaS service, I would also examine how tenant boundaries are tested and how a shared update is validated. Central operation can simplify maintenance, while making the provider’s controls important to every customer depending on that service.
For PLM buyers, the useful conversation concerns supported versions, patch delivery, integration permissions, and responsibility during an incident.
When someone says the environment is secure in the cloud, I want to know which parts of the environment they mean.
Legacy PLM customization creates a continuing security obligation
Customization has helped companies adapt PLM to their engineering processes. It also creates software that somebody must continue to understand.
Consider a hypothetical implementation with a custom release workflow and an old ERP connector. A security update becomes available, but the team needs to validate the workflow and replace a dependency before applying it. Meanwhile, production depends on the existing integration.
The organization faces real risks from both delay and disruption. That is a business decision with engineering consequences.
NIST describes patching as preventive maintenance. I think this is a useful way to evaluate PLM customization. Its cost includes keeping the resulting system maintainable over time.
Nate argues that AI reduces the time defenders can afford to spend resolving these problems. If attackers can investigate weaknesses faster, a lengthy upgrade project becomes a more consequential constraint.
How quickly can your customized environment absorb an urgent security fix?
AI can make broad permissions much more consequential
Finding information in an enterprise system often requires patience. Employees navigate folders, search different applications, and ask colleagues where something lives.
An AI assistant can remove much of that effort. This is valuable, but it should make us revisit the permissions underneath. I explored this shift in how people interact with product information in PLM UX Is Dead. Long Live PLM UX.
Imagine an engineer who can technically access documents across several customer projects. Until now, locating and combining those documents required substantial work. An assistant can potentially assemble the same information in one conversation.
The problem becomes more serious when the assistant connects through a shared integration account with broader access than the employee. OWASP identifies this use of a generic privileged identity as an excessive agency risk.
The connected systems must enforce the person’s actual authorization. Asking the model to respect confidentiality is insufficient.
Have we relied on the difficulty of finding information to compensate for permissions that were too broad?
AI introduces additional places where product data lives
A company can carefully control access to a drawing in PLM and still have unanswered questions about copies created for AI.
A document might pass through an extraction service, enter a search index, appear in a conversation, and leave content in logs. Each location needs defined access and retention rules.
Consider a supplier whose access is revoked at the end of a project. If the supplier’s documents were indexed for an assistant, what changes downstream? Are permissions checked again when someone asks a question? How are stored copies handled?
These questions extend beyond whether a model provider uses customer data for training. They concern the daily operation of the complete solution.
The engineering context adds another issue. A retained copy might represent an obsolete revision. Even an authorized answer can create trouble if users cannot establish which revision supports it.
Access control and revision context both need to survive the journey outside PLM.
The integration tool becomes part of the security architecture
The LiteLLM investigation provides a useful lesson about chains of access.
Its updated account traced the attack to a master key exposed months earlier and never revoked. An internal agent platform held a GitHub token with organization owner privileges. The attacker used that access to obtain further credentials and interfere with the release process.
This matters because a tool introduced to simplify integration becomes another system to maintain and protect.
The same questions apply to PLM adapters, AI gateways, automation services, and MCP servers. What credentials do they hold? What can those credentials reach? Who maintains the deployment?
Nate also points out the financial value of AI provider credentials. Someone who steals a usable key may consume computing resources charged to its owner.
Connecting PLM to AI adds relationships that deserve the same scrutiny as the applications at either end.
A supplier document can influence an agent
Engineering organizations routinely receive outside information, including specifications, quotations, and technical documents.
When an AI agent reads this material, there is another risk to consider. Text inside a document may attempt to influence what the agent does. This is known as indirect prompt injection, and OWASP documents the risk from external files and other content.
Imagine a supplier PDF containing instructions intended to persuade an assistant to retrieve unrelated drawings and send them elsewhere. This is a hypothetical example. Whether it could succeed depends on the agent’s tools, permissions, and other controls.
The document itself has no authority to approve that action. The system must preserve that distinction even if the model interprets the text as an instruction.
An assistant that reads supplier documents should have narrowly defined capabilities. Authorization checks and approval requirements need to be enforced outside the model.
Manufacturing risk includes incorrect changes and interrupted work
Security discussions around PLM naturally focus on intellectual property. Drawings and product specifications deserve protection.
I would also examine what an agent is permitted to change.
An unauthorized modification to a quantity, an approved supplier, or a revision status can affect downstream work. An unavailable release process can delay purchasing or production. The consequences depend on the particular implementation, but they belong in the assessment.
There is a substantial difference between an assistant explaining a change and an agent executing it. A demonstration can move between these capabilities so smoothly that the underlying authority receives too little attention.
For consequential actions, I would want to see the proposed change, its supporting evidence, and the required approval before execution. The resulting record should identify the initiating user and what actually happened.
What must remain under explicit engineering control when an agent can perform the steps?
AI readiness should include a demonstration of control
I would add several practical demonstrations to any AI evaluation.
Ask the assistant for a document the user cannot access. Revoke a permission and repeat the request. Show what happens when a supplier document contains misleading instructions. Demonstrate how an integration can be disconnected and explain which business processes would stop.
Then examine maintenance. Who can patch each component? What must be tested? Could the team determine which software actually ran during an incident and which credentials it could access?
Updating a compromised component does not, by itself, revoke stolen credentials or establish whether information was copied.
Nate’s constructive point is that AI can help defenders investigate these questions. It can assist with examining code, tracing dependencies, and reviewing configurations. Its findings still need verification, and its own investigative access needs limits. Evaluate that assistance against a known incident, checking whether it follows the evidence through connected systems and identifies what remains uncertain.
These demonstrations would tell me much more about readiness than a successful conversation with a product database.
What is my conclusion
AI gives engineering and manufacturing companies useful ways to work with product information. It also gives us a reason to revisit architectural decisions that have become familiar enough to escape examination.
Some risks may come from an unsupported component. Others may come from a new service granted excessive access. A well maintained older application and a recently launched AI product each need to be evaluated on the evidence.
For me, the most thought provoking lesson from Nate’s video is how quickly the assumptions around existing software can change. A weakness can remain unnoticed for years. Its consequences become immediate when someone discovers a practical way to exploit it.
Before adding AI to PLM, I would ask the team to explain what the agent can reach, who maintains the connected components, and how access can be withdrawn when something goes wrong.
Those answers should shape the implementation from the beginning.
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM. My work on connected product data and Product Memory shapes my perspective, and my opinion can be unintentionally biased.
