I get the same errors. Also tried python3.9 and it still fails.

Another option I am considering is having the certificate which is stored in this file copied into a keychain item which could be accessed with a keychain access group. Then Mac apps can access it and monitor it for changes.

I found the answer. I can use the entitlement below despite that it is named a temporary exception. This has been in place for years and appears to be allowed all this time. I can add /.ssh/ to the list under this value to access the config and keys. There are other folders I will need to access which will work this way. com.apple.security.temporary-exception.files.home-relative-path.read-write

Thanks Quinn, I appreciate you. This additional context helps. I currently don't intend to ship via Mac App Store but would like to distribute releases with an installer (.dmg or .pkg) which now appears to require notarization. I'd appreciate clarifications for the temporary exceptions for Enterprise deployments. Leveraging TestFlight so that I can get feedback and crash reports in Xcode would also be appreciated. There are actually 2 dot folders I'd need to access. One is ~/.ssh because we are using the RSA certificate auth feature in OpenSSH to connect to a system. That auth tool creates a file at ~/.ssh/ id_rsa-cert.pub which is needed to make SSH/SCP connections. Our tooling which authenticates user sessions generates this certificate file with a limited lifetime along with files in another dot folder which I would need to interact with internal services. For both I think the right architecture and security recommendation would be to store these assets in the keychain using an access group. I can make a request to do this, but it may not be a high enough priority to be considered. I've read up on XPC services, daemon processes and user agents on macOS but I did not see any details about the App Sandbox and Hardened Runtime policies. Could you also request clarification related to these use cases?