Multi-Agent Systems: Sharing Context Without Sharing Credentials

One release, three different sets of permissions

Consider a release coordinator that asks a researcher to inspect deployment notes, a reviewer to compare the proposed change with policy, and an executor to update a release ticket. All three need the release identifier, acceptance criteria and relevant decisions. Only the executor needs ticket-write access. None needs the ticket system’s upstream OAuth refresh token in its prompt, working directory or handoff message.

Design the permissions around those assignments. The researcher reads selected notes and returns findings. The reviewer reads those findings and the applicable policy, then returns objections. The executor receives a reviewed proposal and can change the designated system. The coordinator tracks completion without distributing its own credential to every worker.

Shared context still needs an audience. A deployment note containing customer information may be appropriate for the reviewer but unnecessary for the executor. Start with the smallest common release record, then let each agent retrieve additional evidence through its own authorized connection. Sharing a workspace should not automatically mean sharing every retrieved document.

A separate conversation is not a separate identity

Anthropic’s Claude Code documentation describes subagents with their own context windows and configurable tool access. It also documents that a subagent referencing an existing MCP server by name shares the parent session’s connection. That distinction matters: a researcher can have a clean conversation while its remote calls still use the same connection as the coordinator.

Before treating a worker as a separate security principal, determine which credential actually reaches the server. A tool allowlist can constrain the harness, but it does not by itself issue a different server-side credential. Likewise, naming a worker reviewer in a prompt or request argument does not establish its identity.

For independently revocable workers, provision separate credentials and run them in environments that cannot read one another’s secrets. Separate processes alone are insufficient if every process can inspect the same environment files or credential store. When a harness cannot provide the required separation, treat its subagents as one authorization principal and reserve stronger boundaries for independently isolated sessions. See one scoped key per agent for the credential inventory behind that design.

Make the handoff an evidence record

Anthropic’s context-engineering guidance describes specialized agents returning condensed findings while detailed exploration remains in their own contexts. Apply that pattern to the release workflow: send the decision-relevant evidence, its origin and unresolved questions. Copying the researcher’s entire transcript would also copy irrelevant tool output and potentially data the recipient should never receive.

A useful handoff identifies the release and assigned task, cites the source document and revision, separates observations from recommendations, and records what remains unverified. Store the approved deployment decision separately from a worker’s proposed amendment. If two reviewers disagree, retain both findings until the coordinator resolves them rather than allowing the last memory write to become policy.

Authorize the resulting artifact for its intended readers. A summary of a restricted incident report can expose the same sensitive facts as the report itself. An artifact identifier should lead to another access check; avoid treating possession of the identifier as permission to retrieve it. Keep passwords, bearer tokens, authorization headers and secret-bearing URLs out of these records. For the distinction between personal and common knowledge, see team memory versus personal memory.

Share the MCP configuration, inject a different credential

Claude Code supports project configuration in .mcp.json and environment-variable expansion in HTTP headers. For independently isolated Claude Code workers, the same configuration can reference a different credential in each worker’s environment:

{
  "mcpServers": {
    "company": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${RELEASE_WORKER_MCP_TOKEN}"
      }
    }
  }
}

The example endpoint is illustrative. The launcher supplies RELEASE_WORKER_MCP_TOKEN through the worker’s secret mechanism before starting Claude Code. The researcher receives a credential permitting its required reads; the executor receives a different credential permitting the required ticket operations. The variable name and checked-in configuration can match across workers. Their credential values and grants differ.

Environment substitution avoids committing a literal token; it does not protect a token from a worker that can inspect its own environment. Keep that credential narrowly scoped. For OAuth-protected MCP connections, the MCP authorization specification requires tokens intended for that MCP server and rejects accepting or forwarding unrelated tokens. Authenticate the agent to the connection layer separately from the connection layer’s upstream authentication.

Enforce source, operation and object restrictions at the service handling the call. Removing a write tool from discovery is insufficient if a direct invocation with the researcher’s credential still succeeds.

Validate requests that cross into a privileged worker

The coordinator becomes a dangerous shortcut if it accepts a worker message such as “publish this release” and executes it using broader privileges. Treat that message as a proposal. Check the authenticated sender, assigned release, requested operation, target object and required approval before invoking the write. A worker-supplied claim that approval already happened is evidence to verify, not an authorization decision.

For the ticket update, bind approval to the ticket identifier and exact proposed content. If the executor changes the target or body after review, require another decision. Return a bounded result to the coordinator: which object changed, the outcome and a reference for inspection. Do not return the executor’s connection material.

Apply the same discipline to shared memory. A researcher may propose a release finding without permission to overwrite the team’s deployment procedure. Give persistent context writes their own grant and review path. Treat recalled observations as recorded data, and review shared skills as executable guidance. Otherwise, an untrusted note can steer the executor even though the note contains no credentials.

Where SPYN3 fits

SPYN3 provides one MCP endpoint per workspace. Upstream credentials remain envelope-encrypted in the workspace; agents hold SPYN3 credentials. Keys can be scoped to chosen sources, with call:tools for upstream-marked read-only tools and separate call:write_tools for writes. Opt-in memory and skills use context tools; memory writes require write:memory, and recalled memory is labelled as recorded data. Personal memory follows the calling person, not a distinct namespace per agent key. Start by giving the researcher a separate key without write grants. Revocation takes effect on the next call.

Test the collaboration through its denied actions

Exercise the release workflow with the real worker credentials in a test environment. Successful collaboration should include predictable refusals:

• Both reviewers can read the approved common release record, while a restricted incident document and its derived summary remain unavailable to an unauthorized worker.
• The researcher can retrieve its evidence but cannot update a ticket, invoke an undisclosed write directly, or overwrite the shared deployment procedure.
• The executor rejects a proposal for another release and a ticket body changed after approval, even when the coordinator forwards it.
• Revoking the researcher’s credential blocks its next protected request while the reviewer continues with its own credential.
• Handoff artifacts and persisted notes contain the evidence needed for review without authorization headers or upstream secrets.

Inspect the server’s recorded caller for each operation. If every call resolves to the coordinator’s credential, separate worker names have not produced separate attribution. If a denied worker can obtain a privileged result by asking another agent, the delegation boundary remains open. Resolve those failures before expanding the number of workers or the authority of the executor.