Know why MQTT access was
allowed or denied.

1. 1 of 6

   A sensor publishes to a topic its role does not cover

   terminal · sensor

   # authenticated as testuser, whose role is "publisher"
   mosquitto_pub -h localhost -p 8883 --cafile "$CA" \
     -u testuser -P "$USER_PW" \
     -t 'restricted/ops/config' -q 1 -m '{"setpoint":42}'

   The credentials are valid. Authentication is not the problem here — which is exactly what makes this case annoying to debug.

2. 2 of 6

   The client gets a protocol error, not an authorization error

   terminal · sensor

   Error: A network protocol error occurred when communicating with the broker.

   At QoS 1 the broker refuses to acknowledge the publish and drops the connection, so most clients surface it as a transport fault. At QoS 0 the same command exits cleanly and the message is still discarded — there is no acknowledgement to refuse with. This is the gap the recorded decision closes.

3. 3 of 6

   The broker attributed the refusal as it made it

   ./trailmq logs backend | grep ACLMon

   [ACLMon] DENY user="testuser" roles=[publisher] action=publish topic="restricted/ops/config"

   Identity, role, action and topic are on the decision itself — not reassembled afterwards from a connection log and an ACL file.

4. 4 of 6

   Activity → filter Outcome: Denied

   timestamp

   8/15/2026, 1:37:00 PM

   actor

   testuser

   client

   demo-sensor-gateway-01

   topic

   restricted/ops/config

   event

   Publish refused
   No rule brings this topic into scope for any role this identity holds.

   The reason is prose, and it names which of the two gates refused: not the role's permissions, but the absence of a topic rule bringing restricted/ops/config into scope for any role testuser holds.

5. 5 of 6

   Permitted, written down, and covered are three different answers

   Outcome Denied Was the operation permitted?

   Evidence Recorded Was it written down?

   Integrity Outside validated scope Does the validated chain cover it?

   TrailMQ labels this record Outside validated scope rather than quietly implying the chain covers it. Next to this, the Access screen resolves the effective rule for the topic, so the fix is a rule you write deliberately — not a guess.

6. 6 of 6

   And the record tells you what it is worth

   The refusal you just read sits outside the chain that TrailMQ validates. The chain covers system and action entries — sign-ins, administrative changes, policy and topic-rule changes — and it is neither externally anchored nor digitally signed, so it shows internal consistency, not third-party custody.

   Evaluation snapshot · figures from a single local run, not a product property

   verdict

   Chain intact

   covered

   system and action entries — store: audit_logs

   not in this chain

   mqtt message evidence, queue records — including this refusal

   external anchoring

   None

   digital signature

   None

   Stating the boundary is the point. Extending integrity coverage over MQTT decision records is planned for 3.2 and is not available today.

You now know who was refused, on which topic, and why — from a client error that said none of it. Every line above is reproducible locally. Run it yourself