AI agents are evolving from digital assistants into operational interfaces for industrial systems. With the Model Context Protocol (MCP), they can access device information, data platforms and approved functions in a standardized way.
But as AI moves closer to industrial operations, a fundamental question arises: If you cannot trust the device, how can you trust the data an AI agent receives from it, or the actions it performs?
This is where trusted device identities become essential. Combining the openness of PLCnext Technology with KEYNOA, the identity and trust platform from DEVITY, creates a foundation for connecting device identities, user authorization and controlled AI interactions in a verifiable chain of trust.
From AI assistance to an operational interface
Generative AI has quickly evolved beyond text and information processing. AI agents can combine information from different sources, identify relationships and select suitable functions based on a user’s request. In industrial automation, this could significantly simplify the way users interact with devices and systems. Instead of navigating multiple interfaces and data sources, a user can describe a task in natural language. An AI agent could then evaluate the status of a device fleet, investigate an anomaly or prepare an approved configuration change. This changes the role of AI. Rather than simply providing an answer, the AI agent becomes an interface between the user, industrial applications and connected devices. That can make diagnostic and service processes faster, simplify access to information and automate repetitive tasks. But as soon as an AI agent accesses production-related systems or prepares changes, additional questions arise:
Which device is the agent communicating with? On whose behalf is it acting? And which operations is it actually allowed to perform?
MCP connects AI and industrial systems
The Model Context Protocol (MCP) provides an important technical foundation for this interaction. MCP is an open standard that enables AI applications to access information, resources and functions provided by external systems. For example, an MCP server could provide an AI agent with the current status of a controller, diagnostic information, certificate data or an approved configuration function. Instead of having to understand every underlying technical interface individually, the agent receives a structured description of the available resources and can integrate them into a conversational workflow. However, MCP connectivity alone does not establish trust. Being able to reach an MCP server does not prove that the endpoint is actually the expected device. Nor does it automatically determine whether a user is authorized to execute every available function or whether an action can later be reconstructed.
For industrial use, several layers therefore have to come together: user identity, AI agent context, device identity, authorization and traceability.
Trusted interactions start with trusted device identities
For human users, identity is an established part of accessing applications. Companies use technologies such as single sign-on, multi-factor authentication and role-based authorization. Connected devices need a comparable foundation. Unique digital device identities make it possible to reliably identify devices and establish secure, encrypted connections. Certificate-based authentication can provide the technical foundation for establishing trust between devices and connected systems. But providing a device with an identity is only one part of the process. The identity also needs to be associated with the correct owner and operating environment. This relationship begins during device onboarding. The system needs to determine which customer or tenant a device belongs to, which configuration it should receive, and which target systems it may communicate with. If this assignment is incorrect, even an encrypted connection could lead to the wrong customer or system context.
Secure onboarding therefore establishes the trust anchor for everything that follows.
Trust also has to be maintained throughout the entire device lifecycle. Certificates expire and need to be renewed. Device identities may need to be revoked after a potential compromise, when a device changes ownership or when it reaches the end of its lifecycle. Managing these processes manually across a growing device fleet is difficult to scale reliably. This is why automated identity and certificate lifecycle management becomes increasingly important.
From connected automation to trusted automation
PLCnext Technology provides an open industrial automation platform with device-level capabilities and an app ecosystem. This openness makes it possible to integrate additional applications and services into an automation environment. An MCP-enabled application running on or in connection with a PLCnext Control could therefore make selected device information and approved functions available to an AI agent.
This openness can be combined with KEYNOA, DEVITY’s identity and trust platform for connected devices. KEYNOA creates a trusted link between a device, its owner and its designated operating environment and orchestrates identity-related information, certificates, policies and configurations throughout the device lifecycle. At the device level, the KEYNOA Engine provides the functionality to establish secure, encrypted connections. Combined with the central orchestration platform, this allows device identities, certificates and configurations to be managed throughout the lifecycle of connected devices.
The approach brings together several essential tasks:
- securely onboard a device and assign it to the correct context,
- provide and manage a unique digital device identity,
- establish secure, encrypted connections,
- automate certificate management,
- provision configurations according to defined policies, and
- securely revoke device identities when required.
Trusted identities can support mutual authentication, encrypted communication, verified updates and auditable interactions. This establishes a reusable trust layer for connections to authorized OT, cloud, data and AI services.
Importantly, KEYNOA does not replace the existing security functions of PLCnext Technology. Instead, it complements them with cross-device management of identity, ownership, certificates and lifecycle processes.
From a user request to a controlled action
When these components are combined, an AI interaction with an industrial device can follow a clear principle:
Verify → Authorize → Execute → Audit
First, the integrated solution verifies who is making the request and which device should be addressed. The user authenticates through the existing enterprise identity infrastructure, while the AI agent receives only the context required for the current session. At the same time, the target device can be identified through its unique digital identity and certificate-based authentication.
Next, the system determines whether the requested function is permitted in the current context. Read access can be treated differently from actions that change a device or its configuration. A useful principle here is least privilege. The AI agent can initially collect and evaluate information, while configuration changes require additional checks. Before a higher-impact action is executed, the system can show the planned changes, including the affected devices, parameters and expected impact. Critical operations or changes affecting several devices can require explicit human approval.
After an operation was executed, an audit record documents who initiated the request, which agent and device were involved, what operation was used and what the outcome was. The result is a controlled workflow in which access to an industrial device does not automatically mean permission to act on it.
What could this look like in practice?
Imagine a service technician who wants to identify controllers on a production line that are not yet sending security logs to the Security Operations Center. Instead of checking every controller manually, the technician asks an AI agent:
“Which controllers on line 3 are not yet sending security logs to the Security Operations Center?”
The agent accesses the current logging status of the PLCnext Technology devices through an approved MCP resource. The user and authorization context comes from the existing enterprise identity infrastructure. At device level, unique digital identities and certificates help ensure that the addressed controllers can be reliably identified and assigned to the correct operating context. The result is therefore more than a list of technically reachable endpoints. The returned information can be associated with identified devices and a defined operator context. If required, an integrated AIoT data platform such as Cumulocity could provide additional historical measurements, alarms, events or device inventory information. The AI agent could then combine the current controller status with historical or fleet-wide context. Suppose the agent identifies three controllers without the required logging configuration. Instead of directly changing the controllers, the AI agent could first propose activating the approved configuration on these devices. The technician would see which devices are affected and which modifications are planned. Only after the user authorization, device identities, applicable policy and target scope have been checked, and the technician has explicitly confirmed the action, would the configuration be executed. An audit record could then document the user, agent, function, affected devices, policy and result.
This makes the distinction between AI-supported analysis and AI-supported action transparent.
What does this mean for operators and the PLCnext Ecosystem?
For operators, the immediate benefit is a simpler and more repeatable workflow. Instead of checking devices individually and manually gathering information from several systems, an AI agent can consolidate current device data, identify deviations and prepare an appropriate action. Device onboarding becomes more standardized. Digital identities, certificate profiles, target platforms and configurations can be provisioned according to defined rules. Automated onboarding reduces the manual effort required to connect and configure devices, as well as the risk of human error.
During operation, automatic certificate management helps maintain trusted connections without handling certificate processes individually for every device. When devices are replaced, compromised, transferred or decommissioned, their digital identities can also be securely revoked as part of the lifecycle process. A structured audit trail can additionally support troubleshooting, incident response and compliance. Instead of reconstructing an incident from disconnected systems, organizations can trace which user, agent and device endpoint were involved in a particular action.
For the broader PLCnext Ecosystem, the approach creates a reusable foundation. New AI, cloud, service or monitoring applications do not have to solve device identity and certificate lifecycle management from scratch for every project. Instead, they can build on an established trust layer. This extends an idea that is already central to the collaboration between DEVITY and PLCnext Technology: turning connected automation into trusted automation and enabling trusted access to industrial data and AI services.
Start small: A step-by-step approach to trusted AI
Trusted AI automation does not have to start with autonomous actions. A gradual approach makes it possible to explore the benefits while keeping the level of automation controlled.
1. Understand
A first demonstrator could keep the AI agent entirely read-only. The agent could query and summarize device, certificate, logging and communication status without being able to modify the controller. This alone could demonstrate how users gain an overview of multiple controllers faster while linking the information to identifiable devices.
2. Prepare
In a second step, the AI agent could prepare an action. For example, it could identify a missing configuration, determine the affected devices and show the parameters that would be changed, without actually executing the modification. The user remains in control and can review the proposed action.
3. Act
Only in a third step would selected actions be executed after authorization checks and explicit human approval. This creates a gradual path from AI-supported information retrieval to controlled AI-supported automation.
The principle is simple: Understand first. Verify next. Approve. Then act.
Building a verifiable chain of trust for industrial AI
MCP provides a standardized way to connect AI agents with industrial devices, applications and data platforms. PLCnext Technology provides the open automation environment and access to device-level information and functions. KEYNOA complements this environment with an identity and trust layer for connected devices, helping to manage the relationship between devices, their owners and their operating environments throughout the device lifecycle.
Together, these technologies can provide the foundation for an AI-enabled industrial workflow that does more than simply connect systems. The crucial point is not whether an AI agent can reach a controller or call a function. What matters is what happens between the request and the action: Can the correct device be identified? Is the user authorized? Is the requested action permitted? And can the process be traced afterwards?
For industrial AI, trust therefore needs to extend across the complete interaction, from the person making the request to the AI agent, the application and ultimately the physical device. The question is no longer just whether an AI agent can act. The real question is whether every action can be linked to a trusted device identity, an authorized user and a traceable process.
More information about the collaboration between DEVITY and PLCnext Technology is available in the PLCnext Community partner profile.
