Setting allow.everyone.if.no.acl.found to true makes any Kafka resource with no ACLs open to every principal. The Kafka documentation says to keep the default of false in production unless every sensitive resource, including ones created later, always gets explicit ACLs. For most teams that means leaving it off.
What the setting actually changes
With the default, a resource that has no ACLs is restricted, and only super users can reach it. That is a safe failure mode: forget an ACL and the service breaks loudly.
With the flag set to true, a resource with no ACLs is accessible to everyone. If the resource has at least one ACL, the normal rules apply and the flag does nothing. The documentation is explicit that the flag does not weaken checks on resources that already have ACLs.
Why new topics are the trap
The risk is not the topics you secured last quarter. It is the topic someone creates next week through an auto-create path or a quick admin command. Until an ACL lands on it, that topic is readable and writable by any authenticated principal. The same applies to consumer groups and other resource types.
If your pipeline creates topics dynamically, the window between creation and ACL is where data leaks or gets poisoned.
Where it is reasonable
The documentation names three cases: development, tests, and a phased rollout while you add ACLs. The rollout case is real. Turning on authorization in a cluster that has run open for years will break clients you forgot about. Flipping the flag to true while you add ACLs topic by topic lets you move without an outage.
If you do this, treat it as a dated project. Write down who will turn it off and when.
How to check your own cluster
- Read the broker configuration for the setting. Check every broker and controller, since a mixed configuration is possible.
- List topics and compare them to the topics that have ACLs. Anything without an ACL is open if the flag is true.
- Check that your topic creation path either creates ACLs in the same step or runs under a principal that cannot create topics at all.
- Re-check after upgrades and config management changes.
What to do instead of leaving it on
Create ACLs as part of the same change that creates the topic, using prefixed patterns for families of topics. That way new topics inherit access rules from their names. The related guide on least-privilege Kafka ACLs shows the commands.
Authentication matters too. A flag that opens unprotected resources to everyone still only helps principals who can connect, so make sure unauthenticated listeners are not exposed.
Safeguard's asset discovery and policies can help you keep track of which services and brokers exist in your estate, so a forgotten development cluster does not keep running open. There is a free scan at gold.safeguard.sh/scan for your dependencies.
Quick check
Does the flag override an ACL that denies someone?
No. The documentation says that if a resource has one or more ACLs, those rules are enforced as usual regardless of the setting.
Who can access a topic with no ACLs when the flag is false?
Only super users, per the Kafka documentation.
Sources
Last reviewed: 19 October 2026.
