🛡️ Governing RabbitMQ With Policies and Operator Policies Using AI

The bug that taught me how RabbitMQ policies really work was a queue that mysteriously stopped honoring its TTL. The TTL policy was right there in list_policies. What I’d missed is that I’d added a second, higher-priority policy that matched the same queue — and policies don’t merge. Exactly one applies per queue, the highest-priority one, and everything else is silently ignored. My new policy had quietly switched off the old one. That single fact about policies — that they replace rather than combine — is the thing most engineers get wrong, and it’s the thing AI is most useful for talking through if you make it.

Policies are how you govern a shared broker, and on a cluster with many teams the guardrails compound: max length here, a TTL there, a queue-type mandate from the platform team. Reasoning about how those interact is exactly the kind of multi-constraint problem AI handles well — provided you anchor it on the no-merge rule and verify the effective policy per queue rather than trusting the policy list.

Make the AI state the no-merge rule out loud

Before designing anything, get the model to confirm the mental model, because if it thinks policies stack, every recommendation that follows is wrong.

I have a shared RabbitMQ cluster. The platform team wants to enforce a max queue length of 1 million on all team queues, but some teams already have their own TTL and max-length policies. If I add a platform-wide policy, how does it interact with existing per-team policies? Walk me through how RabbitMQ chooses which policy applies, and how I avoid silently disabling a team’s policy.

The answer must say that only the highest-priority matching policy applies and the rest are ignored — no merging. If the model implies the limits combine, stop and correct it, because that misconception will produce a “guardrail” that disables the very policies teams depend on.

Policy vs operator policy: pick per guardrail

A normal policy can be overridden by application-declared x- arguments and by higher-priority policies. An operator policy sets a hard ceiling apps cannot exceed — the broker takes the more conservative of the operator policy and the app’s own setting. That distinction decides whether your limit is a default or a wall.

# A normal policy: a default teams can shape around
rabbitmqctl set_policy team-ttl "^team-.*" \
  '{"message-ttl": 3600000}' --priority 1 --apply-to queues

# An operator policy: a hard ceiling apps cannot exceed
rabbitmqctl set_operator_policy max-length-ceiling "^team-.*" \
  '{"max-length": 1000000}' --apply-to queues

Use a normal policy when you’re setting a sensible default teams may legitimately override; use an operator policy when the limit must hold no matter what an app declares. Getting this backwards means either teams route around a limit you needed enforced, or you clamp something teams genuinely need.

Scope the pattern and verify the effective policy

The pattern regex decides blast radius, and a sloppy one catches system queues. Scope it tightly, and always verify what actually applies per queue rather than trusting the policy list.

rabbitmqctl list_policies
rabbitmqctl list_operator_policies

# The one that matters: what policy actually applies to THIS queue
rabbitmqctl list_queues name effective_policy_definition --vhost /

effective_policy_definition is the ground truth. After any policy change, diff it before and after on a sample of affected queues. That’s how you catch the case where your new higher-priority policy shadowed an existing one — the symptom my mysterious TTL bug would have shown immediately if I’d looked there first.

Where AI oversteps on policies

The classic overreach is the merge assumption. Even models that know the rule abstractly will sometimes write recommendations as if a max-length policy and a TTL policy on the same queue both apply — which only happens if they’re the same policy definition, not two competing ones. I keep one verification question handy: “If queue X matches two policies, one with TTL and one with max-length, what does X actually get?” The correct answer is: only the higher-priority one’s full definition; the other is ignored.

The second gap is priority. AI often omits priorities entirely, leaving everything at the default and making the winner non-deterministic between equally-prioritized matches. Make it assign explicit priorities and explain the ordering, so the policy that wins is the one you chose.

My governance loop

I make the AI confirm the no-merge rule, then design the policy/operator-policy split per guardrail with explicit priorities and a tightly scoped pattern. I apply each policy to a narrow test pattern on staging first, check effective_policy_definition on the affected queues before and after, and only widen the pattern once nothing got silently shadowed. For operator policies I also watch for unexpected message loss, since a hard ceiling can clip something teams expected to keep. The AI reasons through the interactions; the effective-policy diff is what proves no existing guardrail got switched off.

The TTL and max-length guardrails here connect directly to the message TTL and expiration strategy guide, and the broader RabbitMQ category covers the queue-type mandates operator policies often enforce. The governance prompts I run this with live with my other prompts.