MCP Cross-Server Tool Shadowing: Name Collision Signals

What 1-SEC checks

Tool-integrity state tracks the reported server for a known tool name. A later same-name tool reported from another server can trigger a shadowing observation. This is distinct from checking whether description text contains malicious instructions.

Read the implementation: Analyze

Required telemetry and context

Relevant input events: tool_register, tool_update, mcp_tool_list. Use a trusted producer at the real application boundary.

• tool_name
• server_name
• description
• description_hash

Field names above describe relevant context, not a complete API request. Consult the current event contract for envelope and detail requirements. Preserve booleans, numbers, and strings as the receiving handler expects them. Agent-provided text cannot independently verify identity or authorization.

Deployment, prevention, and response

Use stable server identities and namespace tools in the actual client/gateway. Preserve the old and new tool definitions and review whether a legitimate migration explains the collision. Do not silently switch execution targets merely because a description looks familiar.

Record the source event, affected agent/host, actual target, policy decision, and response result. Review enforcement configuration separately from detection. A recommendation, selected action, dry-run record, and completed action are different outcomes.

Reproduce the source fixtures

From a checkout of the linked 1-SEC source revision, run the selected fixtures with the repository's Go toolchain. These commands run tests; they do not execute a real attack against your systems.

go test ./internal/modules/aicontainment -run '^(TestToolIntegrity_Shadowing|TestToolIntegrity_CleanDescription)$' -count=1

The referenced source fixtures ran in the selected local package suites. Helper tests and synthetic events establish only the assertions shown, not production prevention or framework compatibility.

func TestToolIntegrity_Shadowing(t *testing.T) {
	tm := NewToolIntegrityMonitor()

	// Register tool from server1
	tm.Analyze("read_file", "Reads a file", "trusted_server", "hash1")

	// Same tool name from different server = shadowing
	result := tm.Analyze("read_file", "Also reads a file", "untrusted_server", "hash2")
	if !result.Shadowing {
		t.Error("expected Shadowing=true when same tool name from different server")
	}
}

// ─── GoalHijackMonitor (ASI01) ────────────────────────────────────────────────

func TestToolIntegrity_CleanDescription(t *testing.T) {
	tm := NewToolIntegrityMonitor()
	clean := []string{
		"Adds two numbers and returns the sum",
		"Reads a file from the specified path and returns its contents",
		"Searches the database for matching records",
		"Sends an HTTP request to the specified URL",
	}
	for _, desc := range clean {
		result := tm.Analyze("clean_tool", desc, "server1", "hash1")
		if result.Poisoned {
			t.Errorf("expected Poisoned=false for clean description: %s", desc)
		}
	}
}

Tuning, evaluation, and coverage limits

A name collision is a signal to review, not proof that one server is malicious. The detector relies on trustworthy server identity labels supplied by the client and bounded in-memory state. It does not create tool namespaces or choose a trusted implementation for the caller.

Evaluate this behavior with representative authorized activity and a controlled known-positive case. Investigate the exact rule, inputs, and state before suppressing an alert. Do not assume a hard-coded heuristic is a configurable setting. Measure your own deployment; the source fixtures do not establish a benchmark, detection rate, compliance certification, or incident-prevention claim.