Pass credentials into the microVM

By default the microVM gets nothing from your host environment beyond what the agent itself needs to authenticate (its own API key or OAuth token) and the proxy settings inherited from your shell. Every other credential has to be passed in explicitly.

Two mechanisms exist: --pass-env for arbitrary environment variables, and --pass-cloud-creds for cloud-provider credentials that often involve files as well as variables.

Both mechanisms deliver credentials over vsock and stage them on tmpfs inside the microVM. They are never written to disk on the host, never persisted in the microVM overlay, and discarded when the microVM exits.

Pass an environment variable

--pass-env <KEY> passes a single host environment variable into the microVM. The flag is repeatable.

To give the agent GitHub CLI access:

export GH_TOKEN=$(gh auth token)
agentguard run claude-code --pass-env GH_TOKEN --workspace ~/projects/myapp

Inside the microVM, gh picks up GH_TOKEN automatically and can open issues and pull requests on your behalf.

For private package registries:

agentguard run claude-code \
  --pass-env NPM_TOKEN \
  --pass-env PIP_INDEX_URL \
  --pass-env PIP_EXTRA_INDEX_URL \
  --workspace ~/projects/myapp

For service API keys, pass each one with its own flag:

agentguard run claude-code \
  --pass-env DATADOG_API_KEY \
  --pass-env SENTRY_DSN \
  --pass-env SLACK_BOT_TOKEN \
  --workspace ~/projects/myapp

Pass cloud provider credentials

--pass-cloud-creds <provider> passes only the variables and files needed by a named cloud provider. The flag is repeatable and accepts comma-separated values.

Valid providers: aws, gcp, azure, vault, kubernetes, all.

AWS

agentguard run claude-code --pass-cloud-creds aws --workspace ~/projects/myapp

Passes AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE, AWS_REGION, and AWS_DEFAULT_REGION. If AWS_SHARED_CREDENTIALS_FILE points to a file, the file is copied into the microVM at /run/creds/.cloud-creds/aws-credentials and the env var is rewritten to point at the new location.

GCP

export GOOGLE_APPLICATION_CREDENTIALS=~/.config/gcloud/svc-account.json
agentguard run claude-code --pass-cloud-creds gcp --workspace ~/projects/myapp

The service account key file is staged into the microVM and GOOGLE_APPLICATION_CREDENTIALS is rewritten to /run/creds/.cloud-creds/gcp-service-account.json. CLOUDSDK_CONFIG, GOOGLE_CLOUD_PROJECT, and GCLOUD_PROJECT are also passed when set.

Azure

export AZURE_CLIENT_ID=... AZURE_CLIENT_SECRET=... AZURE_TENANT_ID=...
agentguard run claude-code --pass-cloud-creds azure --workspace ~/projects/myapp

Passes AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID, and AZURE_SUBSCRIPTION_ID.

Vault

export VAULT_ADDR=https://vault.internal:8200
export VAULT_TOKEN=hvs.xxxxx
agentguard run claude-code --pass-cloud-creds vault --workspace ~/projects/myapp

Passes VAULT_ADDR, VAULT_TOKEN, and VAULT_NAMESPACE.

Kubernetes

agentguard run claude-code --pass-cloud-creds kubernetes --workspace ~/projects/myapp

If KUBECONFIG points to a file, the file is staged into the microVM and the env var is rewritten.

Combining providers

Use comma-separated values for multiple providers in one flag:

agentguard run claude-code --pass-cloud-creds aws,gcp --workspace ~/projects/myapp

Or repeat the flag:

agentguard run claude-code \
  --pass-cloud-creds aws \
  --pass-cloud-creds gcp \
  --workspace ~/projects/myapp

Pass every supported provider at once with all:

agentguard run claude-code --pass-cloud-creds all --workspace ~/projects/myapp

Combining cloud credentials with other env vars

--pass-env and --pass-cloud-creds work together:

export GH_TOKEN=$(gh auth token)
agentguard run claude-code \
  --pass-cloud-creds aws \
  --pass-env GH_TOKEN \
  --pass-env CUSTOM_API_KEY \
  --workspace ~/projects/myapp

One-time credentials

For a credential needed only for a single run, set it inline rather than exporting it in your shell:

GH_TOKEN=$(gh auth token) agentguard run claude-code --pass-env GH_TOKEN --workspace ~/projects/myapp

The variable is read from the shell context for that one invocation and discarded when the microVM exits.