Thank you for explaining that errSecAuthFailed alone does not identify which authorization check failed. Here is some additional evidence.
On macOS 27.0.1, the native app’s recorded failure on October 22, 2026 was:
SecKeychainSetUserInteractionAllowed(false): success.SecKeychainOpen: success.SecItemCopyMatching: -25293.- No mail-server connection was attempted.
The query is equivalent to:
[
kSecMatchSearchList: [loginKeychainReference],
kSecClass: kSecClassGenericPassword,
kSecAttrService: "<service>",
kSecAttrAccount: "<account>",
kSecReturnData: true,
kSecMatchLimit: kSecMatchLimitOne,
kSecUseAuthenticationUI: kSecUseAuthenticationUIFail
]
It does not specify kSecAttrAccessGroup, kSecAttrSynchronizable, or kSecUseDataProtectionKeychain.
On October 25, the deployed app passed strict signature verification, and its executable hash and CDHash matched the recorded build. It is ad-hoc signed with hardened runtime, has no TeamIdentifier, and signature inspection returned no entitlements dictionary.
Keychain Access shows the target item in the login keychain. “Confirm before allowing access” is selected, and the allowed-app list contains security and an app with the expected name. We have not verified the stored trusted-app code requirement against the deployed binary.
Also on October 25, a separate, manually launched Python status-only diagnostic returned success from SecKeychainGetStatus, with flags 7 (unlocked, readable, writable). This establishes only the keychain-level status in that process at that time—not the native app’s item access or the keychain state during the earlier failure. No new credential-access test has been performed.
An earlier Python credential-access test succeeded after a one-time authentication UI approval. That used a different caller and the default keychain search scope. The native app forbids interaction, so this is not a controlled comparison.
Is there a supported public diagnostic path to distinguish an item-specific trusted-application mismatch from execution-session or interaction-policy requirements, without retrieving password data, weakening or rewriting the ACL, or unlocking the keychain?
We understand that SecTrustedApplicationCopyData is not a complete stored code-requirement representation and do not want to rely on private APIs or treat current signature validity as proof of an ACL match. The existing binary has no authentication-only mode; after successful retrieval it proceeds to mail access, so simply rerunning it would not be a bounded diagnostic.
