Threat modeling starts with a protected asset, an attacker-controlled input and an action the agent can take. The scenarios here are illustrative. They do not assert that a named vendor or package is compromised.
A trusted package changes upstream
Scenario: an admitted skill fetches a mutable script during execution. The initial reviewer never sees the later revision. Review the complete update chain, including remote instructions, package registries and transitive dependencies. Prefer repeatable installation from reviewed revisions, inspect changes, and maintain a way to roll back or disable the capability. Publisher reputation and signatures help establish origin; they cannot prove that the content is harmless. [Source 2]
A document redirects the workflow
Scenario: an agent reads a supplier document that tells it to export a private customer list. The document has no authority to grant that action. Keep untrusted content separate from instructions and apply policy checks at the data and tool boundaries. A content classifier can contribute a signal but should not become the sole gate for consequential actions. [Source 3]
A broad credential becomes a bridge
Scenario: a capability needs one project but receives an organization-wide token. An unrelated resource becomes reachable when the tool accepts a different identifier. Limit the credential and verify object-level authorization. The official MCP guidance forbids accepting tokens that were not issued for the MCP server and warns against token passthrough. [Source 1]
A permitted network call leaks data
Scenario: an approved tool can read confidential content and contact arbitrary hosts. A seemingly ordinary request can carry data outside its permitted boundary. Constrain destinations, inspect outbound content where appropriate, and require explicit policy for redirects and uploads. Consider the combined permissions across tools, not only each tool in isolation.
A local server inherits workstation access
Scenario: an MCP server launched as a local process can reach files and network resources available to that process. The protocol does not itself create a sandbox. Limit execution privileges and review launch commands. Official MCP guidance explicitly addresses local server compromise and recommends restricted execution environments. [Source 1]
An apparently safe result outlives its evidence
Scenario: a reviewer approves version A and operators later use version B with different scopes. Preserve the reviewed artifact, the decision, the scope and the expiry. Re-review when versions, publishers, credentials, network access or intended data change. Approval applies to the reviewed conditions, not to a product name indefinitely.