The dangerous step in connecting an AI agent to MQTT is not reading telemetry. It is turning a model decision into a command that may arrive late, run twice, target the wrong device, or exceed the authority of the person who asked for it.
MQTT can provide a clear boundary between the agent and device fleet, but broker delivery guarantees do not make an agent command safe. Safety comes from the policy, validation, approval, expiry, and device-side enforcement around the command path.
Start with command failure modes
Design controls against concrete failures rather than the abstract idea of an unreliable model:
| Failure mode | Required control |
|---|---|
| Prompt content tries to choose a topic | Typed tool; server resolves the destination |
| Agent acts on stale telemetry | State version check and command expiry |
| Retry repeats a physical action | Idempotency key and device-side deduplication |
| Low-risk authority reaches a critical actuator | Consequence class and independent approval |
| Publish succeeds but the device does nothing | Correlated result topic and explicit timeout |
| Agent or command service is compromised | Narrow identity, rate limit, and external kill switch |
Put a command gateway between the agent and MQTT
A production flow usually has five parts:
- Devices and gateways publish telemetry and state to MQTT topics.
- The broker authenticates clients and enforces publish and subscribe policy.
- An ingestion service validates payloads, enriches context, and exposes a narrow event stream to the agent.
- The agent proposes an action through a typed tool rather than publishing arbitrary MQTT messages.
- A command service checks policy, approval state, freshness, and device capability before publishing.
This separation prevents prompt content from becoming a broker credential or topic filter.
device -> MQTT broker -> validated event -> agent
agent -> typed tool -> policy and approval -> MQTT command -> device
Separate observation from control identities
Give observation and control different topics, identities, and permissions.
sites/{siteId}/devices/{deviceId}/telemetry
sites/{siteId}/devices/{deviceId}/state
sites/{siteId}/devices/{deviceId}/commands/request
sites/{siteId}/devices/{deviceId}/commands/result
The service that supplies context to the agent may subscribe to telemetry. It should not automatically inherit permission to publish commands. The command executor should have the narrowest publish scope possible and no ability to edit its own policy.
Expose typed operations, not a publish tool
Do not expose a generic tool such as mqtt_publish(topic, payload) to the model. Define operations around business intent:
{
"operation": "set_temperature_target",
"deviceId": "chiller-07",
"targetCelsius": 6,
"reason": "Reduce deviation from the approved range",
"requestId": "req_01J..."
}
The command service resolves the destination topic, validates the target range, verifies the device capability, and creates an audit record. The agent never chooses a wildcard topic or embeds a credential.
Approve commands by consequence
Not every action needs a human, but every action needs an explicit consequence class.
| Class | Example | Control |
|---|---|---|
| Observe | Read latest temperature | Automatic, read-only |
| Recommend | Suggest a maintenance window | Automatic proposal |
| Reversible control | Adjust a non-critical set point within bounds | Policy-gated |
| High consequence | Stop equipment or unlock access | Explicit approval and independent safeguards |
Physical systems must retain local safety limits. A cloud agent should never be the only protection against an unsafe actuator command.
Expire and deduplicate every command
An instruction can become dangerous when delivered after its context is stale. Include:
- a unique request ID;
- issued and expiry timestamps;
- expected device state or version;
- the initiating principal;
- the policy decision and approval record;
- an idempotency key.
MQTT 5 message expiry helps prevent late delivery, but the device should still reject expired or out-of-sequence commands.
Require evidence of device execution
A successful MQTT publish only confirms the broker accepted a message according to the chosen QoS flow. It does not prove the device performed the action.
Use a separate result topic with a correlation ID:
{
"requestId": "req_01J...",
"status": "applied",
"deviceStateVersion": 1843,
"observedAt": "2026-07-27T09:30:00Z"
}
The workflow can then distinguish accepted, delivered, applied, rejected, expired, and timed-out states.
Production controls to verify
Before connecting an agent to MQTT:
- issue unique service identities and rotate credentials;
- allow-list exact topic patterns per tool;
- validate payloads against versioned schemas;
- cap command rate and concurrency per device;
- log proposals, approvals, policy decisions, publishes, and results;
- test duplicate delivery, reconnects, stale retained state, and partial failure;
- provide a kill switch outside the agent path.
Start with read-only telemetry and offline recommendations. Add bounded command execution only after the audit trail and failure handling are observable.
Read the MQTT security guide for identity and authorization design, the MQTT 5 migration guide for session and message expiry, and MQTT vs Kafka when the agent also needs durable event replay.