Production guardrails

Updated 29 September 2026 · applies to 1.0.0 · Community and Commercial

Permissions answer "is this person allowed to do this?". Guardrails answer a different question: "should this happen here, right now, even though they are allowed?" — which is the question that matters at 3am, when the person at the keyboard has every permission and is looking at the wrong cluster.

BROKA has five, and they work at different distances from the action.

1 · The environment is read-only

The bluntest one, and the only one that cannot be argued with. An environment marked read-only refuses every write — creating a topic, purging a queue, resetting an offset, deleting keys — no matter who asks. An administrator with the full permission set is refused exactly like everyone else, because this is a property of the place, not of the person.

The refusal happens in the API. The console disables the buttons it knows will be refused and says why on hover, but that is a courtesy: a request made any other way is refused just the same, with 403 ENV_READ_ONLY.

2 · The environment is guarded, and every write has to say why

A destructive operation against a broker — every delete, plus purge, trim, reset-offsets, flush and bulk-delete — has to carry a reason in every environment. The middle policy extends that to every write, and that one requirement is the whole of what separates it from an open environment. Without its reason a write is refused with 400 REASON_REQUIRED before it runs, and the refusal is recorded as a blocked write like any other. In the environment's form the option reads Guarded — every write asks for a reason.

The console asks inside the confirmation described in 4 below: a prompt that needs a reason grows a Reason field, and Confirm stays disabled until it has something in it. A write with no confirmation of its own opens a small A reason is required window before it is sent, which can keep the reason for the next ten minutes or ten operations in that environment. The sentence travels with each request and lands on its audit entry — so the trail answers why beside who.

The Edit environment sheet for Production: name, colour, the write policy set to Guarded — every write asks for a reason, the default classification set to Internal, and the Allow insecure TLS switch left off. — The write policy applies to every connection in the environment whatever the operator's permissions; the TLS switch is the fifth guardrail, and it is off by default.

The write policy applies to every connection in the environment whatever the operator's permissions; the TLS switch is the fifth guardrail, and it is off by default.

3 · The connection is read-only

The same idea at a smaller scale. Any single connection can be frozen with its own switch, and it is refused even inside an open environment — 403 CONNECTION_READ_ONLY. Use it when one cluster is mid-incident, mid-migration, or simply not yours to touch this week.

The two switches are independent, not levels of one setting. Either is enough to stop a write, and the wider one is reported first so an operator learns the real reason rather than the nearest one.

4 · The action names what it is about to do

Destructive actions confirm, and the confirmation carries the fact you would want before saying yes, not a generic "are you sure":

Purging a RabbitMQ queue states how many ready messages will go, and that purged messages are not dead-lettered.
Deleting a Kafka topic requires you to type its name — the button stays disabled until the typed text matches exactly.
Deleting Redis keys by pattern offers a dry run first: the match count, before anything goes.
Deleting a virtual host states that it takes every queue, exchange, binding and policy inside it.
Deleting a user states that connections already authenticated keep working.

A confirmation dialog in guarded Production: Read 10 messages from orders.audit?, a sentence on what the read does to the queue, a required Reason field with a reason typed, and Cancel beside Read and requeue. — The reason is not decoration: it travels with the request and is stored on the audit entry, so the trail says why as well as who.

The reason is not decoration: it travels with the request and is stored on the audit entry, so the trail says why as well as who.

5 · The environment refuses unsafe transport

An environment decides whether connections inside it may skip TLS certificate verification. While that is off — the default — a connection that asks for it is refused at save time, with a message naming the remedy rather than the rule: upload the cluster's CA certificate, or change the environment's policy deliberately. Turning it on is itself an audited change.

What a refused action leaves behind

A blocked write is written to the audit trail as a blocked action, with the reason that blocked it, the actor, the target and the environment. This is deliberate:

A trail that only holds successes cannot answer the question an access review is actually asking.

The same applies to policy changes: switching an environment's guard policy or its TLS stance is an administrative action and is recorded with what changed.

What guardrails are not

Not a substitute for permissions. They sit on top: the role check runs first, then the guardrail, then the broker's own authorisation, which BROKA never bypasses.
Not an approval workflow. Nothing in BROKA routes a destructive action to a second person for sign-off today — and a guarded environment is not one either: it asks the person doing the work to account for it, not somebody else to agree to it.
Not enforced on the broker. A guardrail stops BROKA from issuing the write. Anyone with direct broker credentials is outside its reach — which is the argument for giving BROKA's own connection the narrowest broker-side permissions that still let it do its job.