App Management permission cannot be given to non-bundled apps

We are using a java program as an installer for a software suite. This program is bundled inside a signed and notarized Mac app, but it uses the system installed Java (from env). For installing software, it requires the App Management permission (currently under System Settings › Privacy & Security › App Management). Since the program runs via the system provided Java executable, that one is the executable, that needs said permission.

In the past, it was possible to add java to said permissions list. With macOS 26.2 it is no longer possible. I think, this change happened with 26.2. It was definitely still working with macOS 15 (I can reproduce it there), and I am confident, that it also still worked under 26.1.

In Console.app I can see errors like this one

/AppleInternal/Library/BuildRoots/4~CCKzugBjdyGA3WHu9ip90KmiFMk4I5oJfOTbSBk/Library/Caches/com.apple.xbs/Sources/SecurityPref/Extension/Privacy/TCC+PrivacyServicesProvider.swift:227 add(record:to:) No bundle or no bundle ID found for record TCCRecord(identifier: "/opt/homebrew/Cellar/sdkman-cli/5.19.0/libexec/candidates/java/11.0.29-tem/bin/rmic", identifierType: SecurityPrivacyExtension.TCCIdentifierType.path, access: SecurityPrivacyExtension.TCCAccess.full, managed: false, allowStandardUserToSetSystemService: false, subjectIdentityBundleIdentifier: nil, indirectObjectIdentityBundleIdentifier: nil, indirectObjectIdentityFileProviderIdentifier: nil, tccAuthorization: <OS_tcc_authorization_record: 0xa97d0ba80>)

This is reproducible for various different Java installations. I can also not add Java to the other permissions that I tried.

Since Java is not installed in a bundled app but instead as a UNIX executable in a bin-folder, the error No bundle or no bundle ID found for record makes sense.

I expect this to also affect other use cases where programs are provided as UNIX executables such as Python or C-Compilers like g++.

While it is possible to bundle an entire JRE inside each app, we intentionally chose not to as this massively increases app size. If this issue is not resolved or a workaround can be found, this is the only option that remains for us. I am however worried that there are other use cases where this is not an option.