Skip to content

Managed Agents: vault_ids not inherited by subagents dispatched via agent_toolset — MCP OAuth calls fail #1562

Description

@quinnborn

Summary

When a coordinator agent dispatches a subagent using the agent_toolset_20260401 tool, the vault credentials configured via vault_ids at sessions.create are not available to the subagent's execution context. Any MCP tool call in the subagent that requires OAuth credentials (e.g. a Dynamics 365 or Microsoft Graph MCP server) fails silently or returns an auth error.

The vault_ids parameter exists only on sessions.create. There is no mechanism to pass or inherit vault credentials when dispatching a subagent via agent_toolset_20260401, and the tool accepts no vault_ids parameter. This makes vault-backed MCP tools unusable in any multi-agent pattern where the tool call originates from a subagent rather than the coordinator.


Reproduction

import anthropic

client = anthropic.AsyncAnthropic()

# Session created with vault credentials for an MCP server
session = await client.beta.sessions.create(
    agent={"id": "<coordinator_agent_id>"},
    environment_id="<env_id>",
    vault_ids=["<vault_id>"],   # OAuth cred for https://example.com/mcp
)

# Coordinator dispatches a subagent via agent_toolset
# (subagent has the same MCP server in its agent definition)
await client.beta.sessions.events.send(
    session.id,
    events=[{
        "type": "user.message",
        "content": [{"type": "text", "text": "Run the pipeline"}],
    }],
)

# Coordinator → subagent → subagent calls MCP tool
# Result: agent.mcp_tool_result  →  is_error=True  (auth failure)
# The vault credential was never forwarded to the subagent's context

Observed: subagent MCP calls fail with auth errors. The coordinator's own MCP calls succeed with the same vault credential. The difference is execution context — subagent is isolated.

Confirmed: the same subagent works correctly when given its own sessions.create(vault_ids=[...]) call (manual multi-session orchestration). This is the only known workaround.


Expected behavior

One of the following:

  1. Subagents inherit vault credentials from the parent session — when a coordinator dispatches a subagent, the subagent's MCP calls use the same vault context. Least-surprise behavior.
  2. agent_toolset_20260401 accepts a vault_ids parameter — coordinator passes credentials explicitly when dispatching, allowing per-subagent scoping.
  3. agents.create / agents.update accepts vault references — credentials bound to the agent definition; any session referencing that agent gets vault access automatically.

Workaround

Manual multi-session orchestration — create a separate session for each agent with its own sessions.create(vault_ids=[...]). Orchestrate data flow between sessions in Python. This works but defeats the purpose of agent_toolset_20260401 and loses the unified event stream.


Why it matters

Vault credentials + managed agents is the documented secure pattern for connecting agents to external services. But the moment you introduce a coordinator/subagent split — which is the primary use case for agent_toolset_20260401 — vault-backed MCP tools stop working for all agents except the coordinator. Multi-agent pipelines that need to call external APIs from subagents are effectively blocked unless they abandon the managed-agents orchestration pattern entirely.


Environment

  • anthropic Python SDK (latest)
  • Beta header: managed-agents-2026-04-01
  • Models tested: claude-sonnet-4-6
  • MCP server type: url with OAuth credentials in vault
  • Vault credential type: OAuth (confirmed failing); static bearer untested

Verified what's missing

  • sessions.create body params — vault_ids present here only
  • agents.create / agents.update — no vault_ids parameter
  • agent_toolset_20260401 tool schema — no vault_ids parameter; no credential passthrough of any kind
  • Managed agents docs — vault_ids documented only at session level; no mention of subagent credential inheritance
  • Cookbook / quickstart examples — no example combining vault + multi-agent (agent_toolset)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions