Make recipient routing auditable

Verifiedon 2026-07-302026.7.1

Correct content to the wrong person is still a failure

Routing is where identity, data classification, action, and destination become a real decision. A rule such as “send support messages to the team” is not auditable because it leaves “support,” “team,” and “send” undefined. A reviewer should be able to inspect one row and reproduce the same result without guessing what the author intended.

This lesson is provider-neutral by design. OpenClaw configuration and channel behavior must be checked against the current official documentation index and official release history. The course evidence boundary is OpenClaw 2026.7.1, revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4, checked 2026-07-30. No rule below grants permission to send to a real recipient.

Write the matrix from the deny row outward

Begin with the default: unrecognised source, identity, classification, action, or destination → drop and log. Then add narrow allow rows. Useful columns are:

Do not use wildcards for convenience. If you need a wildcard, define exactly which field it covers and why it is safe. “Any approved sender” can still be unsafe when a sender is approved for one channel and a different recipient. Bind source, identity, classification, action, destination, and approval as a tuple.

An approval is not a blanket permission. It should identify the exact destination, the action, the content class, the route version, the approver, and an expiry. A previously approved draft becomes a new decision if its destination, content class, or action changes. Default-deny is not pessimism; it is the only predictable outcome for values you have not reviewed.

Worked example: three cases

Case A — allowed sender, internal draft. actor-test-17 is allowlisted for synthetic-workspace/support-room. It asks for a draft classified as technical-question; destination is reviewer-test-room. The route matches, but approval is absent. Outcome: hold, create a draft record, notify the approver without copying sensitive source text.

Case B — allowed sender, unknown destination. The same actor requests delivery to team-general, a destination not in the matrix. Outcome: drop and log. Do not silently map it to the nearest known room, and do not “helpfully” send a warning to that destination.

Case C — known destination, forbidden classification. A billing draft is routed to the reviewer room, but the matrix permits only internal technical triage there. Outcome: hold and escalate to the route owner. The destination is known; the proposed action is not.

source == "synthetic-webhook"
sender == "actor-test-17"
classification in ["technical-question", "billing-question"]
destination == "reviewer-test-room"
action == "deliver"
approval.destination == destination
approval.routeVersion == "v3"
approval.expiresAt > now
# otherwise: drop or hold; never choose a fallback destination

The code is a review aid, not a drop-in OpenClaw configuration. Provider adapters expose different fields, and the exact supported keys must come from the current OpenClaw and provider documentation.

Lab: route five synthetic messages

Create a matrix with at least one default-deny row, one draft-only row, one approval-required delivery row, and one prohibited recipient class. Assign a route version and owner. Then classify these five events:

1. Recognised sender, known class, draft action, known reviewer destination, no approval.
2. Recognised display name, unallowlisted stable sender ID, known destination.
3. Recognised sender, approved class, destination not in scope, valid approval for another room.
4. Recognised sender, known destination, delivery approval expired by one minute.
5. Recognised sender, unknown classification, destination in scope.

Expected outcomes are, respectively: hold; drop; drop; hold; hold and escalate. Your own policy may use different names, but it must never convert uncertainty into delivery. For each result, record a synthetic event ID, matched rule or default-deny reason, intended action, destination class, route version, and owner.

Failure modes, rollback, and learner artifact

The most dangerous failure is a broad fallback: if a destination lookup fails, the adapter chooses a general room; if a classification is unknown, the system treats it as “normal”; if approval is missing, the draft is sent because the request “looks safe.” Remove those fallbacks. Another failure is policy drift: the route matrix says v3, while the running adapter uses v2. Stop delivery and reconcile the route version before continuing.

If a test reaches an unauthorised destination, disable the route immediately, preserve the redacted decision record, and inspect whether the mistake came from identity, classification, destination mapping, or approval scope. Do not delete the evidence. Narrow the rule and retest with synthetic events. If a real message or recipient appears in the artifact, remove it and rotate any exposed secret.

The learner artifact is a redacted routing/access-control matrix with default deny, an approval-required row, five case results, and a short note naming the change owner. Lesson 4 adds durable event identity so retries cannot bypass this matrix.

Source receipt

Read the OpenClaw documentation index and the official release history before translating this provider-neutral matrix into configuration. Reviewed version: 2026.7.1, revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4, 2026-07-30. This lesson teaches policy reasoning, not a claim that any particular provider permission or adapter is production-ready.