Skip to content

fix(mcp): let the MCP binding act as a real agent - #19

Closed
glatinone wants to merge 1 commit into
test/shared-app-statefrom
fix/mcp-agent-identity
Closed

glatinone wants to merge 1 commit into
test/shared-app-statefrom
fix/mcp-agent-identity

Conversation

@glatinone

Copy link
Copy Markdown
Owner

fix(mcp): let the MCP binding act as a real agent

Every access rule is decided from the caller's identity, and every MCP tool
hard-coded mcp_client. So every MCP client pointed at one store was the same
agent, with three consequences, one of them a security hole:

  • A cell one MCP client created was readable by all of them. created_by
    grants access to its creator, and the creator was the same synthetic id for
    everybody - so the per-cell access model was inert in this binding, which is the
    cross-agent leakage RFC-AMP-001 §5 lists as a threat.
  • readable_by naming a real agent id matched nothing. A caller passing it to
    amp_remember - the documented parameter - stored a cell its own server could
    not recall. That is the same root cause, and it makes the multi-agent use case
    the RFC cites for this binding unusable.
  • created_by recorded a name no agent uses, which is exactly the attribution
    §5 leans on to make a poisoned memory traceable.

AMP_MCP_AGENT_ID now supplies the identity, read per call rather than cached at
import, because the MCP client sets the environment when it spawns the process.
Unset, it falls back to the old name so nothing breaks - and the fallback is
documented as what it is: a shared namespace, not an identity.

Both places a user copies from now set it: the getting-started MCP snippet and
examples/mcp-claude-desktop/mcp_config.json. The release notes gained the
caveat next to the other honest limits.

Four tests, all of which fail on the old code: the configured id is what lands in
created_by, the default is used when nothing is configured, a cell restricted to
an agent is recallable when the server is that agent and invisible when it is
another, and amp_forget is gated on the same identity.

Every access rule is decided from the caller's identity, and every MCP tool
hard-coded `mcp_client`. So every MCP client pointed at one store *was* the same
agent, with three consequences, one of them a security hole:

- **A cell one MCP client created was readable by all of them.** `created_by`
  grants access to its creator, and the creator was the same synthetic id for
  everybody - so the per-cell access model was inert in this binding, which is the
  cross-agent leakage RFC-AMP-001 §5 lists as a threat.
- **`readable_by` naming a real agent id matched nothing.** A caller passing it to
  `amp_remember` - the documented parameter - stored a cell its own server could
  not recall. That is the same root cause, and it makes the multi-agent use case
  the RFC cites for this binding unusable.
- **`created_by` recorded a name no agent uses**, which is exactly the attribution
  §5 leans on to make a poisoned memory traceable.

`AMP_MCP_AGENT_ID` now supplies the identity, read per call rather than cached at
import, because the MCP client sets the environment when it spawns the process.
Unset, it falls back to the old name so nothing breaks - and the fallback is
documented as what it is: a shared namespace, not an identity.

Both places a user copies from now set it: the getting-started MCP snippet and
`examples/mcp-claude-desktop/mcp_config.json`. The release notes gained the
caveat next to the other honest limits.

Four tests, all of which fail on the old code: the configured id is what lands in
`created_by`, the default is used when nothing is configured, a cell restricted to
an agent is recallable when the server *is* that agent and invisible when it is
another, and `amp_forget` is gated on the same identity.
@glatinone

Copy link
Copy Markdown
Owner Author

Landed on master in the v0.1.0 chain: the branch was fast-forward merged as part of b940905..92b88ee and released as v0.1.0. Closing so the open list matches reality - the commits are in master, and the tag points at them.

@glatinone glatinone closed this Oct 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant