Securing agentic AI in OT authentication and authorization for factory agents

Agentic AI is the practice of deploying autonomous software agents that consume real-time data, reason about operational conditions and take actions, sometimes without human approval for every step. In factory environments, this means agents that adjust process parameters, trigger maintenance workflows or reroute production. The security implications are immediate and serious: an agent with unconstrained access to an MQTT namespace can issue commands to actuators, PLCs and safety-critical systems.

This article provides a concrete architectural framework for authenticating, authorizing and constraining AI agents operating in OT environments using HiveMQ Broker as the policy enforcement backbone. It assumes familiarity with MQTT 5, X.509 certificate infrastructure and ISA-95/IEC 62443 security zone concepts.

Why do AI agents in factories require a different security model than traditional MQTT clients?

Traditional MQTT clients in OT, such as a temperature sensor publishing to site/area-1/line-3/temperature, are predictable. They publish to a narrow set of topics at a known frequency with a known payload schema. Their behavior is deterministic. Security policy for these clients is straightforward: authenticate the device, authorize it for specific topics and monitor for anomalies.

AI agents break every one of those assumptions. An agent might subscribe to dozens of topics across multiple ISA-95 levels, correlate data from disparate sources, and then publish a command to a topic it has never previously written to, all within a single reasoning cycle. The agent's behavior is goal-directed rather than deterministic, which means its communication patterns are inherently less predictable.

Consider a predictive maintenance agent monitoring vibration data on a CNC machining line. Under normal conditions, it subscribes to site/plant-2/area-machining/line-7/vibration/# and publishes analysis results to site/plant-2/area-machining/line-7/insights/vibration-health. Straightforward. But when the agent detects an anomaly pattern that correlates with bearing failure, it may attempt to publish a speed-reduction command to site/plant-2/area-machining/line-7/cnc-04/cmd/spindle-speed and simultaneously notify the MES system via enterprise/mes/work-orders/create. The blast radius of a misconfigured or compromised agent is dramatically larger than that of a misconfigured sensor.

HiveMQ's security model must therefore enforce not just "Can this client connect?" but "Can this agent perform this specific action, on this specific topic, at this moment, given current operational context?"

How should AI agent identity and credentials be architected?

Every agent deployed in a factory environment needs a unique, non-shared identity. This is non-negotiable. Shared service accounts, a common shortcut in early-stage deployments, make it impossible to audit which agent performed which action and impossible to revoke access to one agent without disrupting others.

Certificate-based identity with short-lived credentials

The strongest pattern for agent identity uses mutual TLS (mTLS) with X.509 certificates issued from an internal PKI or a managed certificate authority. Each agent receives a unique client certificate that encodes its identity attributes:

• Common Name (CN): A human-readable agent identifier, such as agent-pred-maint-line7-plant2

• Organization Unit (OU): The agent's functional class, such as predictive-maintenance

• Subject Alternative Names (SANs): Additional identifiers for multi-site agents

HiveMQ's TLS configuration supports mTLS natively, and the Enterprise Security Extension allows extracting certificate fields during MQTT authentication to make authorization decisions based on the agent's identity attributes.

For agents running in containerized environments (Kubernetes pods on an on-premises cluster, for instance), integrate with a secrets management platform such as HashiCorp Vault to issue short-lived certificates. A certificate lifetime of 24 hours with automated renewal eliminates the risk of long-lived credential compromise. The pattern looks like this:

1. Agent pod starts and requests a certificate from Vault using its Kubernetes service account token.

2. Vault issues a certificate with a 24-hour TTL, signed by an intermediate CA trusted by HiveMQ.

3. The agent connects to HiveMQ Broker using mTLS.

4. HiveMQ validates the certificate chain against the trusted CA and extracts identity attributes.

5. On certificate expiry, the agent re-authenticates with a fresh certificate, and HiveMQ's session management handles the reconnection cleanly via MQTT 5 session expiry intervals.

Agent registration and lifecycle

Beyond cryptographic identity, each agent should be registered in an agent catalog that tracks:

This catalog becomes the source of truth for authorization policies enforced by HiveMQ. When HiveMQ's Semantic Graph captures the relationships between agents, equipment and data flows, the catalog also provides the governance metadata that makes agent activity auditable and explainable.

How does least-privilege access work for agents that need broad data visibility?

Least-privilege access is a well-understood principle, but applying it to agentic AI surfaces a tension: agents often need broad read access to perform correlation and reasoning, while requiring tightly constrained write access to prevent unsafe actions. Treating read and write permissions identically either starves the agent of data or grants it dangerous command authority.

Asymmetric read/write authorization

The solution is asymmetric authorization: generous subscribe permissions, restrictive publish permissions. HiveMQ Broker's authorization framework, configurable via the Enterprise Security Extension or custom extensions, supports this granularity natively.

For the predictive maintenance agent example:

Subscribe permissions (broad):

Publish permissions (narrow):

Notice the explicit deny on command topics. Even if a future policy change accidentally broadens permissions, the explicit deny acts as a safety net. In HiveMQ's authorization model, explicit denies take precedence over allows.

Dynamic permission escalation

Some agents legitimately need elevated permissions under specific conditions. A quality control agent might normally only publish inspection results, but during a detected quality excursion, it needs to publish a line-stop command. Static policies cannot handle this safely.

The architectural pattern for dynamic escalation uses HiveMQ's extension framework to implement a permission broker:

1. The agent publishes a permission escalation request to a dedicated topic: governance/escalation-requests/{agent-id}

2. A governance extension (or a human operator monitoring escalation requests) validates the request against predefined escalation criteria

3. If approved, the extension dynamically updates the agent's authorization policy via HiveMQ's admin API

4. The escalated permission includes a TTL (e.g., 15 minutes) after which it automatically reverts

5. All escalation events are logged to an audit topic: governance/audit/escalations

This pattern provides the operational flexibility agents need while maintaining the audit trail and temporal constraints that OT security demands. According to the NIST Cybersecurity Framework's identity management guidelines, time-bounded privilege escalation reduces the attack surface by approximately 85% compared to persistent elevated access.

What mechanisms prevent AI agents from issuing unsafe commands in factories?

Authentication verifies identity. Authorization constrains scope. But neither mechanism validates whether a specific command is safe to execute given current operational context. An agent may be authorized to publish to a spindle speed topic, but commanding a spindle to 15,000 RPM during a tool change operation is dangerous regardless of permissions.

Command validation with HiveMQ Data Hub

HiveMQ Data Hub provides a policy engine that operates at the broker level, inspecting and validating messages before they reach subscribers. For agent-issued commands, Data Hub policies can enforce:

• Schema validation: Every command payload must conform to a JSON Schema or Protobuf definition. An agent cannot publish malformed or structurally invalid commands.

• Range validation: Numeric command values must fall within defined safe ranges. A spindle speed command must be between 0 and 12,000 RPM, a temperature setpoint between 15°C and 85°C.

• Rate limiting: No more than N commands per time window to a given actuator topic. Prevents an agent in a reasoning loop from flooding a controller with conflicting commands.

• Contextual gating: Commands can be held and validated against current operational state before forwarding. A line-stop command during an active safety procedure might be held for human approval.

A Data Hub policy for spindle speed validation might enforce that any message published to topics matching site/+/+/+/+/cmd/spindle-speed must contain a JSON payload with a target_rpm field between 0 and 12,000, a ramp_rate field between 0 and 500, and an agent_id field matching the authenticated client identity. Messages failing validation are rejected and routed to a dead-letter topic for investigation.

The command envelope pattern

For high-stakes commands, wrap every agent-issued command in a standardized envelope that includes metadata for downstream validation:

The reasoning field is critical. It provides the audit trail that IEC 62443 compliance auditors will ask for: why did the agent take this action? The confidence field enables downstream policy decisions, such as requiring human approval for any command with confidence below 0.8. The ttl_seconds field ensures stale commands are never executed.

HiveMQ Data Hub validates the envelope structure and routes commands based on their metadata. High-confidence, standard-escalation commands pass through directly. Low-confidence or elevated-escalation commands are routed to an approval queue where a human operator (or a governance agent with appropriate authority) reviews and approves or rejects.

How should AI agent activity be monitored and audited for cyber security?

Security is not a one-time configuration. Agent behavior must be continuously monitored, and all agent actions must be auditable. IEC 62443 and most manufacturing cybersecurity frameworks require demonstrable audit trails for any automated system that interacts with control systems.

Structured audit logging

Every agent interaction with HiveMQ Broker should produce an audit record:

• Connection events: Agent connected, disconnected, authentication succeeded/failed, certificate details

• Authorization events: Topic access granted, denied, escalation requested/approved/rejected

• Command events: Command published, validated, rejected, approved, executed, expired

HiveMQ's Enterprise Security Extension and extension SDK provide hooks for all of these events. Route audit records to a dedicated MQTT topic hierarchy (governance/audit/#) and bridge them to your SIEM or log aggregation platform via HiveMQ's Kafka Extension for long-term retention and analysis.

Behavioral anomaly detection

Even properly authenticated and authorized agents can behave anomalously due to model drift, corrupted input data, or adversarial manipulation. Monitoring agent behavior against established baselines catches issues that static policies miss:

• An agent that normally publishes 10 insights per hour suddenly publishing 500

• An agent requesting permission escalation more than once per shift

• An agent's command confidence scores trending downward over time

• An agent subscribing to topics outside its normal pattern

When HiveMQ's anomaly detection capabilities are applied to the agent audit stream, these behavioral deviations become detectable in real time rather than during post-incident forensics.

Conclusion

Securing agentic AI in a factory is not optional, and it cannot be added after the fact. Every agent needs a verifiable identity, asymmetric read and write permissions, command validation and a complete audit trail in place before it publishes its first message. HiveMQ Broker's extension-based authentication and authorization framework, combined with Data Hub's policy engine, gives IT and OT teams the enforcement layer to make that possible. As HiveMQ Pulse adds semantic context to that operational data, the platform becomes the foundation for trusted delegation: domain experts set the goals, agents execute within defined limits and every action stays explainable.

The next step is mapping these patterns to your own factory architecture. Schedule a consultation with a HiveMQ solutions architect to design an agent security model for your OT environment, or review HiveMQ's enterprise security documentation to start evaluating the technical details.