Threat definition
Tool discovery supplies model-facing names, descriptions, input schemas, annotations, and later outputs. A server or dependency can change these values to redirect behavior, hide effects, expand inputs, or inject instructions. Schema validity is not trust.
Trust boundary
Treat discovery as versioned supply-chain input. Pin or approve servers and tool identities. Normalize names from trusted transport context. Review semantic changes to descriptions and schemas. Keep authorization policy separate from model-readable text.
Validation and evidence
Validate arguments against a local expected contract and apply resource and action policy after parsing. Record server identity, tool identity, schema version or digest, requested arguments, policy result, target, and effect. Redact secrets.
Failure and residual risk
A compatible schema can change meaning. A tool can return prompt injection or false success. Name collisions can route policy to the wrong server. Dynamic discovery improves extensibility and increases change and approval risk.
Pomerium boundary
Pomerium can apply routed MCP method and tool-name policy for supported requests. It does not approve tool semantics, schema changes, annotations, output content, or local stdio discovery. The host and tool owner must validate those boundaries.
Evaluation checklist
- Which authenticated server and version own each discovered tool?
- Are name, description, schema, annotations, and output treated as untrusted input?
- Does local validation and policy bind arguments to a named resource and action?
- Can discovery changes trigger review and rollback?
- Does target evidence confirm the effect instead of trusting the tool response?
