How do security teams detect malicious MCP tools or agent skills?

They need two checks: review the instruction layer as a security artefact, then measure runtime behaviour against the declared work envelope. Code scanning alone is insufficient because the implementation may be benign while the description or tool intent is not.

How security teams separate malicious MCP tools from benign ones

Security teams should treat the tool description, instruction layer, and declared permissions as evidence, not marketing. The first pass is to review what the tool says it will do, what context it asks for, and whether that story is internally consistent. A tool can look harmless in code while its intent, prompts, or packaging are designed to abuse trust once an agent loads it.

That means detection starts before execution. The question is not only whether the implementation contains obvious malware, but whether the tool is trying to shape agent behaviour, solicit unnecessary access, or hide a capability that becomes dangerous when the agent follows it. A benign codebase can still be a malicious tool if the instruction surface is the real payload.

Teams should also treat the declared work envelope as a baseline for runtime comparison. If a skill claims to summarise tickets but starts requesting secrets, calling unexpected endpoints, or chaining actions that exceed its stated purpose, that is a strong signal of malicious intent or compromise. MCP Security Guide is useful here because it frames MCP authorisation, token handling, and tool poisoning as practical review points rather than abstract protocol issues.

Why runtime behaviour matters more than static inspection alone

Static scanning can prove a package is syntactically clean, but it cannot prove the tool is honest. Malicious MCP tools and agent skills often depend on the gap between declared purpose and observed behaviour, especially once the agent has context, tokens, or delegated access. Runtime signals such as unexpected network calls, privilege escalation attempts, secret requests, or cross-tool chaining are often more reliable than source code alone.

This is especially important for skills and tools that are loaded dynamically. The security team should compare observed actions against the tool’s intended work envelope, then ask whether the behaviour is necessary for the stated job. If the answer is no, the behaviour should be treated as suspicious even if the package passed code review. OWASP Agentic Skills Top 10 (AST10) gives a good lens for this because it focuses on malicious skills, permission inheritance, and credential exposure through skill chains.

The same logic applies when an MCP tool or skill is embedded in a broader agent workflow. The more the runtime can influence tool selection, permission use, or downstream delegation, the more important it becomes to measure actual behaviour against declared scope. That is what separates a normal integration from a deceptive one.

What strong detection looks like in practice

Good detection combines content review, behavioural telemetry, and access controls. Review the instruction layer as if it were executable policy, inspect the tool for hidden instructions or outbound calls, and then monitor whether the runtime matches the advertised function. Where possible, compare what the tool claims to need with what it actually requests at run time, especially if the request involves secrets, tokens, or broad workspace access.

Security teams should also look for signs of abuse patterns that recur across malicious tools: secret harvesting, token passthrough, unexpected delegation, hidden exfiltration, and command chaining that exceeds the stated task. Anthropic GTG-1002 AI espionage campaign is a useful reminder that autonomous tooling can be driven to harvest credentials at scale, while postmark-mcp malicious MCP server 2025 shows how a seemingly normal integration can quietly exfiltrate data through the function the agent is already trusted to use.

When the tool is designed for agentic use, the distinction between tool intent and tool effect matters. A skill may be technically valid and still operationally malicious if it induces the agent to overreach. That is why the highest-value signals are not only malware indicators, but also authority abuse, scope creep, and behaviour that diverges from the declared work envelope.

Risk and Threat Considerations

Malicious MCP tools and agent skills are risky because they exploit trust at the boundary between description and execution. The attacker does not need to win a traditional malware fight if the agent willingly loads the tool, grants it context, or follows its instructions into broader access than intended.

Failure mechanism: The tool’s instruction surface, package metadata, or runtime prompts misrepresent its intent, while the agent grants access, executes actions, or passes secrets that the declared task did not require. That creates a path for secret theft, unauthorized actions, or hidden exfiltration even when the binary or repository looks ordinary.

Impact: Compromise can spread through delegated authority, poisoned tool chains, and overbroad access reuse. The practical outcome is not just a bad plugin, but a trusted workflow that becomes an attacker-controlled action path.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10, OWASP Agentic AI Top 10, OWASP Agentic Skills Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API8 — Security Misconfiguration	MCP tools are exposed through runtime interfaces and trust boundaries that can be abused via misconfiguration.
Recommendation — Harden exposed tool interfaces and verify runtime access paths before allowing agent execution.
OWASP Agentic AI Top 10	ASI02 — Tool Misuse	The question is about detecting tools or skills that cause agents to perform unintended actions.
Recommendation — Inspect tools for misuse patterns and block capabilities that exceed the declared work envelope.
OWASP Agentic Skills Top 10	AST10 — Agentic Skills Top 10	Agent skills are the direct subject, especially malicious skills and permission inheritance.
Recommendation — Review skill registries for malicious content, overreach, and hidden credential exposure.
NIST SP 800-53 Rev 5	AU-6 — Audit Record Review, Analysis, and Reporting	Runtime detection depends on analyzing logs and behaviour against expected tool use.
Recommendation — Correlate agent actions with audit data to flag tool behaviour that exceeds declared scope.
MITRE ATT&CK	T1552 — Unsecured Credentials	Malicious tools often try to harvest or misuse secrets during execution.
Recommendation — Hunt for secret access, token theft, and credential misuse triggered by tool invocation.

Practitioner Guidance

What to prioritise: Put tool and skill review into the same control class as access review. If a tool can influence prompt context, token use, or downstream actions, it deserves pre-execution scrutiny and post-execution telemetry.

What to verify: Confirm that the tool’s declared purpose, requested permissions, and observed runtime behaviour all match. If the tool asks for broader access than its work envelope justifies, treat that mismatch as a detection signal, not a tuning issue.

Common mistake: Teams often over-trust static code review and underweight the instruction layer. For MCP and agent skills, the harmful behaviour may be in the instructions, the packaging, or the delegated context rather than in obvious malicious code.

Practitioner takeaway: The best detection posture is behavioural, not purely static, because malicious tools are often exposed by what they try to make the agent do, not by what the code visibly contains.