Vault Management for Multi-Agent Systems on GitHub

What a multi-agent system actually needs to protect

A multi-agent framework like CrewAI lets you define several AI agents that split a job between them: one researches, one writes, one reviews, coordinated through what CrewAI calls Crews for a team of agents working together, and Flows for a more structured, step by step process. It is open source, written in Python, MIT licensed, and widely used, with roughly 59,500 stars on its GitHub repository at the time of writing.

None of that includes a vault. Running several agents instead of one just means several processes that might each need a key: one to call a search API, one to call a model provider, one to push a commit. The question this page answers is where those keys actually live, because the framework itself won't tell you.

• CrewAI: open source, Python, MIT licensed, built around Crews and Flows.
• More agents means more processes that each might hold a credential.
• The framework coordinates the agents. It does not manage their secrets.

CrewAI has no vault. Its own docs put keys in a .env file

Check CrewAI's own setup instructions and you'll find API keys configured the same way any Python script handles them: an environment variable or a .env file, with examples referencing variables like SERPER_API_KEY for its search tool. There is no mention of a credential vault, scoped per-agent tokens, or rotation anywhere in the core framework.

That is not a criticism specific to CrewAI. Most multi-agent frameworks are orchestration layers, not secrets infrastructure, and they leave this exactly where a single script would leave it. The difference is that a single script has one key to lose track of. A crew of five agents, each calling different services, has five, and a .env file does not tell you which agent used which key for what.

• CrewAI's setup docs show keys as environment variables or .env entries, nothing more.
• No built-in vault, scoped tokens, or rotation in the core framework.
• Five agents sharing one .env file means five unscoped keys with no record of who used which.

Running a crew from GitHub Actions: use GitHub's own vault first

If your multi-agent workflow runs from a GitHub Actions pipeline rather than a laptop, you already have a real secrets store available before reaching for anything else: GitHub's encrypted secrets, set at the repository, environment, or organization level. A workflow reads one through the secrets context, written as secrets.NAME, as either an input or an environment variable for a step.

Two details matter for a multi-agent job specifically. GitHub automatically masks a declared secret's value out of workflow logs, which matters when one of your agents prints its environment while debugging. And secrets are not passed to a workflow run triggered from a forked repository, with the single exception of the built-in GITHUB_TOKEN, which closes an obvious way a stranger's pull request could try to exfiltrate a key just by triggering your pipeline.

• Repository, environment, or organization level secrets, read through the secrets context.
• Masked automatically from logs, which covers an agent that prints its own environment.
• Not passed to a run from a forked repository, except GITHUB_TOKEN.

One key per agent, not one key for the whole crew

The easiest mistake, and the one a .env file encourages, is giving every agent in a crew the same key for the same service. It is simpler to set up, and it means that if one agent's output ever leaks that key, in a log, a committed file, or a prompt sent to a model provider, you have to assume every agent using it is compromised and rotate the whole crew's access, not just one agent's.

Scope a key to the one agent and the one service that needs it instead. It costs a few more minutes of setup, and it means a leak traces back to exactly one place, which is the entire point of doing this per agent rather than per crew.

• Shared keys mean a leak from any agent forces a rotation of all of them.
• Scoped, per-agent keys mean a leak traces to one agent and one service.
• This costs setup time once. It saves an incident response later.

What to put behind it once you're past a handful of agents

A .env file and GitHub's own secrets cover a small setup. Past a handful of agents calling a growing list of services, put an actual secrets platform behind both. HashiCorp Vault can issue short lived, scoped credentials on request instead of one static key, and revoke them on a lease, so a credential a crew agent used an hour ago simply stops working rather than staying valid until someone remembers to rotate it.

Infisical is a more drop-in option for teams that don't want to run Vault's infrastructure: it is open source, self-hostable or cloud-hosted, and it ships a feature called Agent Vault built specifically to broker outbound API access for AI agents, so an agent calls a service under a stored credential it never sees directly rather than holding the raw key itself.

• HashiCorp Vault: short lived, scoped, revocable credentials instead of one static key per service.
• Infisical: open source, with an Agent Vault feature purpose-built for AI agent access.
• Either one replaces a single shared key in a .env file once a few agents become a real pipeline.

What Forkbench covers here, and what it doesn't

If part of your multi-agent setup runs as coding agents in terminals on your own Mac rather than in CI, Forkbench's Vault handles the same problem on that side: a key stays in your Keychain, and a command uses it by name without the value reaching the prompt or a saved transcript.

It has nothing to do with GitHub Actions or a CrewAI pipeline running in the cloud. Forkbench is a Mac desktop app, not a CI secrets store, and it does not reach into a GitHub workflow or broker credentials for agents running somewhere else. If your crew runs entirely in CI, the GitHub secrets and the vault platform above are what you actually need, not Forkbench.

• Covers: keys a coding agent needs inside a Forkbench Thread, on your Mac.
• Does not cover: GitHub Actions secrets, or a crew running outside your Mac.
• Pair it with GitHub's secrets or a platform like Infisical for the CI half of the job.

A setup order that holds up

Work through this roughly in order, and you'll end up with a setup that survives one agent's key leaking instead of taking the whole crew down with it.

• Get every key out of a shared .env file and into GitHub's encrypted secrets or a vault platform.
• Scope one key per agent per service, not one key for the crew.
• Check log masking on purpose: have an agent print its environment once, deliberately, and confirm nothing real shows up.
• Add HashiCorp Vault or Infisical once you have more agents than you can track by memory.
• Keep the Mac side, if you have one, in Forkbench's Vault, separate from the CI side.