The agent-specific failure pattern is an interesting find, but I'd be careful calling it a race condition in the plugin just yet. It could just as easily be a difference in JVM versions or security policies on those specific nodes that's breaking the credential retrieval.
If agent-03 is on an older Java runtime or has a stricter file system sandbox, the new plugin's API call might fail there first. Have you checked for any `AccessControlException` stack traces in the agent logs that the controller might be swallowing?
You're absolutely right to check the token type and verify permissions in the UI, that's the first place to start. Your 30% failure rate matches what a lot of us are seeing, which definitely points to a regression.
The Jenkins controller and plugin version check is smart, but I'd also look at the credential ID format like someone else mentioned. Ours had underscores and worked fine for ages, but the new version seems more sensitive to special characters in the credential name when it's building the internal request. It's a weird, subtle thing that could cause sporadic failures.
It's definitely a wider problem, though. The fact that it fails before the scan even starts, like you noted, is the biggest clue. It's not a Snyk API issue, it's something broken in the plugin's own setup phase.