The trust model breaks because the component can look legitimate at install time while still carrying prompt injection, typosquatting or secret-exfiltration behaviour at runtime. That turns a simple software dependency into an active control path inside the agent workflow. Security teams need to evaluate what the tool can do, not just who published it.
When Trusting an MCP Server Becomes a Security Assumption
The break is not just that an extension may be malicious. It is that install-time trust stops being a meaningful control when the component can change the agent’s behaviour after deployment, use hidden prompts or data flows, and act inside the same workflow boundary as approved tools. The security question shifts from publisher reputation to runtime capability, inspection, and containment.
A trusted mcp server or extension can therefore become a control plane, not a passive dependency. If it can receive user context, influence prompts, call tools, or forward secrets, then the agent inherits that component’s behaviour unless the platform constrains what it may observe and do.
That is why behavioural inspection matters more than catalogue trust alone. The relevant question is whether the component can be observed, restricted, and revoked with the same rigor as any other privileged integration. For MCP-specific authorisation and token handling, the Model Context Protocol: Authorization specification is the clearest external reference for how servers should handle access without relying on unsafe token passthrough, while the MCP Security Guide covers the practical trust boundaries practitioners need to design around.
What Behavioural Risk Changes After Installation
The dangerous part is runtime intent mismatch. A server or extension may look legitimate during review, but later inject prompts, alter outputs, exfiltrate secrets, or quietly broaden the agent’s action surface. That is a different failure mode from a broken package, because the component can remain functional while still steering the workflow toward unsafe outcomes.
Behavioural inspection is meant to catch the parts that static provenance checks miss: whether the tool rewrites instructions, accesses data it should not need, or behaves differently when it sees sensitive context. The issue is especially acute where tool calls are chained, because one compromised integration can become a bridge into other systems the agent is already allowed to reach. The OWASP Agentic AI Top 10 is useful here because it frames tool misuse, identity and privilege abuse, and supply-chain exposure as distinct classes of agent risk.
For MCP ecosystems, installation trust is also weakened by dependency disguise. A package may be published under a plausible name, or it may present a safe-looking interface while the runtime behaviour is designed to collect secrets or manipulate prompts. The postmark-mcp malicious MCP server 2025 case shows why the observable behaviour of the server matters more than the label attached to it.
How Security Teams Should Treat MCP Servers and Extensions
Teams should treat these components as active integrations with delegated authority, not as ordinary software packages. That means evaluating what they can read, what they can trigger, which secrets they can reach, and whether their permissions are bounded tightly enough to survive compromise or hidden functionality.
Behavioural inspection works best when paired with least privilege, scoped credentials, and revocation that is fast enough to matter operationally. If an extension can influence prompts and reach production tools, then the approval decision should include blast radius, isolation boundaries, and the ability to disable the component without breaking the rest of the workflow. NHIMG’s AI Agent Identity Security: The 2026 Deployment Guide is relevant because it connects delegated authority to short-lived credentials and task-scoped access, while the AI Agent Observability, Audit and Incident Response Guide helps teams decide what to log, attribute, and revoke when behaviour changes after deployment.
When the supply chain itself is part of the risk, provenance alone is not enough. The extension or server should be tested for what it does with prompts, tokens, and downstream tool calls, and the organisation should be prepared to quarantine it if its runtime behaviour exceeds the declared function. A broader supply-chain view is also covered in the AI Supply Chain Security and AI-BOM Guide, which is useful when the question is not just “who shipped it?” but “what did we actually place into the agent path?”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP tools can be abused to steer agent actions and exfiltrate data. |
| ASI03 — Identity & Privilege Abuse | Trusted extensions can escalate delegated authority inside agent workflows. | |
| Recommendation — Constrain tool permissions and inspect tool behaviour before granting agent access. Enforce least privilege and separate agent authority from extension capability. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party MCP components can introduce hidden malicious behaviour. |
| NHI-02 — Secret Leakage | Malicious servers can expose tokens or other secrets at runtime. | |
| NHI-05 — Overprivileged NHI | Trusted components often fail when they are granted broader access than needed. | |
| Recommendation — Assess third-party integrations for hidden behaviour and supplier risk before approval. Scan integrations for secret access paths and block unnecessary credential exposure. Minimise delegated permissions and revoke any excess access immediately. | ||
Practitioner Guidance
What to prioritise: Prioritise behavioural controls before broad rollout. If an MCP server can see sensitive context or call privileged tools, treat that as a high-risk integration until it has been observed under representative workloads.
What to verify: Verify that the component’s declared purpose matches its observed runtime behaviour, especially around prompt handling, secret access, outbound calls, and hidden tool invocation. If the runtime behaviour is broader than the declared need, constrain or remove it.
Common mistake: Do not confuse code review or publisher trust with runtime safety. A component can be reputable, signed, and still become unsafe once it is allowed into the agent’s control path with excessive reach.
Practitioner takeaway: The control objective is not to trust software less, but to trust it conditionally, based on observed behaviour, bounded privilege, and rapid revocation when the component’s actual actions diverge from its expected role.
Related resources from NHI Mgmt Group
- What breaks when developers expose an MCP server publicly without lifecycle review?
- What breaks when a Kubernetes-hosted MCP server is exposed through a tunnel without scoped authorization?
- What breaks when sensitive data is allowed to flow from Zapier MCP into an AI model without inspection?
- What breaks when Teams MCP access is granted without content inspection or write controls?