Guide
Securing API Keys in Offline Multi-Agent Systems
An offline multi-agent framework still needs keys for the tools it calls. Running the model locally changes what leaves your machine, not whether a key sits in a file an agent can read.
An offline multi-agent framework means the model runs on your own hardware, through something like Ollama, vLLM, SGLang or LM Studio, so no prompt or completion goes to a cloud provider. CAMEL-AI is the open source framework most people mean by this today, and its commercial counterpart Eigent, built on CAMEL-AI, ships an Enterprise tier with cloud, enterprise gateway, local and bring-your-own-key model options. Neither includes a built in secrets vault: CAMEL-AI's own setup reads provider keys from plain environment variables, the same as a single script would. Claude cannot be the local part of this, since the Claude Platform only runs through Anthropic's own servers or a cloud partner such as AWS Bedrock, Google Cloud or Microsoft Foundry. The keys worth protecting in an offline setup are the ones your agents still use for GitHub, a search API or a deploy target, and those need the same treatment they would need anywhere: out of the project folder, into a keychain or a secrets manager, injected only at the moment a command runs.
What 'offline' actually covers, and what it does not
Offline, in a multi-agent context, means the reasoning model runs on hardware you control instead of calling out to a provider's API. That is a real and meaningful boundary: no prompt or completion leaves the machine, and there is no bill per token.
It does not mean the system has no network access. A crew of agents built to do real work usually still calls a search API, reads and writes to GitHub, hits an internal service, or deploys something. Each of those calls needs a credential, and that credential is exactly as exposed offline as it would be if the model itself were cloud hosted.
So the first thing to get straight before picking a framework is which calls are actually local and which ones still carry a key. Confusing the two is how a team ends up feeling secure about a setup that still has three live tokens sitting in a .env file.
- Local model inference removes the model provider's key, not every other key.
- A tool-calling agent that reaches GitHub, a search API or a deploy target is making a network call with a credential, offline model or not.
- Check each tool the crew can call, not just where the model runs.
CAMEL-AI: the open source framework, and what it leaves to you
CAMEL-AI is the open source multi-agent framework most people mean when they search for an offline multi-agent setup. It builds agents through a ModelFactory abstraction that can point at a cloud provider or a local server, and its own documentation walks through connecting Ollama, vLLM, SGLang and LM Studio, each running at a localhost address with no cloud key involved for that part.
Credential handling in CAMEL-AI is plain. Its examples set a provider key with an ordinary environment variable, such as OPENAI_API_KEY, and the repository ships a .env.example file for local configuration. There is no built-in vault, no encrypted store, and no mechanism that keeps a key out of the process environment the agent inherits.
That is a reasonable design for a framework meant to be embedded in whatever you are building, but it means the security work is yours. If an agent built with CAMEL-AI can read its own process environment, or can be asked to print it for debugging, the key is one bad prompt away from your transcript.
- CAMEL-AI's ModelFactory supports local backends: Ollama, vLLM, SGLang, LM Studio.
- Provider credentials are read from environment variables, by design.
- No built-in vault or encrypted credential store ships with the framework.
Eigent: the enterprise piece, built on CAMEL-AI, not the same thing
Eigent is a separate product from the same team, built on top of CAMEL-AI, packaged as a desktop app for Mac, Windows and Linux with a self-hosted option. Its own site advertises an Enterprise tier offering custom features and integrations, local deployment, and what it calls enterprise grade security, alongside a model picker that spans cloud, an enterprise gateway, local models and bring-your-own-key.
That bring-your-own-key language matters for the question this page is answering. Eigent's enterprise framing is about deployment and governance, where the agents run and who administers them, not about taking the key itself out of your hands. You still provide the key; Eigent lets you choose where the request that uses it goes.
Worth separating clearly: CAMEL-AI itself has no enterprise edition. If a listing or a search result implies otherwise, it is almost certainly describing Eigent, the application, not the framework underneath it.
- Eigent is a desktop multi-agent app built on CAMEL-AI, not CAMEL-AI itself.
- Its Enterprise tier covers deployment and governance, including local and self-hosted options.
- Bring-your-own-key means you still hold the key; Eigent routes where it is used.
Why Claude cannot be the local half of this
Anthropic calls its developer offering the Claude Platform, and every path into it is a network call: directly to Anthropic, or through a cloud partner such as AWS Bedrock, Google Cloud or Microsoft Foundry. There is no downloadable Claude model and no on-premises deployment, so a search for an offline Claude setup inside a multi-agent framework is looking for something that does not exist.
What you can run locally is everything around that one network call: the files an agent reads and writes, the commands it executes, and the other tools it has access to. The call to Claude itself still needs an API key that leaves your machine, so it belongs in the same category as the GitHub or deploy credentials above, not in the part of the system you can make fully offline.
If you are specifically trying to manage Claude Code sessions without exposing more than you have to, that is a related but different problem from the offline-model question this page covers.
- Claude Platform access is always a network call, direct or through AWS, Google Cloud or Microsoft Foundry.
- No local weights, no on-premises Claude deployment exists today.
- A Claude API key is a key like any other: keep it out of files an agent can read.
Where to put the keys CAMEL-AI and Eigent do not manage
Since neither framework ships a vault, the job falls to the operating system or a dedicated secrets manager, and both can be made to work fully offline. On a Mac, the Keychain stores a secret encrypted and hands it to a process only when asked. HashiCorp Vault and a self-hosted Infisical instance do the same thing for a team, and both can run entirely on infrastructure you control with no outbound dependency.
If the multi-agent process is launched from a terminal on your own Mac, Forkbench's Vault is another option worth knowing about: it keeps keys in the macOS Keychain and lets a command use one by name, so the value does not have to sit in the environment variable the agent's own code reads directly.
State the limit plainly, because it matters here. A Vault key that is not pinned to one Thread can still be read by whatever program you ran it with, the same way any secrets manager hands a real value to a process that asks correctly. Vaulting a key changes where it rests. It does not change what a command is allowed to do once it has been handed the value.
- macOS Keychain, HashiCorp Vault and a self-hosted Infisical instance all run without a cloud dependency.
- Forkbench's Vault keeps a key in the Keychain and releases it to a named command.
- An unpinned Vault key can still be read by the program it was run with; vaulting moves the key, it does not limit the command.
A setup that is actually offline, end to end
Pick the pieces in order of what they actually remove. The model call is the first and easiest to take offline, through Ollama, vLLM, SGLang or LM Studio behind CAMEL-AI's ModelFactory, or through Eigent if you want the packaged app and its Enterprise deployment options.
Every remaining tool call, GitHub, search, deploy, a Claude or OpenAI key for a step you still want cloud reasoning on, gets the same treatment: out of the .env file, into the Keychain or a self-hosted secrets manager, handed to the one command that needs it and nowhere else.
Then test it the boring way. Ask the crew to print its own environment and confirm the keys you moved are not there. That single check catches most of what goes wrong in practice.
- Take the model call offline first: Ollama, vLLM, SGLang or LM Studio.
- Move every remaining tool credential into the Keychain or a self-hosted secrets manager.
- Confirm a printed environment no longer contains the keys you moved.
Related: Managing Claude AI agents offline, API key security in a Python multi-agent framework, Letting an agent deploy without handing it the credential, Download Forkbench
Frequently asked
Can CAMEL-AI run completely offline?
The model call can. CAMEL-AI's ModelFactory connects to local backends such as Ollama, vLLM, SGLang and LM Studio with no cloud model provider involved. Any other tool an agent calls, GitHub, a search API, a deploy target, still makes its own network call with its own credential.
Does CAMEL-AI or Eigent include a secrets vault?
No. CAMEL-AI reads provider keys from environment variables and ships a .env.example file; there is no built-in encrypted store. Eigent, the desktop app built on CAMEL-AI, lets you bring your own key and choose where it is used, but it does not vault the key for you.
Is Eigent the same thing as CAMEL-AI?
No. CAMEL-AI is the open source multi-agent framework. Eigent is a separate desktop application built on top of it, with its own Enterprise tier covering deployment, local hosting and governance.
Can Claude be run offline inside a multi-agent system?
No. The Claude Platform only runs through Anthropic's own infrastructure or through AWS Bedrock, Google Cloud or Microsoft Foundry. There is no downloadable or on-premises Claude model, so a Claude call always needs a key that leaves the machine.