The environment decides what a write needs.
A connection belongs to an environment, and the environment carries a policy. The console and the server both apply it, so a write a policy refuses never reaches the broker.
Writes are refused; browsing and inspection stay open. A production cluster can be read by everyone who needs to look at it without anyone being able to change it from the console.
Production guardrails →Every write states a reason. A destructive operation asks for one in every environment, and the reason travels with the record.
One connection can be read-only on its own, whatever its environment allows — for the cluster you were asked to look at and not to touch.
See what a change will do before it does it.
The operations that move the most are the ones that show their effect first.
A preview computes the current and new offset of every partition against the cluster and writes nothing; the reset asks for a reason.
Consumer lag without guesswork →A draft rule is measured against the live clusters before it is saved: which targets it matches, what each reads now, and how many would fire.
Alert rules you can trust →The MCP server changes things only through preview, plan and apply, as its token owner, under every guard a person meets — and only when an administrator allows writes.
An AI assistant under the same rules →Every change and every refusal is on the record.
A guardrail that leaves no trace is a guardrail nobody can show worked. BROKA records what was done, by whom, where and why — and what was refused, with the policy that refused it.
Records are sealed in one chain per installation; a range can be exported and verified, and altering a stored record makes verification fail from that record on.
The audit trail →Who may write is decided per scope, so the people who operate staging are not automatically the people who may change production.
One permission model →