Stop your Keys in .env: Securely Auto-Wire Vertex AI for Local Dev

A developer detailed a method to securely auto-wire Google Cloud Vertex AI for local development by storing service account keys in the OS-native encrypted keyring instead of plaintext files. The approach uses secret-tool on Linux and security on macOS to keep credentials in memory, with a shell profile check to load them into the environment. The post also highlights common configuration traps, such as missing IAM role bindings and the need to explicitly set the VERTEX_SA_JSON environment variable when adding the backend.

Setting up GCP Vertex AI locally usually ends up with a service-account.json key sitting in your home directory or a raw export VERTEX SA JSON=$ cat ... shoved into your .bashrc . It works, but it's sloppy. Files get accidentally committed to git repositories, keys rot on disk, and plaintext credentials just sit there waiting to be read by any local process. Here’s how to auto-wire Vertex AI into Contenox cleanly using your system’s native encrypted keyring Linux or macOS , keeping credentials strictly in memory—along with the common configuration traps to avoid. First, spin up your service account and generate the JSON key via gcloud : 1. Create the service account gcloud iam service-accounts create vertex-runner \ --description="Service account for Contenox Vertex AI" \ --display-name="Vertex Runner" \ --project=YOUR PROJECT ID 2. Grant the Vertex AI User role CRITICAL — without this every call 403s gcloud projects add-iam-policy-binding YOUR PROJECT ID \ --member="serviceAccount:vertex-runner@YOUR PROJECT ID.iam.gserviceaccount.com" \ --role="roles/aiplatform.user" 3. Generate and download the JSON key gcloud iam service-accounts keys create service-account.json \ --iam-account=vertex-runner@YOUR PROJECT ID.iam.gserviceaccount.com The IAM Trap:Step 2 is easy to miss. Creating the account and key succeeds without it, but the key has zero permissions by default. If your requests throw 403 PERMISSION DENIED , this binding is usually what's missing. Instead of leaving service-account.json floating around in your user directory, pipe it directly into your OS's native encrypted keyring and delete the file immediately. For Linux GNOME Keyring / KWallet : Store key inside your system keyring secret-tool store --label="Contenox Vertex Key" service contenox key vertex sa < service-account.json Delete the local plaintext file rm service-account.json For macOS Apple Keychain : Store key inside macOS Keychain security add-generic-password -a "$USER" -s "contenox-vertex-sa" -w "$ cat service-account.json " Delete the local plaintext file rm service-account.json What about Windows? If you are on Windows, usingWSL Windows Subsystem for Linux is absolutely the way to go—it gives you the standard Linux toolchain so you can just use secret-tool exactly as shown above. If youmustrun Contenox natively in PowerShell, you can achieve this same memory-only injection using the Microsoft.PowerShell.SecretManagement module, or by leaning on cross-platform CLI tools like 1Password op or Bitwarden bws . Add a non-blocking check to the end of your shell profile ~/.bashrc on Linux, ~/.zshrc on macOS . When your shell fires up, it decrypts the key straight into RAM: Linux ~/.bashrc : Auto-load Contenox Vertex SA Key into memory if secret-tool lookup service contenox key vertex sa /dev/null 2 &1; then export VERTEX SA JSON=$ secret-tool lookup service contenox key vertex sa fi macOS ~/.zshrc or ~/.bashrc : Auto-load Contenox Vertex SA Key into memory if security find-generic-password -a "$USER" -s "contenox-vertex-sa" /dev/null 2 &1; then export VERTEX SA JSON=$ security find-generic-password -a "$USER" -s "contenox-vertex-sa" -w fi Reload your shell: source ~/.bashrc or source ~/.zshrc Now add the backend to Contenox and explicitly point it to VERTEX SA JSON : contenox backend add vertex --type vertex-google \ --url "https://aiplatform.googleapis.com/v1/projects/YOUR PROJECT ID/locations/global" \ --api-key-env VERTEX SA JSON contenox config set default-provider vertex-google contenox config set default-model gemini-3.6-flash The Gotcha:Youmustpass --api-key-env VERTEX SA JSON when adding the backend. If you omit it, Contenox ignores your environment variable and falls back to standard gcloud Application Default Credentials ADC , causing provider auth rejections if ADC isn't logged in. Test it out: contenox chat "say hi" op run , bws , or A Quick Side Note on Local Hygiene:While we're talking about Contenox here, this keyring injection approach makes sense foranylocal environment variable or credential, regardless of the harness, tool, or framework you're using. Whether it's a standalone CLI script, an agent harness, or custom tooling, keeping raw keys off your filesystem and out of plaintext .env files should be standard operating procedure across your entire local dev setup. P.S. If you've got unused GCP cloud credits sitting around in a project, this setup is a super convenient way to put them to work through Contenox instead of paying out-of-pocket for standard API endpoints