Put portable workflow knowledge in documentation or skills that can travel with the model, and keep MCP focused on connected capabilities such as live system access, stateful orchestration, and execution boundaries. That separation makes review easier and reduces the chance that workflow logic gets mistaken for a security control.
Why portable instructions belong outside MCP
Skills-style instructions are best treated as portable operating knowledge: how a model should think, sequence work, use conventions, and present results. MCP is better reserved for capability access, where the system must touch live tools, APIs, files, or other stateful resources. That boundary keeps the instruction layer reusable while making the access layer easier to audit and govern.
When the two are mixed, teams often end up reviewing ordinary workflow guidance as if it were an access decision. Separating them lets reviewers ask different questions: is this instruction safe and clear, or does this connector actually grant a capability? For a practical model of how agentic systems change the risk surface, see the OWASP Agentic AI Top 10.
The same separation also prevents “documentation drift,” where a process note silently becomes a de facto control. If a workflow step matters because it changes what the model can do in a connected system, it belongs in MCP-bound capability design, not in a reusable skill that may travel across contexts.
What MCP should carry, and what it should not
MCP should hold the parts of the integration that are context-bound and enforceable: live system access, scoped tool invocation, execution boundaries, and any runtime authorization decisions. That is the layer where audience, transport, token handling, and downstream system reach matter. The MCP specification’s authorization model is a good reference point when you need to keep those boundaries explicit: Model Context Protocol: Authorization specification.
By contrast, MCP is usually the wrong place for reusable reasoning, templated analysis, checklists, or business logic that should survive a connector change. If that logic is portable, it is operational knowledge, not access policy. Keeping it outside the protocol reduces duplication and avoids the false impression that a workflow note has security significance just because it sits near a connector.
This is especially important when multiple tools expose similar actions. The protocol should describe how the model reaches a capability, while the skill should describe how to use the capability safely and consistently. That distinction becomes sharper in agentic systems, where tool misuse and identity or privilege abuse are separate failure modes from bad instructions.
How teams should draw the line in practice
A useful test is whether the content would still make sense if the connected system disappeared. If yes, it belongs in documentation or a portable skill. If the content only matters because it governs a live integration, it belongs in MCP or in the policy around that MCP deployment. That test is practical, because it forces teams to separate reusable knowledge from environment-specific authority.
Another way to frame it is by review ownership. Product, operations, and domain owners can maintain skills-style instructions as part of knowledge management, while platform or security owners review MCP access as an exposure decision. For implementation detail on how agentic systems handle skills and permissions, the OWASP Agentic Skills Top 10 (AST10) is a useful complement to the broader agent security guidance.
Where a workflow step includes credential use, resource selection, or audience restriction, treat that step as part of the capability boundary, not as a general skill. Where it is only describing sequence, style, or decision logic, keep it portable. That keeps the access layer small enough to reason about and the instruction layer broad enough to reuse.
Risk and Threat Considerations
Mixing portable instructions with MCP access creates two risks: reviewers may miss where authority actually changes, and an ordinary workflow note may be mistaken for a control. In agentic environments, that confusion can widen the blast radius of a connector, because a benign-looking instruction can sit beside a tool that reaches live data or executes actions.
Failure mechanism: Workflow logic, access boundaries, and runtime permissions get blended into one artifact, so changes to a skill can unintentionally alter how a connected capability is used or reviewed.
Impact: Teams may overtrust documentation, underreview connector scope, or allow a portable instruction to accumulate hidden operational authority, increasing the chance of misuse, privilege creep, or unsafe automation.
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 API Security 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 | Splitting skills from MCP limits unsafe tool use and unclear authority boundaries. |
| ASI03 — Identity & Privilege Abuse | MCP boundaries determine where agent authority and privilege actually change. | |
| ASI07 — Insecure Inter-Agent Communication | Capability routing and execution boundaries need explicit handling in connected agent systems. | |
| Recommendation — Separate reusable instructions from runtime tool access to reduce misuse and overreach. Treat MCP-scoped capabilities as privilege boundaries and review them separately from skills. Define clear interface boundaries so inter-agent or tool communication does not inherit excess trust. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP access should not accidentally expose functions beyond intended authority. |
| API2 — Broken Authentication | Connected capabilities depend on correct authentication and token handling. | |
| Recommendation — Restrict connector-exposed functions to the minimum authorized capability set. Verify that MCP-connected systems authenticate requests correctly and do not rely on ambiguous trust. | ||
Practitioner Guidance
What to verify: Before placing content in MCP, confirm that it truly governs live capability, state, or execution boundaries. If the content only tells the model how to work, keep it in the skill or documentation layer and review it as knowledge, not access.
Decision rule: If the content would still be useful after the tool, system, or tenant changes, do not bind it to MCP. If changing the connector would invalidate the logic, treat it as part of the access design and require tighter change control.
Practitioner takeaway: The cleanest design is not “more MCP,” it is clearer separation, portable instructions should stay portable, and anything that can change real system reach should be reviewed as access.
Related resources from NHI Mgmt Group
- When should organisations prioritise Zero Standing Privilege for non-human identities?
- How should security teams decide whether JIT access is safe for non-human identities?
- What is the difference between JIT access and Zero Trust for NHIs?
- How should organizations prioritize security in their MCP implementations?