Security settings
The Security settings page: verified destination names, the administrator lock, what it protects, and the switch that lets outboundctl change rules and settings.
The Security page protects Outbound from changes nobody meant to make: a stray click on a shared Mac, a curious child, or a script calling the command-line tool. It holds the check on destination names, the administrator lock and the switch that governs outboundctl.

Destination names
Section titled “Destination names”An app can claim any server name when it connects. The section titled “Destination Names” decides whether a rule written for a name trusts that claim.
Only match host and domain rules on verified names: “Allow rules need a recent DNS answer for the connection’s address. Block and ask rules still apply to unverified names.” With it on, a host or domain allow rule applies only when a DNS answer Outbound saw for that name returned the connection’s address. Block and ask rules still match the name the app gave, so an unverified name can’t slip past a block. The connection alert says which kind of name it is (Connection details).
It is on for a new install. After an upgrade from an earlier version it stays off, so your existing rules keep matching as before, and the page says: “Name verification stays off after an upgrade to preserve your existing rules. You can turn it on here. Names hidden by encrypted DNS may remain unverified.” Keep Current Setting dismisses that note.
The footer: “The DNS cache is kept only in filter memory. Entries are used until their TTL expires, for at most one hour, and cleared when the filter restarts. Turning verification off follows your approval-before-unblocking setting.”
Administrator lock
Section titled “Administrator lock”The section is titled “Administrator Lock”. Settings lock is the state of the lock, with one or two buttons beside it.
- Locked: Unlock…. It is disabled while an unlock is already running, and the button then reads “Unlocking…”. The prompt is the macOS administrator dialog, headed “Unlock Outbound settings to change network protection.” If the lock is turned on again while that prompt is open, unlocking stops and the page reports “Settings were locked while authentication was in progress.” A second attempt while one is already running reports “Administrator authentication is already in progress.” A failed attempt reports “Administrator authentication failed (status). Settings remain locked.”
- Unlocked, with the saved lock still on: Turn Off Lock (removes the lock) and Lock Now (locks again immediately).
- Lock off: Turn On Lock.
Unlocking lasts for this session. The saved lock stays on, so Outbound is locked again the next time it starts, and after you quit it or choose Lock Now.
The footer under the section reads: “When locked, the protected areas need an administrator’s name and password. Unlocking lasts until Outbound quits or you lock it again. Use it on a shared Mac or a child’s account.”
Three switches choose what the lock protects. All three are on by default. They are disabled while this session is locked, so after Unlock… you can change them until you choose Lock Now or quit:
- Protect rule editing: rules cannot be created, changed or removed while locked. The Rules window becomes read-only, and alerts offer “Once” only, so an answer can never quietly write a rule. See Rules.
- Protect profile switching: the active profile cannot be changed while locked. See Profiles.
- Protect these settings: while this session is locked, General, Appearance, Menu Bar, Alerts, Notifications, Updates, Advanced, Trusted and DNS are disabled. Security stays usable, because it holds Unlock…. Permissions stays usable, because those are macOS’s own settings and fixing one never loosens a rule. Outbound’s Connections, License, Intelligence and Labs stay usable too. Monitor, Blocklists, Telemetry and Profiles stay open so you can search them; the controls on those pages that save a change are off.
Alert input
Section titled “Alert input”The section is titled “Alert Input”. Allow scripted control of alerts decides whether an alert accepts clicks and key presses that other software posts, rather than ones you make. The text under it: “Off by default. An administrator must authorize changes. Accessibility actions remain available.” Turning it on or off asks for an administrator’s name and password, so a script can’t change it for itself. From Terminal, the setting is outboundctl prefs key allow-scripted-alerts.
Command line
Section titled “Command line”The section is titled “Command Line”. outboundctl changes is a picker with three options. The page explains: “Loosening protection and AI changes always ask; Off makes the command line read-only.” It is disabled while this session is locked, and when your organisation manages it.
- Allow tightening: a change that only tightens protection, such as a new block rule, is made straight away. A change that loosens protection asks for your approval in Outbound.
- Ask every time (the default): every change outboundctl requests waits for your approval in Outbound. Pass
--no-waitto return while it waits, then check it withoutboundctl requests status <id>or withdraw it withoutboundctl requests cancel <id>. - Off: outboundctl is read-only. Status, history and explanations still work. A command that would change something stops with exit status 77, even when you run it as root, and prints: “outboundctl changes are disabled in Outbound Settings. Change Command Line access in the app.”
The lock is a second refusal, also status 77, also for root. A command that touches a protected area while Outbound is locked prints: “Settings are locked. Unlock them with an administrator account to make this change.” outboundctl has no setting that turns the lock off, and no setting that changes outboundctl changes. Those are changed on this page.
A prefs set or backup restore that would let traffic through is refused even for root. The tool exits with status 77 and prints: “This change would loosen protection. Approve it in the Outbound app.” (for a restore, “This restore would loosen protection. Approve it in the Outbound app.”).
An organization can forbid rule editing on its own. That refusal is also status 77, and root can override it: “changes are not allowed: your organization has turned off editing of rules (UsersMayEditRules). Run as root to override.” Root still cannot get past outboundctl changes or the settings lock. Managed Macs are covered in Locking settings and Managed preferences.