Hi folks, I would like to ask for clarification regarding Local Network Policy. I found 2 cases where I think the behaviour differs from the documentation. 1. Use case In a CI environment, we have multiple services (LaunchAgents) which require Local Network Access. We are fine by manually approving the Local Network Permission once (per service), but we also require these services to be able to self-update. Self update results in downloading the a binary with an (obviously) different UUID, which seems to result in re-triggering the Local Network Consent prompt. Strange thing: If I don't click either buttons (Allow of Reject), just restart macOS, it will result in an enabled entry in Privacy & Security > Local Network. I read a reply somewhere on this forum by an Apple engineer that the approval process is a mix of Bundle ID + UUID + other components, so I would expect a new binary with the same properties (but different UUID) to be already whitelisted. Is this behaviour intended? 2. Use Case Given the first issue, I decided to do this in the "right way". I was happy to read this sentence in the documentation: If you ship a launchd agent that’s not installed using SMAppService, make macOS aware of the responsible code by setting the AssociatedBundleIdentifiers property in your launchd property list. I have a properly setup (and code signed) Application, for which I have enabled Local Network permission in Privacy & Security. I have a standalone LaunchAgent, which runs a long running binary from a user directory. The agent is managed with launchd, and in this sense it is "independent" from the main Application Bundle. I have setup AssociatedBundleIdentifiers in the Agent plist, to associate it with the Application. The TeamIdentifier of the 2 binaries are the same. Based on the documentation, this should be enough for my agent to signal macOS that the responsible code is the Application Bundle (which is already enabled from Local Network POV). Instead, once the LaunchAgent starts, the Local Network Consent popup appears for the binary. I would expect the Application to be the responsible code, thus no more Consent popup. Is this behaviour intended? I need this service to run as user, so I cannot just circumvent the Consent popup by running as a Daemon or Root. Nor I would like to manage the Agent with ServiceManagement. What do you guys think, have I misunderstood the documentation?

Hello there, Today, after five months I have received an email from Developer Relations that "The entitlement for Endpoint Security has been assigned to your account". As you can see on the attached images, this supposed to be the Production Entitlement (I got the dev entitlement a while ago). As far as I understand, I should be able to assign the entitlement in the "Identifiers>App IDs>App>Additional Capabilities". As you can see on my second screenshot, the UI only mentions "Development Developer ID" Distribution support. Furthermore, when creating a "Developer ID" (or event Mac App Store) provision profile, I should eventually see an "Additional Entitlements" section to be able to choose the production Entitlement. I can't find the "Additional Entitlements" UI in any Cert / identifier / Profile combinations. I tried Xcode 15's Automatic code signing as well, but it doesn't seem to do the trick. It totally seem as If I have never received the production entitlement. I saw Quinn's advice in an old thread, that presumably the entitlement was misaligned to the wrong profiles(?), and in this case: "To correct this, you’ll need to get back in touch with the folks who granted you the entitlement." I am devastated as I can be, I waited for this day like it was christmas. I was pinging the "endpoint-review . at . apple.com" email address for months with no success. Then why would they answer to my n+1th email? Anybody has any advice what to do? Which other email addresses should I try to ping? I still have 2 TSIs, but read earlier that they have no use in this regard. Thank you in advance for everyone