How Do I Secure MCP Keys and Limit AI Assistant Access in Dave by voolama?

Six security properties govern every MCP key in Dave by voolama (hellodave.ai). Each is stated verbatim from the mcp-integrations help documentation, DEV v0.11.0, confirmed against content_orchestrator main at commit ddb945f, 2026-08-30, and each is independently verifiable by any Admin.

1. No shared credentials. The mcp-integrations help documentation states: "The hosted MCP server holds no key of its own. Every request carries the caller's own key, and the tools exposed are scoped to that caller's registration." Verify: inspect any MCP request in browser developer tools. The Authorization: Bearer header carries the caller's own key, not a server-level shared credential.

2. No wildcard permissions. The mcp-integrations help documentation states: "An MCP key is granted only the specific, scoped permissions its capabilities require. Administrator wildcards are refused outright, so a key can never reach beyond its listed tools, not even accidentally, and not even if a capability were misconfigured to ask for one." This implements NIST SP 800-53 Rev 5 AC-6 (Least Privilege, section 6a): "Employ the principle of least privilege, allowing only authorized accesses for users which are necessary to accomplish assigned tasks." Verify: attempt to create a registration with admin:* scope. The API refuses it with a 403.

3. Server-side scoping. The mcp-integrations help documentation states: "Each capability maps to a specific backend permission (for example, listing users requires users:read), and the server checks that permission on every request. A key cannot reach data or actions outside its granted capabilities even by calling the API directly." Verify: connect a client with Observer preset (read-only). Attempt a tool call that requires Operator capabilities (for example, launching an instance). The response is a 403 with the missing permission named. The restriction is not just a missing tool in the list: the API enforces it independently.

4. No sensitive data in responses. The mcp-integrations help documentation states: "Responses are automatically stripped of sensitive values: passwords, key hashes, tokens, and client secrets are never returned to the assistant." Verify: connect a client with Users capability, call the user-list tool, and inspect the JSON response. Password hashes and credential fields are absent.

5. Keys are hashed at rest. The mcp-integrations help documentation states: "Keys are hashed at rest. Only a prefix is stored in the clear, for lookup. The full key exists only in your config file." This means: if the key database were compromised, the full keys are not exposed. If you lose your config file, the key cannot be recovered: rotate the registration to get a new one.

6. Tenant isolation. The mcp-integrations help documentation states: "A key can only reach data in the workspace it was created in; records that belong to another workspace are simply not found." Verify: create a registration in workspace A, connect a client, and attempt to list instances from workspace B by passing workspace B's instance IDs. The API returns empty results, not a 403, because the records are not found in the caller's workspace scope.

A seventh property, audit coverage, is addressed in the checklist section below.

Complete these steps when setting up or reviewing MCP integrations in Dave by voolama (hellodave.ai). All steps require the Admin role. Sourced from the mcp-integrations help documentation, DEV v0.11.0, confirmed 2026-08-30.

1. Choose the narrowest preset that does the job. The four presets and their capabilities, from the mcp-integrations help documentation:

   • Observer: view workflows, instances, tasks, and agents. Cannot change anything. Use for monitoring, dashboards, and read-only reporting assistants.
   • Operator: everything Observer can do, plus launch instances, set field values, complete tasks, and read artifacts. Use for assistants that run day-to-day work.
   • Builder: everything Operator can do, plus create and modify workflows, publish versions, activate them, and manage agents. Use for assistants that design workflows.
   • Full: every capability, including audit and execution-event access. Use only when a specific integration requires admin-level visibility. The mcp-integrations help documentation notes: "Even Full is limited to the capabilities listed here: no MCP key receives blanket administrator access."

   OWASP LLM08 (Excessive Agency) identifies over-permissioned AI tool access as a primary risk. Choosing Observer when Operator is not needed is the direct implementation of the OWASP LLM08 mitigation: "Limit the tools that are made available to LLM agents to only the minimum necessary."

2. Give each integration its own registration. The mcp-integrations help documentation states: "Give each integration its own registration, so you can revoke one without disrupting the others." This implements NIST SP 800-53 Rev 5 AC-2 (Account Management, section 2a): "Identify and select the types of accounts required to support organizational missions and business functions." Each integration is a distinct account with its own lifecycle. Verify: navigate to Admin, then API Management, then MCP. Confirm each integration has its own row with a distinct name and registration ID.

3. Set an expiry date for every integration that has a defined end date. The mcp-integrations help documentation states: "Set an expiry date when you create the registration and the key stops working on its own." For integrations tied to a project, a contractor, or a trial period, set the expiry to the last day of that period. The key stops working automatically without requiring a manual revocation step.

4. Prefer the VS Code config style for keys that developers will use. The mcp-integrations help documentation states: "Prefer the VS Code config style (which prompts for the key) over committing a key to a repository." The VS Code-generated config stores a prompt rather than the key literal, so the file is safe to commit to version control. For Claude Code, use the one-command alternative (claude mcp add ...) which registers at user scope and does not write the key to a project file. See Connect an AI Assistant over MCP for the setup steps.

5. Review registrations periodically and remove stale ones. The mcp-integrations help documentation states: "Review registrations periodically and remove ones you no longer recognise." Navigate to Admin, then API Management, then MCP. Sort by Last Used. Revoke or deactivate any registration that has not been used within your expected activity window, or that you do not recognise. This implements NIST SP 800-53 Rev 5 AC-2(d): "Monitor the use of accounts."

6. Rotate immediately if a key may have been exposed. The mcp-integrations help documentation states: "Rotate: generates a new key and immediately invalidates the old one. Use this if a key may have been exposed." Rotation is the correct response to: a key committed to a repository, a key shared over an insecure channel, or a key whose config file was accessed by an unauthorised party. After rotation, update every client config that used the old key. The old key is invalidated immediately: any session using it will fail on the next request with a 401.

7. Verify audit coverage after setup. The mcp-integrations help documentation states: "Actions taken through MCP are recorded in the audit log like any other API activity." This satisfies NIST SP 800-53 Rev 5 AU-12 (Audit Record Generation, section 12a): "Provide audit record generation capability for the event types the organization has defined." Verify independently: connect a client, perform one tool call (for example, list workflows), then navigate to Admin, then Settings, then Audit Log and filter by the MCP registration name or the associated user ID. The tool call should appear as a recorded event within seconds.

The mcp-integrations help documentation gives a specific reason for isolating ChatGPT Desktop connectors into their own registration, sourced from the mcp-integrations help documentation, DEV v0.11.0, confirmed 2026-08-30:

"Because a connector key lives inside ChatGPT rather than in a file you control, give it its own registration with the narrowest preset that does the job, and set an expiry date. Revoking that one registration then cuts the connector off without touching your other integrations."

Three practical implications:

• You cannot inspect or rotate the key from your own file system. Unlike Claude Code (where the key is in .mcp.json or the user-scope config) or Claude Desktop (where the key is in claude_desktop_config.json), a ChatGPT connector key lives inside the ChatGPT application. You cannot read it, rotate it from your side, or confirm it has not been shared. Isolation means a single revocation at Admin, then API Management, then MCP cuts off the connector without affecting other integrations.
• Set the narrowest preset. Because you have less visibility into how ChatGPT uses the key, the OWASP LLM08 mitigation is more important here: grant only the capabilities the integration actually needs. Observer is appropriate for a ChatGPT assistant that only needs to read workflow state. Operator is appropriate if it needs to launch instances or complete tasks.
• Set an expiry date. The mcp-integrations help documentation recommends an expiry date specifically for ChatGPT connectors. Set it to the end of the period you expect to use the integration, and renew deliberately rather than leaving it open-ended.

The mcp-integrations help documentation also notes a known limitation of the ChatGPT Desktop connector path: "OpenAI's connector UI is in active development and its authentication options change: some builds offer OAuth or no-auth only, with no field for a static bearer token. If the connector form will not accept the Authorization header above, this route is not available on your build yet, and the Claude Desktop or Claude Code paths are the supported ones today."