-
Notifications
You must be signed in to change notification settings - Fork 3
plat 503
State: built on main, not deployed, not verified in a live chat. P2. Owner decision 2026-10-05: agents should be able to do it.
Found: 2026-10-05, RTS. The owner asked a chat agent to connect a Vault MCP connection; it could use Notion MCP but said "Vault MCP share isn't available from chat tools" and sent the owner to the Integrations UI. Vault itself was running (video-studio-vault active).
What exists today (read from the code, not tried live): the connection tools in agent_go/cmd/server/mcp_connection_tools.go can list servers (including the Vault inventory) and remove or rediscover one; Vault secret access can be granted to a group by manage_vault_secret_access, but only from the admin CapLayer chat. Code has a per-place attach tool (place_mcp_attach.go, place_mcp_tool.go). No chat tool attaches or shares a Vault MCP connection to a Crew or workflow.
Decision (owner, 2026-10-05): what an agent may attach or share follows the person it acts for: their account (email) and role, exactly as the Builder MCP connection follows the account (PLAT-487). A read-only account cannot; an account can only share a connection it is allowed to manage. No separate agent-level permission and no global switch.
Built: manage_vault_access (the Vault chat's tool: connect catalog/custom MCP servers, sign in, status, sync, disconnect, inspect groups and tools, save group permissions) is now offered in every Code, Crew and workflow chat, not only the Vault chat. Scope per the owner: anyone who may manage Vault can do it from anywhere. registerVaultAccessChatTool (agent_go/cmd/server/vault_access_chat_tool.go) registers it only for an active administrator with the Vault product and capLayerConnectionAccess rechecks that on every call, so a role change takes effect at once. Added to the Crew mcp feature tools, Code's product.yaml allowlist and the Crew read-only deny list. The description and parameters moved to caplayerproduct.AccessToolDescription / AccessToolParameters() so both chats share one definition. Secret values never pass through it; secret grants stay in the Vault chat.
Left: deploy; check live that an administrator's Code, Crew and workflow chats list the tool and that a non-administrator's do not; then an agent doing the RTS case end to end. TestCodeSkillOptionsStayPrivateAndRefreshWithoutMutatingBuiltins fails on a clean origin/main as well (the code-mcp skill text), unrelated.
Owner decision: Vault is how people share MCPs, so a connection that already works in a Crew, Code or workflow (or a person's own store) can be promoted into Vault without a second sign-in. promote_place_connection {name, confirm} on manage_vault_access (agent_go/cmd/server/vault_promote.go): active Vault administrator only, only for a connection that person signed in, explicit confirm step; creates the Vault connection like connect_server (catalog first, custom URL as fallback), then re-seals the existing token, client registration and OAuth config for the new connection (token files are bound to their path, so they are read and rewritten, never copied); syncs tools; no group gets access; the personal connection is unchanged; logged as [VAULT_PROMOTE]. Providers that rotate refresh tokens may invalidate one copy. Secrets (promote_place_secret) are not built; the wider personal-vaults design is PLAT-507.
Left: check live on RTS with the owner's Notion connection: confirm step text, promote, tools discovered, no group access, then grant a group and see the tools from a second account.
Live test on RTS (workflow rtsprreviweer, Notion): both manage_my_vaults promote and manage_vault_access promote_place_connection failed at "create the Vault connection". Cause: the place connection's own catalog name is not a Vault catalog name, so the catalog create failed and the fallback created the connection from the bare URL, which makes the Vault service contact the server with no sign-in and Notion answers upstream initialize: transport error: authorization required. A catalog create does not contact the server. Fix: resolveVaultProvider finds the Vault catalog entry by the connection's URL (then by name) and uses it with no bare-URL fallback; Vault's own refusal text is now part of the error instead of a bare status (vaultServiceRequestAs). The earlier steps (finding the connection, reading its token) had passed in the logs.
Owner: no fallbacks. vaultCatalogProvider is strict: the connection's URL must match a Vault catalog entry, else the promote is refused with that reason; no bare-URL create and no name guessing.
Verified live (RTS, 2026-10-05 10:28 UTC, release 832f0ad): the owner promoted the rtsprreviweer workflow's Notion connection into a vault he owns; the server logged [VAULT_PROMOTE] creating Vault connection c-94acea49… with the existing sign-in and no error followed. Not yet checked: a second account in that vault seeing and using the Notion tools.
Auto-synced from docs/ on main. Edit there, not here.