How Dynamic Access Control works and should work for AI-Ready PLM

In this article, let’s explore how dynamic access control is transforming PLM security by calculating permissions at runtime based on roles, groups, projects, ownership and business context. Learn why AI Agents create new PLM security challenges and how manufacturers can govern agent identity, least-privilege access, delegated authority and autonomous actions in AI-ready PLM environments.

How Dynamic Access Control works and should work for AI-Ready PLM

Product Lifecycle Management systems contain some of the most valuable intellectual property inside a manufacturing organisation.

CAD models. Product structures. Bills of Materials. Requirements. Simulation results. Supplier information. Cost data. Manufacturing processes. Engineering changes. Future product designs.

The fundamental security question has therefore always been:

Who should be allowed to do what with which product information—and when?

Historically, organizations often approached this through relatively static permissions and role-based access.

But modern product development is becoming far more dynamic.

Engineers participate in multiple projects. Suppliers collaborate temporarily. Global teams work across organizational boundaries. Products move through different lifecycle states. And increasingly, AI assistants and autonomous agents need access to PLM information.

This requires a more sophisticated approach: Dynamic Access Control.

Managing permissions ensures that the right people have access to the right data at the right time—protecting intellectual property, enabling collaboration and keeping processes secure.

Smart access control is therefore not merely an IT security feature. It is the foundation of a successful PLM strategy.

Why Static Access Is No Longer Enough

Consider a design engineer working on Project Alpha.

The engineer may require:

• Modify access to Project Alpha designs,
• Read access to standard components,
• No access to Project Beta,
• Restricted access to cost information,
• Temporary access to supplier documentation.

Six months later, the engineer moves to another program. Should all those permissions remain? Obviously not.

The problem becomes even more complex when product lifecycle states are considered.

A designer might be allowed to modify a component while it is in Work in Progress, but once it becomes Released, modification may require an Engineering Change process.

Access therefore depends on context.

Not simply:

Who are you?

But also:

What are you trying to access?

What are you trying to do?

Which project are you working on?

What role are you performing?

Who owns the object?

What is its lifecycle state?

That is why modern PLM security increasingly needs to be calculated dynamically.

How Dynamic Access Control Works

Instead of permanently attaching every permission to every PLM object, a modern authorization engine can evaluate access when an operation is requested.

Suppose an engineer attempts to modify a CAD-related object.

The PLM system first gathers the user’s security context.

This might include:

• user identity,
• organization,
• group,
• role,
• project membership,
• ownership,
• geographic or organizational context.

The system then identifies the relevant access-control policy and rules applicable to the requested object and operation.

Conceptually, the process becomes:

User / Agent

↓

Requested Object

↓

Requested Operation

↓

Security Context

↓

Applicable Access Rules

↓

Grant/Deny Resolution

↓

Allow or Reject

The system maps the user’s context against conditions such as:

• Group membership,
• Assigned role,
• Project participation,
• Ownership,
• Object type,
• Lifecycle state,
• Other organizational rules.

Applicable grant and deny rules are resolved.

The operation is then either allowed or rejected.

The important difference is:

Security is calculated at runtime rather than simply stored as static permissions on individual objects.

This provides enormous flexibility.

A Simple Manufacturing Example

Consider a new electric motor being developed.

During early development:

Design Engineers may create and modify CAD models.

Manufacturing Engineers may review manufacturability information.

Procurement may see approved supplier information.

Finance may access cost information.

External Suppliers may access only specifically shared drawings.

Once the design is released, however, the rules change.

Design engineers may no longer directly modify the released definition.

A formal Engineering Change Request may first be required.

The product hasn’t necessarily moved somewhere else.

The user’s identity hasn’t changed. But the business context has changed, so the authorization decision changes. That is the power of dynamic access control.

Designing Access Logic at Organization Level

Before configuring PLM permissions, organizations should avoid starting with individual users.

Start with business logic.

A useful framework is: WHO + WHAT + ACTION + CONTEXT + TIME

WHO?

Identify major communities:

• Design Engineering
• Manufacturing Engineering
• Quality
• Procurement
• Service
• PLM Administration
• Suppliers
• Customers
• Partners
• AI Agents

WHAT?

Classify information:

• CAD
• BOMs
• Requirements
• Changes
• Manufacturing information
• Supplier data
• Cost information
• Compliance documents

ACTION?

Define permitted operations:

• View
• Create
• Modify
• Approve
• Release
• Download
• Export
• Delete

CONTEXT?

Consider:

• Project,
• Role,
• Ownership,
• Lifecycle state,
• Product program,
• Geography,
• Confidentiality level.

TIME?

Some access should be temporary.

Supplier access, contractor access and project-specific access should expire when the business requirement disappears.

This prevents permissions from accumulating indefinitely.

The New Complication: AI Agents

Now introduce Agentic AI.

Imagine an Engineering Change Agent tasked with analyzing the impact of replacing a component.

The agent may need to:

1. Read the component.
2. Perform where-used analysis.
3. Examine affected BOMs.
4. Retrieve historical changes.
5. inspect supplier information.
6. Generate an impact assessment.
7. Draft an Engineering Change Request.

Suddenly the question becomes:

What permissions should an AI agent have?

Giving an AI agent unrestricted PLM access simply because it needs broad context would be extremely dangerous.

An AI agent is effectively becoming another participant in the PLM security architecture.

But unlike a human user, it may perform thousands of operations rapidly.

That changes the risk profile dramatically.

Advantages of Dynamic Access for AI Agents

Context-Specific Permissions

Agents can receive access appropriate to a particular task rather than permanent broad access.

Least-Privilege Operation

A BOM-analysis agent may receive read access without modify or release privileges.

Scalable Governance

Organizations can govern many agents using centralized policies.

Temporary Authorization

An agent can receive additional access only for the duration of an approved workflow.

Better Automation

Agents can operate across engineering processes without requiring manually configured permissions for every object.

The Risks

Dynamic access also introduces significant challenges.

Policy Complexity

Too many overlapping rules can become extremely difficult to understand.

Incorrect Rule Configuration

A badly designed rule could accidentally expose sensitive product information.

Agent Speed

A human with excessive access might view several sensitive objects.

An autonomous agent could potentially access thousands before the problem is detected.

Cascading Actions

One agent may invoke another agent, API or enterprise system, creating complicated authorization chains.

Auditability

Organizations must understand not only:

Who accessed the information?

but increasingly:

Which agent accessed it, for what purpose, under whose authority, and what did it do next?

Special Care Required for AI Agents

Manufacturers should therefore avoid treating AI agents exactly like human users.

Every enterprise AI agent should have a clearly defined identity.

Do not allow multiple agents to operate through generic administrator credentials.

Second, define the agent’s purpose.

A Part Search Agent should not automatically receive Engineering Change approval rights.

Third, apply least privilege.

Give the agent only the permissions required to perform its defined task.

Fourth, separate:

Read → Recommend → Modify → Approve → Release

These represent dramatically different risk levels.

An AI agent might be allowed to read BOMs and recommend a change while a human remains responsible for approval.

This reflects an important Industry 5.0 principle:

Autonomy should increase gradually with trust, evidence and governance.

Dynamic Access Control Checklist for AI-Ready PLM

Before implementing access-control logic, organizations should ask: