Your own keys in OpenBao: Context7 and O'Reilly

Many developers already reach two tool servers straight from their editor: Context7 for current library documentation and O’Reilly for books, videos and courses. Each needs a personal key, so each person’s .mcp.json carries one:

"oreilly": {
  "type": "http",
  "url": "https://api.oreilly.com/api/content-discovery/v1/mcp/",
  "headers": {
    "Authorization": "Bearer ${OREILLY_MCP_TOKEN}"
  }
},
"context7": {
  "type": "http",
  "url": "https://mcp.context7.com/mcp",
  "headers": {
    "CONTEXT7_API_KEY": "${CONTEXT7_API_KEY}"
  }
}

That works for one person on one machine. It does nothing for the chat workspace, for agents or for a colleague, and the key sits in an environment variable or a file. This article moves both servers behind the platform. An administrator connects each one once. Each person keeps their own key in their own OpenBao folder, sets or changes it from the console or from OpenBao, and the key goes out only on their own calls. It is never in a chat, a config file or a shared account.

Everything below was done on a live system on 27 September 2026. The screenshots are real, with names and addresses replaced.

Who does what

People cannot register servers or declare variables themselves: each of those decides where the platform sends traffic and credentials. What they control is their own key.

Where your key lives

Every person’s values sit in one folder of the kv secrets engine (KV version 2):

kv/
└── users/
    └── ayse.demir@corp.example/
        └── mcp/
            ├── context7    CONTEXT7_API_KEY
            └── oreilly     OREILLY_MCP_TOKEN

Read the path kv/users/<email>/mcp/<server> part by part:

Two more things about the path:

• Nobody can list kv/users/. No one can see which colleagues have a vault, so you open your own folder by its full path. The console links to it for you.
• The command line and the web UI use kv/users/…; the underlying API and policies use kv/data/users/… for values and kv/metadata/users/… for versions. If a tool asks for the API path, that is the one.

Part A: the administrator

A1. Start from what your .mcp.json already says

Each entry of the .mcp.json above answers a question on the console’s forms:

The slug is fixed when the server is registered. If the name is already taken, the platform adds -2, and the OpenBao folder follows the slug, so check the brackets on /mcp before you tell people where their key lives.

A2. Register each server

On /mcp → Register a server, enter the name and URL, leave Auth at none (there is no shared key: every person brings their own), and tick require user (signed assertion). Then press Register & sync.

Context7 answers without a key, so its tools appear at once. O’Reilly refuses anyone without a token, so its first sync fails, and the row says exactly what to do next:

That is expected. The next two steps fix it.

A3. Declare the variable, and choose the server first

On /mcp → Variables → Declare a variable, the first field is Server. It decides everything else about this variable:

• It is where the value goes. A person’s value for this variable is sent to this server and to no other.
• It is where the value lives. The value is stored in mcp/<this server's slug> in each person’s OpenBao folder.
• It cannot be changed later. Editing a declaration lets you change delivery, header, template, format, required, secret and description, but not the server and not the name. A variable on the wrong server has to be deleted and declared again, and deleting it deletes every value people have stored for it.
• Two servers never share a variable. If two servers take the same token, declare it on each, and each person saves it once for each.

The rest of the form comes straight from the header line in .mcp.json:

Write a description for each; people read it on their own page. After Declare, both servers show their variable and where it is delivered:

What the platform enforces for you: people supply values only, never a header or a template; transport headers and the platform’s own headers cannot be targeted; and a required variable that a person has not set stops their call with a link to their page, before anything reaches the tool server.

A4. Save your own key, then Sync tools

A server with no shared key refuses even to list its tools anonymously. Sync tools therefore runs with the pressing administrator’s own value. Save your own O’Reilly token on My variables first (step B1 below), then press Sync tools on the row:

The cached tool list is what your token can see. Every person’s calls still carry their own token.

By default a server is open to all signed-in users of the allowed teams. For a server only some people should reach, set its Access to granted and add them. The GitHub article walks through the same steps for a third service.

Part B: each person

B1. Save your key on My variables

Sign in to the console and open My variables (/vault). A server whose required key you have not saved says so:

Paste your key and press Save. The row then shows set, a short fingerprint and in OpenBao. The value is never shown again, not even to you. To change it later, type the new key and press Replace; the fingerprint changes.

The box at the top of the page names your folder and links to it:

B2. Check it in OpenBao

Follow open my folder in OpenBao. Choose method OIDC, leave Role blank, and sign in with the same company account you use for the console. An administrator should also leave the role blank for this: the administrator role is for running the vault, not for personal keys.

The link opens mcp/ in your folder. There is one secret per server:

Open one. It holds one key, named exactly like the variable, with its value masked until you reveal it:

B3. Change it in OpenBao

On the secret, press Create new version, replace the value, and Save. Keep the key name exactly as it is, and do not delete the other rows if the secret has several keys: the new version is the whole secret.

There is nothing to save on the console. The platform reads your folder on every call, so the next call uses the new key, and My variables shows the new fingerprint and time:

A key typed into OpenBao is checked exactly like one saved on the console: no line breaks, at most 8 KiB, and the variable’s format. A value that fails is refused as unusable rather than sent. A key you add under a name the server does not declare is kept and never sent.

B4. The same from the command line

Point the bao client at your vault and sign in; a browser window completes the company sign-in:

export BAO_ADDR=https://vault.corp.example
bao login -method=oidc
bao token lookup

bao token lookup shows your folder name as meta.email. List your folder, read a secret and see its versions:

bao kv list kv/users/ayse.demir@corp.example/mcp
bao kv get kv/users/ayse.demir@corp.example/mcp/context7
bao kv metadata get kv/users/ayse.demir@corp.example/mcp/context7

To change one key, use patch, and pass the value on standard input so it never lands in your shell history (read -rs does not echo what you paste):

read -rs NEWKEY
printf '%s' "$NEWKEY" | bao kv patch kv/users/ayse.demir@corp.example/mcp/context7 CONTEXT7_API_KEY=-
unset NEWKEY

Do not use bao kv put to change one key. put writes a whole new secret: every key you do not name is dropped. patch changes only the keys you name. This matters for a server with several variables.

What each command answered for a member, run against the live vault:

Use it from your editor

Once both servers are on the platform, your .mcp.json no longer carries anybody’s key. It points at the platform’s relay and sends your personal platform key; the relay adds your Context7 or O’Reilly key from your folder on the way out:

"context7": {
  "type": "http",
  "url": "https://ai.corp.example/api/mcp/context7",
  "headers": {
    "Authorization": "Bearer ${BOSPHORUS_KEY}"
  }
},
"oreilly": {
  "type": "http",
  "url": "https://ai.corp.example/api/mcp/oreilly",
  "headers": {
    "Authorization": "Bearer ${BOSPHORUS_KEY}"
  }
}

Replace ai.corp.example with your platform’s address. The last part of each URL is the server’s slug. The chat workspace, the editor extension and agents reach the same servers the same way, each with the key of whoever is asking. In aimo for VS Code there is nothing to add to a file: once you are signed in it reaches the same servers through the relay, and its Vault view writes your variables into the same folder.

What the platform promises about your key

• It is read from your folder on each of your calls, and sent only to the one server it was declared on. There is no cache: a change applies to the next call.
• It is never in the model’s context, never in a log line, and never in the audit trail, which records the variable’s name only. If a tool’s answer echoes it, the stored copy shows [uservar:CONTEXT7_API_KEY] instead.
• The console never shows it, to you or to its administrators, and no ordinary sign-in can list other people’s vaults. The few people who run OpenBao itself hold a role that can reach every folder; keep that group small.
• If OpenBao cannot be read for a moment, a required key stops the call with could not be read from the vault just now … try again. It never says the key is missing, and it never sends the call without it.
• Remove on My variables deletes it. Removing the last key of a server destroys that secret with its history. Removing one of several keys leaves the old value in the secret’s version history, which you can destroy in OpenBao.

When something is not right