Beyond PLM examines security risks between legacy PLM and AI

AI-generated summary

Connecting AI to product lifecycle management can make engineering information easier to find and workflows easier to execute, but it also exposes security assumptions embedded in legacy software, customizations and integrations. Beyond PLM author Oleg argues that AI adoption should begin with understanding what an assistant can access, who maintains each connected component and how access can be withdrawn. The concern extends to companies that have not deployed AI: attackers can use it to investigate existing systems more quickly. Drawing on Nate B. Jones’s security analysis, the article calls for evidence-based assessment rather than assuming that either cloud hosting or newer software guarantees security. Several incidents illustrate the dependency risks. PHP issued emergency fixes for vulnerabilities that, in some configurations, could permit an attack before application code executes. Researcher Scott Helme documented eight weak eMudhra intermediate certificate keys, including one with a value of four. AI integration software provider LiteLLM disclosed a compromised release. These examples do not establish vulnerabilities in any particular PLM product, the author stresses, but demonstrate why underlying components and chains of access deserve scrutiny. Cloud PLM security depends on architecture and operational responsibilities. A customized installation hosted on cloud infrastructure may retain its own versions, database and upgrade schedule, whereas centrally operated SaaS can simplify maintenance while making tenant isolation and shared-update validation especially important. AWS’s shared responsibility model illustrates that infrastructure hosting does not eliminate application-level obligations. Legacy customization adds continuing maintenance demands: in a hypothetical implementation, a custom release workflow and old ERP connector delay an urgent patch while teams validate compatibility and replace a dependency. The author frames this as a trade-off between disruption and exposure, citing NIST’s treatment of patching as preventive maintenance. Jones argues that faster AI-assisted investigation by attackers could make lengthy upgrade cycles more consequential. AI also changes the practical significance of permissions. An engineer who already has overly broad access across customer projects might previously have struggled to locate and combine documents; an assistant could assemble them in one conversation. Shared integration accounts with privileges exceeding the employee’s authorization compound the risk, which OWASP identifies as excessive agency. Authorization must therefore be enforced by connected systems, not merely requested through model instructions. Data governance must also follow drawings and documents into extraction services, search indexes, conversations and logs. Revoked supplier access must propagate downstream, and retained content must preserve revision context so that an otherwise authorized answer does not rely on obsolete engineering information. Integration tools become security-critical systems themselves. LiteLLM’s updated investigation traced its attack to a master key exposed months earlier and never revoked. An internal agent platform held an organization-owner GitHub token, enabling access to further credentials and interference with releases. PLM adapters, AI gateways, automation services and MCP servers warrant similar examination of credentials, reach and maintenance ownership. Stolen AI provider keys can also generate computing charges. Separately, external documents introduce indirect prompt-injection risks: a hypothetical supplier PDF might try to persuade an agent to retrieve unrelated drawings and transmit them elsewhere. Success would depend on available tools and controls, but external text must never substitute for authorization; capabilities and approval requirements should be constrained outside the model. Manufacturing consequences extend beyond intellectual-property theft. Unauthorized changes to quantities, approved suppliers or revision status can affect downstream operations, while an unavailable release process can delay purchasing or production. The article distinguishes assistants that explain changes from agents empowered to execute them. For consequential actions, the author advocates visible proposals, supporting evidence, required approvals and records identifying the initiating user and actual outcome. AI readiness should therefore be demonstrated through denied-access tests, permission revocation, misleading supplier documents, integration disconnection and incident reconstruction. Updating compromised software alone neither revokes stolen credentials nor establishes whether data was copied. AI can help defenders examine code, dependencies and configurations, but its findings require verification and its investigative access needs limits. The conclusion favors evaluating both older applications and new AI products on evidence and designing controls from the outset. The author discloses that his role as OpenBOM co-founder and CEO, and work on connected product data and Product Memory, shape his perspective.