HiveMQ published a piece at the end of July on securing agentic AI in OT environments, by Kudzai Manditereza, and it puts a sentence on the table that deserves to be read slowly: an agent with unconstrained access to an MQTT namespace can issue commands to actuators, PLCs, and safety-critical systems. The post argues that securing agents is not a bolt-on concern but an architectural requirement enforced at the broker level.
I read it from two seats. I spent years running a multi-tenant IoT platform with 5,000+ devices publishing 2M+ MQTT events a day, where the ACL model was the difference between a fleet and a free-for-all; I wrote up that experience in MQTT in Production: Topic Patterns and ACLs. And these days I run agent-facing tool servers in my own publishing pipeline. From both seats my reaction is the same: HiveMQ is right, and about half of what they propose is something disciplined fleets already do. The other half is genuinely new, and worth being precise about.
An agent is a client with intent#
A sensor is boring in the best way. It publishes the same topics at the same cadence for years, and its worst failure modes are silence and noise. An agent is a different animal: it pursues goals, its communication pattern changes as its reasoning changes, and if it is compromised or simply wrong, it does not just corrupt a data stream, it acts. That asymmetry is the whole story:
| Classic device fleet | Agent on the same broker | |
|---|---|---|
| Identity | Per-device credentials issued at provisioning | Per-agent identity with short-lived certificates (HiveMQ suggests 24-hour TTLs via a secrets manager) |
| Behavior | Fixed publish/subscribe pattern, defined by firmware | Goal-directed and changing; the pattern follows the reasoning |
| Authorization | Static least privilege, decided once at provisioning | Contextual: this action, on this topic, at this moment, under current operational conditions |
| Failure mode | Silent device, chatty device, garbage data | Confident wrong commands issued at machine speed |
| Governance | Change requests through humans, on human timescales | Runtime permission escalation with approval chains and automatic expiry |
What fleet ACLs already solve#
The foundation HiveMQ describes is exactly the discipline a good fleet already runs on. The topic tree is an API and the ACL is its type system: every client gets a unique identity, permissions are written against topic placeholders instead of individual clients, everything is denied by default, and read and write are never symmetric. On my fleet, a device could publish only under its own id and subscribe only to its own command channel; nothing could publish into another tenant’s namespace, ever. An agent inherits all of this machinery for free, and the HiveMQ example permission set (generous subscribe on telemetry, narrow publish on its own insight topics, explicit deny on every command topic) is a placeholder ACL wearing a new name.
What genuinely changes#
Static least privilege assumes the client’s legitimate behavior is known in advance. For firmware that is true; for a goal-directed agent it is not, and this is where the HiveMQ piece earns its title. Three mechanisms are actually new relative to fleet practice. First, time-bounded escalation: their quality-control agent normally publishes inspection results only, but can request a temporary right to publish line-stop commands during a quality excursion; the request is routed through an approval chain and the permission automatically reverts after fifteen minutes. Second, payload-aware policy at the broker: schema validation, range checks, and rate limits on what the agent publishes, not just where. Third, identity lifetime as a control: certificates that expire in hours, so a leaked credential is a short-lived problem.
The same shape on the MCP side#
What convinces me this pattern is right is that I keep meeting it outside MQTT. The tool servers I run for this site follow the same asymmetry without my having planned it that way: read tools are open-handed, while every write capability sits behind a guard, and the publishing tool is backed by a ledger that makes posting an article twice impossible no matter which client asks. The industry is converging here too; the same week I am writing this, Cloudflare shipped fine-grained write controls for MCP servers. It is one idea in different clothes, and it echoes something I wrote about the MCP spec going stateless: in agent systems, a capability has to argue its case. State did, and now permissions do.
How I would wire it today#
- Give every agent its own identity with short-lived credentials; never a shared account.
- Start from the fleet baseline: deny by default, placeholder ACLs, subscribe wide and publish narrow, explicit denies on command topics.
- Make escalation a first-class object: requested, approved, time-bounded, logged, and auto-reverting.
- Validate payloads at the broker (schema, ranges, rates), because an agent’s mistakes arrive well-formed and fast.
- Audit agent traffic separately from device traffic; the questions you will ask about it are different.
Give an agent the permissions you would give a junior operator on day one: enough to observe everything, enough to act on almost nothing, and a clear path to ask for more.