Sporadic failures with CSSMERR_CSP_OPERATION_AUTH_DENIED with RSA.Decrypt() on MacOS unless I open up permissions in KeyChain

Question

(Warning: This is a long question - mostly because the situation kept mutating it's behavior as my tests went on)

Monterey 12.6, JetBrains Rider 2022.2.2 & .Net Core 6.0.6

I've used BouncyCastle 1.9.6 to create a Self signed certificate and I've got it stored, with a private key, in the KeyChain. While in the same process that's just created the certificate, I'm able to call the following bit of code just fine:

using var rsa = certificate.GetRSAPrivateKey();
var keyBits = rsa!.Decrypt(key, RSAEncryptionPadding.OaepSHA512);

However if I exit out of the program and then rerun it, I'm getting the following exception with the RSA.Decrypt

Interop+AppleCrypto+AppleCFErrorCryptographicException: The operation couldn’t be completed. (OSStatus error -25293 - CSSM Exception: -2147416032 CSSMERR_CSP_OPERATION_AUTH_DENIED)
   at Interop.AppleCrypto.ExecuteTransform(ReadOnlySpan`1 source, SecKeyTransform transform)
   at Interop.AppleCrypto.RsaDecrypt(SafeSecKeyRefHandle privateKey, Byte[] data, RSAEncryptionPadding padding)
   at System.Security.Cryptography.RSAImplementation.RSASecurityTransforms.Decrypt(Byte[] data, RSAEncryptionPadding padding)
   at PureRomance.DatabaseSystems.Security.Vault.Vault.GetAes(Byte[] key, X509Certificate2 certificate)

It's the exact same binary that's being executed both times. This is the Keychain entry showing the binary name I'm using.

However on rerunning of the app I get the above exception.

To make things even odder. After the first execution, I went in and removed Vault_Tester from the ACL and re-ran. This time I was prompted by KeyChain (as I'd expected) and I dutifully entered my password to access it (Pressing the Always Allow to lock that setting in). Now - now it's happy with always using the Private Key over and over again. The Keychain ACL show's the same entry but now it's apparently 'correct'.

Just to confirm as well: if open up the permissions wide and set the "Allow all applications to access this item" option (which kinda defeats the point of using the Keychain!) this issue also goes away - but that's cause I've exposed it wide.

I ran a and this is the only difference I could find:

Before

access: 5 entries
    entry 0:
        authorizations (6): decrypt derive export_clear export_wrapped mac sign
        don't-require-password
        description: Imported Private Key
        applications (1):
            0: /Users/rambler/Files/ApplicationWorkspaces/Rider/Vault/Vault_Tester/bin/Debug/net6.0/Vault_Tester (OK)
                requirement: cdhash H"d2ef97a53482cc84ca4f8be9c189d0cd0f782a74"
    entry 1:
        authorizations (1): encrypt
        don't-require-password
        description: Imported Private Key
        applications: <null>
    entry 2:
        authorizations (1): integrity
        don't-require-password
        description: ff520e3d4a24d7510008fa20597fea853ca5ad335e21efc97b63a239ac0a722d
        applications: <null>
    entry 3:
        authorizations (1): partition_id
        don't-require-password
        description: cdhash:d2ef97a53482cc84ca4f8be9c189d0cd0f782a74
        applications: <null>
    entry 4:
        authorizations (1): change_acl
        don't-require-password
        description: Imported Private Key
        applications (0):

After

access: 5 entries
    entry 0:
        authorizations (1): encrypt
        don't-require-password
        description: Imported Private Key
        applications: <null>
    entry 1:
        authorizations (6): decrypt derive export_clear export_wrapped mac sign
        don't-require-password
        description: Imported Private Key
        applications (1):
            0: /Users/rambler/Files/ApplicationWorkspaces/Rider/Vault/Vault_Tester/bin/Debug/net6.0/Vault_Tester (OK)
                requirement: cdhash H"d2ef97a53482cc84ca4f8be9c189d0cd0f782a74"
    entry 2:
        authorizations (1): integrity
        don't-require-password
        description: ff520e3d4a24d7510008fa20597fea853ca5ad335e21efc97b63a239ac0a722d
        applications: <null>
    entry 3:
        authorizations (1): partition_id
        don't-require-password
        description: cdhash:d2ef97a53482cc84ca4f8be9c189d0cd0f782a74, cdhash:d2ef97a53482cc84ca4f8be9c189d0cd0f782a74
        applications: <null>
    entry 4:
        authorizations (1): change_acl
        don't-require-password
        description: Imported Private Key
        applications (0):

Basically, it looks like the data in entries 0 & 1 were flip-flopped, and entry 3 had the same hash values twice. Other than that, the hash is identical.

But wait...there's more...

This was constantly biting me for hours and then - it suddenly vanished. All of sudden it was working fine - exactly as I felt it should. No need to modify the ACL.

So I deleted my draft of this post, went upstairs and bemoaned "Computers".

One hour later...

Just before I was about to commit my work, I ran another test. And it failed. Not just the first time but every time until I opened up the permissions wide. And it was like that for a good 20-30 minutes. I was just about to give up...and now it's working again...

None of this makes any sense!

I'm used to there being a logical reason for this, but the code hasn't changed, the behavior of the KeyCHain access seems to be the thing with the shifting sands.

Anyone got any idea? I'm also unsure if this should exist here, or in the AskDifferent StackOverflow site...

Also, the only things involved here are my app, my MacBooks Keychain and...me. There is no other third party tool getting in the way. I looked at This and This but neither apply.