Integrations: secrets on the network, not on the VM

Integrations “inject secrets” on the network, “so that those secrets cannot be extracted from the VM itself.” The VM, and any agent on it, can use an integration but can never read the secret behind it.

Sources: https://exe.dev/docs/integrations, https://exe.dev/docs/integrations-attach, https://exe.dev/docs/integrations-http-proxy, https://exe.dev/docs/integrations-github, https://exe.dev/docs/integrations-llm, https://exe.dev/docs/integrations-reflection, https://exe.dev/docs/integrations-aws-wif, https://exe.dev/docs/integrations-catalog.

The model

flowchart LR
  A[Agent on VM] -->|http://name.int.exe.xyz/...| E[exe.dev edge]
  E -->|adds stored header / signs request| T[Target API]
  K[(Secret stored<br/>server-side)] -.-> E
  A -.x|cannot read| K

• How you create and attach them. Integrations are created with integrations add and attached with integrations attach, over SSH or from the Integrations page in the web UI.
• Where the secret lives. It is “stored server-side and injected at the network edge when your VM calls the integration hostname.”
• Listing them. integrations list --json shows stored secrets as ***.
• Discovering what’s available. integrations list --available prints the built-in types, the catalog services and the databases you can add.

Built-in types

The catalog “covers well over a hundred services” (https://exe.dev/docs/integrations-catalog).

Identity federation (no stored keys)

There are workload identity federation guides for AWS, GCP, Anthropic, OpenAI and Tailscale. For example: “Identity Federation lets an attached VM mint short-lived exe.dev OIDC tokens. AWS trusts those tokens through an IAM OIDC provider, then exchanges them for temporary role credentials with AssumeRoleWithWebIdentity” (https://exe.dev/docs/integrations-aws-wif).

Attaching

integrations attach blog vm:my-vm      # one VM
integrations attach blog auto:all      # every VM
integrations attach blog tag:prod      # any VM tagged prod
tag my-vm prod
new --name my-vm --integration blog --integration myapi
integrations detach blog vm:my-vm

Default integrations

New accounts get two integrations attached to auto:all by default:

• reflection
• llm, which calls https://llm.int.exe.xyz/v1/models “without storing provider API keys on the VM”

Worked example: HTTP proxy

integrations add http-proxy --name myapi --target https://api.example.com --bearer sk-... --attach tag:prod
# from an attached VM:
curl http://myapi.int.exe.xyz/users

With --strip-prefix /api/v3, a request to http://myapi.int.exe.xyz/api/v3/users is forwarded to https://api.example.com/users.

The LLM integration in more detail

Each provider in the integration gets one source:

• exe.dev LLM gateway. Uses exe.dev’s managed credentials and your exe.dev LLM allocation.
• API key. The VM can call the integration but can’t read the key.
• ChatGPT subscription. OpenAI only, on personal integrations only. It needs device-code login enabled in ChatGPT.
• Custom HTTPS endpoint.
• Disabled.

Team LLM integrations can use the gateway or provider API keys (https://exe.dev/docs/integrations-llm).

According to https://exe.dev/docs/shelley/llm-gateway, the gateway provides managed access to:

• Anthropic, OpenAI, Fireworks and xAI models
• Deepgram recorded-audio transcription

Why this matters for agents

An agent running on a VM can be prompt-injected, and it can read every file on the VM. Integrations change what it can leak. It can call GitHub or your API, but it can’t exfiltrate the token, because the token was never on the VM. Pair this with egress <vm> integrations to block the rest of the internet (https://exe.dev/docs/internet-access).