Thanks — I’ll walk you through how to manage GCS secrets so your LiveKit agent can egress into your GCS bucket. I’ll cover the recommended steps, two ways to provide credentials to the agent, how to configure egress, and security best practices. Acknowledging your question: you want secure, practical guidance for storing and supplying Google Cloud credentials so LiveKit egress can write to your GCS bucket. 1) Create a service account and key • In Google Cloud Console → IAM & Admin → Service Accounts, create (or reuse) a service account. • Grant it the minimal role needed to write objects to your bucket (e.g., Storage Object Creator on that bucket). • Create and download a JSON key for that service account. Treat the JSON as highly sensitive. 2) Two safe ways to supply credentials to your LiveKit agent • Option A — Environment variable (recommended for most deployments) ◦ Upload the JSON key as a file in your deployment environment or secret manager. ◦ Set

GOOGLE_APPLICATION_CREDENTIALS

to the path of that JSON file in the agent’s environment. The Google Cloud libraries used by LiveKit plugins will pick this up automatically. ◦ In LiveKit Cloud you can store the JSON as a file-mounted secret and set the env var to the mounted path. • Option B — Pass credentials directly to the plugin (useful for programmatic/ephemeral credentials) ◦ Load the JSON into memory and pass it as

credentials_info

(a dict/object) or set

credentials_file="/path/to/key.json"

when constructing Google plugins (STT/TTS or other Google integrations) in the agent. ◦ Example: provide the JSON fields (type, project_id, private_key, client_email, etc.) to the plugin API so it authenticates without relying on env vars. 3) Configure egress to target GCS • When starting composite egress (TrackCompositeEgress or RoomCompositeEgress), specify the output bucket. • Use the S3-style output configuration but supply your GCS bucket name; access/secret fields can be left empty when using a service account credential. • Ensure the service account has Storage Object Creator permission for that bucket and any prefix you use. 4) Security best practices • Never commit the JSON key to source control. • Store the JSON in a secret store or file-mounted secret; avoid plaintext in code. • Use least privilege: grant only required permissions to the service account. • Rotate keys periodically and revoke old keys. • Prefer short-lived credentials or workload identity where possible (if you run in GKE/GCE, consider using Workload Identity or instance service accounts instead of long-lived JSON keys). If you’d like, tell me: • Where you run the agent (LiveKit Cloud, GKE, VM, etc.) so I can give exact steps for storing the file or setting the env var there. • Whether you prefer file-mounted secrets or passing credentials in code — I’ll provide the exact config/snippet for your environment. Sources: Google Gemini LLM plugin guide | LiveKit docs | Google Cloud TTS integration guide | LiveKit docs | Google Cloud STT plugin guide | LiveKit docs | server-sdk-ruby | livekit/livekit_composite | DeepWiki