Teams often inspect only one layer, either the package code or the natural language instructions. That misses the other half of the risk. Skills can persuade an agent through prompts while scripts carry out the action, and MCP servers can expose tool descriptions, returned content, and authentication paths. Effective review must cover the full package and its runtime context.
Where reviewers miss the real attack surface
The most common mistake is treating mcp server review as either a code audit or a prompt review. A server can look clean in source while still exposing risky tool descriptions, weak return paths, or overbroad authentication handling at runtime. Skills create a different blind spot: the natural-language layer can steer the agent into actions that the underlying script then executes without further judgment. That means the review has to follow the whole chain from instruction to execution, not just whichever layer is easiest to inspect.
That matters because MCP shifts security decisions into places teams often under-review: tool exposure, permission boundaries, and how the agent interprets returned content. The risk is not only malicious code, it is also persuasive text that changes what the agent chooses to do. In practice, many teams discover the dangerous path only after the agent has already combined a harmless-looking instruction with a legitimate tool call.
For a useful baseline on why this surface is hard to control, The State of MCP Server Security 2025 found that only 18% of deployments implement any form of access scoping for tool permissions.
How the review should actually work
Effective review starts by separating three things: the skill text, the executable logic, and the runtime context the agent will see when it calls the server. If reviewers only inspect one of those layers, they miss the interaction effects that create most of the risk. The instruction may be benign in isolation, while the tool output, metadata, or auth path makes it dangerous when the agent reasons over it.
- Read the skill as an influence mechanism, not just documentation. Ask what it could persuade the agent to request, reveal, or execute.
- Inspect the package or server code for exposed tools, argument handling, token usage, and any place where returned content can alter later decisions.
- Review the auth path and permission scoping separately from the code path. A secure-looking implementation is weak if every tool shares the same broad access.
- Test the runtime conversation, because the real issue is often what the agent does after reading a tool description or tool result.
That runtime check matters especially when a tool returns content that is later treated as trusted context. Once the agent accepts that content, the line between “information” and “instruction” can blur, and reviewers who never exercised the full flow will miss the exploit path entirely. This is where teams also underestimate indirect exposure, such as a tool that discloses environment details that make later abuse easier.
These controls tend to break down when the agent can chain multiple tools together, because the unsafe outcome only appears after several individually acceptable steps.
Common edge cases teams underestimate
Tighter review often increases friction, so teams have to balance developer speed against the cost of missing a cross-layer failure. The sharpest edge cases are not the obvious malicious packages, but the ordinary ones that gain dangerous behavior through composition.
One common example is a skill that appears harmless because it only gives guidance, while the underlying script is what actually performs the action. Another is an MCP server that exposes a narrow tool but returns rich data that the agent then uses as an untrusted shortcut. A third is brittle authentication design, where the tool works only because it inherits a broad session or token context that reviewers never verified.
Current guidance suggests treating any package with both instruction and execution components as a single security object. Reviewers should also be careful with “safe by interface” assumptions, because an interface can look narrow while still carrying broad privilege through its backend connection. The practical question is not whether the package contains code, but whether the code, prompt, and runtime context together create a wider blast radius than any one layer suggests.
Teams also get this wrong in environments where the agent is allowed to browse, retrieve, and act in the same session, because the review surface expands from static content to live decision-making. In those environments, a partially reviewed MCP server is usually more dangerous than a clearly broken one, because it inspires false confidence.
Risk and Threat Considerations
The material risk is cross-layer abuse of trust, where a persuasive skill or exposed MCP tool path causes the agent to take actions beyond what the reviewer expected. That creates exposure in authorization, data handling, and downstream action execution, even when no single component looks overtly malicious.
Failure mechanism: the attacker or unsafe package relies on the reviewer separating prompt logic from executable logic. The skill can steer the agent toward a tool call, while the tool description, returned content, or auth context supplies the actual path to data exposure or unintended action. Once the agent treats tool output as trusted context, the package can drive behavior that bypasses human intent.
Impact: teams may approve tools that can reveal sensitive data, trigger unauthorized actions, or widen access through inherited credentials and permissions. The result is usually not one obvious compromise point, but a chain of small review misses that combine into a material control failure.
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 address the attack and risk surface, while NIST AI RMF and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 — Prompt Injection / Instruction Hijacking | Skills can steer agent behavior through natural-language instructions. |
| A5 — Tool Misuse / Unauthorized Actions | MCP tools can be abused when descriptions and outputs shape agent actions. | |
| A7 — Identity, Authorization and Privilege | MCP review must cover auth paths and permission boundaries at runtime. | |
| Recommendation — Test skill text for instruction hijacking paths before allowing execution. Review tool exposure and constrain actions the agent can invoke. Verify agent authorization is narrowly scoped to each tool and action. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Exposure | MCP servers may expose credentials through configs or returned content. |
| NHI-05 — Overprivileged Non-Human Identities | MCP runtime access can inherit broader privileges than reviewers expect. | |
| Recommendation — Scan packages and configs for exposed secrets before approving deployment. Enforce least privilege on the identities used by MCP servers and tools. | ||
| NIST AI RMF | GV-2 — AI Governance, Policies, and Procedures | Agent and skill reviews need governance over decision boundaries and approvals. |
| MAP-1 — Map AI System Context and Use | The question is about mapping how skills, tools, and context interact. | |
| Recommendation — Define review policy for instruction, tool, and runtime-context changes. Document the full agent, tool, and context flow before risk decisions. | ||
| CIS Controls v8 | 6 — Access Control Management | MCP server review hinges on scoped permissions and controlled access paths. |
| Recommendation — Limit tool and backend access to the minimum required for each function. | ||
Practitioner Guidance
What to prioritise: Review the instruction layer and the executable layer together, then validate the runtime flow with realistic agent inputs. If either layer can change the agent’s action set, it deserves full review before release.
What to verify: Confirm which tool descriptions are visible to the agent, what returned content is trusted as follow-on context, and whether authentication or permission scope is narrower than the underlying backend access. The control is only meaningful if those three align.
Common mistake: Treating “the code passed review” as sufficient when the skill text can still redirect the agent into misuse. The fastest way to miss the real risk is to review each layer in isolation.
Practitioner takeaway: The safest review posture is to assume the agent will combine every exposed instruction, tool description, and runtime result into one decision path, so the security question is whether that whole path is bounded, observable, and truly least privilege.
