Guide
Vault Configurations for an Air-Gapped AI Agent Workspace
Air-gapped means no connection to any outside network at all. That one requirement rules out most of the vaults people reach for first.
A vault for an air-gapped AI agent workspace has to run with zero outbound calls, which immediately rules out any cloud secrets manager. Google Cloud Secret Manager always communicates over HTTPS to Google's own infrastructure and has no offline mode. ServiceNow is a cloud SaaS platform for IT workflow and, more recently, agentic AI through partnerships with Anthropic and OpenAI; it is not a secrets manager product and it does not run disconnected from ServiceNow's own cloud either. What actually works is self-hosted software you fully control, most commonly HashiCorp Vault or its open-source fork OpenBao, configured with an unseal method that does not call out to a cloud key management service, and with telemetry and update checks turned off so the process makes no network calls at all.
What 'air-gapped' actually requires from a vault
Air-gapped means a machine or network has no connection to any outside network, not even an occasional one. That is a stricter bar than 'secure' or 'offline for now.' A vault that is air-gap compatible has to work with zero outbound network calls, forever, not just when someone remembers to disconnect the Wi-Fi.
That single requirement eliminates an entire category of products before you even compare features. Any secrets manager that is delivered as a cloud service fails the test by definition, because the whole product is an API you call over the internet. The question worth asking first is not which vault has the best features. It is which vaults are software you run yourself, with no call home built into the core function.
- Air-gapped means zero connection to an outside network, permanently.
- A cloud-delivered secrets manager cannot meet that bar by definition.
- Start by asking who runs the vault process, not which features it has.
Why Google's secret tools fail the air-gap test
Google Cloud Secret Manager stores API keys, passwords, and certificates, and its own documentation is explicit that it always communicates over a secure HTTPS connection to Google's infrastructure. There is a regional option for data residency, but that only controls where inside Google's network your data sits, not whether a connection to Google is required at all.
Google's AI agent tooling, such as Gemini CLI and the Agent Development Kit, has its own separate story about what runs locally versus what needs the cloud, covered in detail elsewhere. For the vault question specifically, the answer is simpler: nothing in Google's current secrets tooling is built to run with no outbound connection, so it is not a candidate for a genuinely air-gapped workspace.
- Secret Manager requires a live HTTPS connection to Google's cloud.
- A regional setting changes where data sits, not whether a connection is needed.
- No Google secrets product currently ships an offline or air-gapped mode.
Why ServiceNow is not a vault for this either
ServiceNow sells the Now Platform, a cloud SaaS product for IT service management and workflow automation, delivered as a subscription with no on-premises air-gapped edition on offer. It has added generative AI features under the Now Assist name since 2023, including text-to-code and summarization, and in January 2026 it announced partnerships with Anthropic and OpenAI to bring agentic AI into the platform.
None of that makes ServiceNow a secrets manager. It is a workflow platform that happens to be adding AI agents, not a vault product you install inside your own air-gapped network. There is no integration between ServiceNow and Forkbench, and nothing about ServiceNow's cloud architecture changes once you add its AI features.
- ServiceNow is a cloud SaaS workflow platform, not a secrets manager.
- Its AI features (Now Assist, the Anthropic and OpenAI partnerships) run on that same cloud.
- There is no ServiceNow integration with Forkbench.
What actually runs air-gapped: HashiCorp Vault's license, and OpenBao
HashiCorp Vault is self-hosted software, which makes it a real candidate, but its licensing changed in a way that matters before you build on it. Vault's own license file states plainly that Business Source License 1.1 terms apply to 'Vault Version 1.15.0 or later,' with the work now copyrighted by IBM. That license permits non-production use freely but restricts production use that would compete with HashiCorp's own commercial offerings, which means Vault 1.15 and every version after it is not open source, whatever older articles may still say.
OpenBao is the answer to that change. It is a fork of Vault hosted under the Linux Foundation's OpenSSF, distributed under the MPL-2.0 license, which is OSI-approved open source. Being self-hosted and open source both matter for an air-gapped build: you need to be able to run the binary with no license server to call, and ideally to audit or patch it yourself if something breaks while you are disconnected.
- Vault 1.15.0 and later: Business Source License 1.1, not open source.
- OpenBao: the open-source fork, MPL-2.0, run by the Linux Foundation's OpenSSF.
- Either one is self-hosted, which is the baseline requirement for an air gap.
Configuring the vault for zero outbound calls
The default install of either Vault or OpenBao is not automatically air-gap safe, because some common configuration choices quietly depend on the internet. Auto-unseal using a cloud key management service, such as AWS KMS or Azure Key Vault, calls out to that cloud every time the vault starts. For an air-gapped build, use Shamir secret sharing or a local hardware security module for unsealing instead, since both work with no outside connection.
Turn off anything that phones home by default: update checks, telemetry, and any plugin that fetches from a public registry at startup. Point the vault at an internal certificate authority and internal DNS rather than a public one, and run it on the same isolated network segment as the agent that will use it, so there is no path between the two that touches an outside network even by accident.
- Avoid cloud KMS auto-unseal; use Shamir shares or a local HSM instead.
- Disable telemetry and update checks so the process makes no outbound calls.
- Use an internal CA and internal DNS, not public ones.
What a vault still does not solve, even air-gapped
A correctly configured, fully disconnected vault solves one problem: keeping a secret off disk in plain text. It does not solve what the agent can do once it is handed a secret, and it does not solve how code or model weights get into the air-gapped network in the first place, which usually still means someone carrying physical media across that boundary. Treat that transfer step as its own risk, not a detail.
Inside the air gap, the agent still has the same filesystem access as the account that runs it, vault or no vault. A locked-down vault and a locked-down filesystem are two different controls, and an air-gapped network does not make either one optional.
- A vault protects the secret at rest, not what happens after it is handed over.
- Getting code or models across the air gap is its own, separate risk.
- Filesystem access still matches the account running the agent, vault or not.
Where Forkbench fits, and where it does not
Forkbench runs coding agents on a Mac, each one in its own real terminal rather than a shared cloud environment. Its own Vault keeps keys in the macOS Keychain and lets a command use one by name, so the value never reaches the prompt, the command line, or the transcript, and a Thread can be locked to its folders by the macOS kernel sandbox.
That is a different scope from the self-hosted vault problem above. Forkbench protects secrets and folders on one Mac; it is not a drop-in replacement for a HashiCorp Vault or OpenBao cluster serving a whole air-gapped network, and it has no integration with Google Cloud or ServiceNow. The folder lock is also opt-in and does not restrict the network on its own, and Windows and Linux support is still in development with no date, so a mixed-OS air-gapped fleet cannot rely on it yet for every machine.
- Forkbench's Vault: local to one Mac, keys stay in the Keychain.
- Not a substitute for a self-hosted Vault or OpenBao cluster across a network.
- No integration with Google Cloud or ServiceNow; Windows and Linux are still in development.
Related: A secure local workspace for Google's AI agents, Evaluating the best vault systems for AI agent workplaces, The best vault solutions for an AI agency suite, Download Forkbench
Frequently asked
Can Google Cloud Secret Manager run in an air-gapped environment?
No. Its own documentation states it always communicates over HTTPS with Google's infrastructure, and there is no offline or air-gapped mode available.
Does ServiceNow offer a vault product for an air-gapped AI agent workspace?
No. ServiceNow is a cloud SaaS platform for IT workflow that has added agentic AI features. It does not sell a standalone secrets manager and does not run disconnected from its own cloud.
Is HashiCorp Vault still open source?
No, not from version 1.15.0 onward. Vault's own license file states that Business Source License 1.1 applies from that version. OpenBao, hosted by the Linux Foundation's OpenSSF under the MPL-2.0 license, is the open-source fork.
Can a self-hosted vault run with absolutely no network connection?
Yes, if you avoid cloud auto-unseal methods and disable telemetry and update checks. Use Shamir secret sharing or a local hardware security module to unseal it instead.
Does Forkbench work inside an air-gapped network?
Forkbench's Vault and folder lock protect one Mac and do not depend on any specific cloud, but it is not a substitute for a self-hosted vault serving a whole air-gapped network, and it has no integration with Google Cloud or ServiceNow.