SecurityAgent taking focus for plugin in macOS 26.1

We have a custom SecurityAgentPlugin that is triggered by multiple authorizationdb entries. Some customers report that the SecurityAgent process takes window focus even though no UI or windows are displayed.

Our plugin explicitly ignores the _securityAgent user and does not show any UI for that user. However, in macOS 26.1, it appears that the plugin still causes the SecurityAgent to take focus as soon as it is triggered.

Is this a change in macOS 26.1 or a bug? Can we do anything to prevent "focus stealing"?

Not necessarily an Apple developer, but I ran across this when searching for an annoying bug I've been having lately on my macbook. Every few minutes, SecurityAgent.bundle steals focus from whatever app I have open. It automatically returns focus a few seconds later.

The full path of the offending bundle in my case is

/System/Library/Frameworks/Security.framework/Versions/A/MachServices/SecurityAgent.bundle

Maybe this is related? I couldn't find any other info on this issue online.

First up, authorisation plug-ins are fundamentally brittle and if you’re shipping one as a product then you ought to test your product on every beta release of macOS that we seed. Not just major release seeds, but minor release seeds and even bug fix release seeds.

As to what’s going on here, it’s hard to say without more context. Is your plug-in based on SFAuthorizationPluginView? What rights are you inserting it to?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

maartenweyns: Are you running any security software? Or software that has a SecurityAgent Plugin.

Quinn: Our product contains a SecurityAgent plugin and is an essential part of our product. We do a lot of testing, but this issue seems to be hitting some customers depending on maybe their MDM setup and software installed on the Macs. Could you make help me some documentation on changes in 26.1? We do have an SFAuthorizationPluginView, but that is not even invoked for this issue

We are seeing the same issue with our product, except we can see it on Sequoia as well. We see the issue when we are inserting into rights: com.apple.ServiceManagement.daemons.modify

We are seeing the same issue with our product, except we can see it on Sequoia as well. We see the issue when we are inserting into rights: com.apple.ServiceManagement.daemons.modify

We are also adding a mechanism to com.apple.ServiceManagement.daemons.modify. I can't rule out that it also happens in Sequoia, but many of our users see the problem very often on Tahoe.

Could you make help me some documentation on changes in 26.1?

I’m not aware of any documented changes in this space. OTOH, documentation for authorisation plug-ins is almost non-existant in general )-: so that’s not surprising.

this issue seems to be hitting some customers depending on maybe their MDM setup

OK.

What right is being authorised when this happens?

Have you confirmed that the right is still set up the way you think it’s set up? If this is happening in managed environments then my experience is that such environments often have multiple security products installed. It’s easy to imagine these products fighting each other over how a specific right might be authorised.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Have you found a workaround for this?

Nope, we haven't. Our situation (simplified) looks like this:

  1. restart machine, we are using a script to tell us which application is currently active
  2. when an app opens, we are inserting into 'com.apple.ServiceManagement.daemons.modify' (the rights will be removed when the app closes)
  3. this app has the focus & remains open
  4. within 3-5 mins, the application SecurityAgent with path '/System/Library/Frameworks/Security.framework/Versions/A/MachServices/SecurityAgent.bundle' takes the focus

(I am unable to reply back to your comment OP)

What right is being authorised when this happens?

Have you confirmed that the right is still set up the way you think it’s set up? If this is happening in managed environments then my experience is that such environments often have multiple security products installed. It’s easy to imagine these products fighting each other over how a specific right might be authorised.

It's the com.apple.ServiceManagement.daemons.modify right. We see it on MDM enrolled Macs with only our product installed, but on Macs not enrolled there is no issue. Seems like the SecurityAgent is doing something in the background on MDM Macs. Triggering the plugin should be fine, but taking focus when no UI is shown seems wrong

So this is the default setup for com.apple.ServiceManagement.daemons.modify:

% security authorizationdb read com.apple.ServiceManagement.daemons.modify | plutil -p -
YES (0)
{
  "class" => "rule"
  "comment" => "Used by the ServiceManagement framework to make changes to the system launchd's set of daemons."
  "created" => …
  "k-of-n" => 1
  "modified" => …
  "rule" => [
    0 => "is-root"
    1 => "entitled-admin-or-authenticate-admin-nonshared"
  ]
  "version" => 1
}

What does it look like after your modifications?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

What does it look like after your modifications?

{
  "class" => "evaluate-mechanisms"
  "comment" => "Preferences."
  "created" => 784744897.064658
  "mechanisms" => [
    0 => "MyAuth:invoke"
  ]
  "modified" => 784745142.85089
  "shared" => false
  "tries" => 10000
  "version" => 0
}

What does it look like after your modifications?

Ours after modification is:

{
  "class" => "rule"
  "comment" => "Used by <company> to evaluate ad hoc rules."
  "created" => 780002118.985772
  "k-of-n" => 1
  "modified" => 785095658.311386
  "rule" => [
    0 => "com.<company>.AdHoc"
    1 => "com.<company>.original.com.apple.ServiceManagement.daemons.modify"
  ]
  "version" => 0
}

@ehale I'm testing on latest macOS 26.2 beta 3. I have not seen the focus issue yet. Have you tested on that?

I'm testing on latest macOS 26.2 beta 3. I have not seen the focus issue yet.

Well, that’s promising. @ehale , I’d also be interested in hearing your experience with that beta.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Turns out I was too quick. The issue still occurs on the latest beta, unfortunately.

@DTS Engineer I've discovered more information. The process /usr/libexe/mdmclient runs every so often to check if the machine is enrolled in MDM (I believe). This process seems to invoke our security agent plugin to check the right com.apple.ServiceManagement.daemons.modifywhich is the same right we are already modifying when this happens. I have tried to return early in our security agent's invoke method if it is the mdmclient process, but that didn't seem to work. I am going to see if I can return even earlier, or, ignore it altogether.

SecurityAgent taking focus for plugin in macOS 26.1
 
 
Q