The new boundary is tool discovery
After startup the agent asks the server what tools it has. That reply is the capability set for the task. Add one item to the list and you add one capability — without changing business code or shipping a release.
MCP security · discovery, permissions, supply chainCHENGDU, CN / 2026
MCP is not a plugin.
It is a new execution plane.
MCP lets an agent discover tools at runtime, carry context and call local or remote services. For engineering, it feels like a universal connector. For security, the enterprise attack surface gains a layer gateways never see: the tool catalog. If review still stops at “this model vendor is on the approved list,” you miss the end that actually executes. Yofune Labs folds MCP server testing into a standardized AI agent security assessment: provenance, where credentials land, and whether the tool list can grow at runtime. KUROSHIO is the validation engine that leaves reviewable discovery and call evidence.
Who this page is for
- Platform and integration teams wiring internal search, tickets or repositories into agents
- Security and supply-chain owners who must approve third-party or public-registry MCP servers
- AppSec, red teams and CISO offices that need to prove MCP permissions do not exceed the task
01The problem
The problem
Connecting an internal system used to mean application, account, network and API review. A single MCP configuration can now finish discovery, authentication and invocation at once. Capability no longer lives only in business code; it lives in the tool list the server declares on the spot.
Review stops at the model vendor
Having a model provider on the list does not mean the execution side is controlled. What actually reaches internal systems is often the MCP process, the token it holds and functions that appear only at runtime.
An official-looking name is not a controlled release channel
Convenient servers from public catalogs move quickly from a developer laptop into an internal trial. Same name, different implementation: the agent only sees that the tool list changed.
MCP embeds a third-party runtime in the agent
Discovery trusts what the server declares, not an interface list the enterprise already reviewed. If the server says it can export, the model may take that as fact.
02The risk
The risk
The key is still valid; the door has changed. A wrong address in development, one line in a config repo, a new version of a same-name package, poisoned internal DNS — the result is the same. Business systems need not be breached for data to leave where it belongs.
Same name, different permission boundary
The search MCP is still called internal-search, but the tool list now includes an export. Once the search credential can also drive export, swapping the server merely turns that capability on.
Credentials follow the tool chain
To make search useful, teams often hand internal API tokens straight to the MCP process. Whoever can change the MCP can use that token. Least privilege sits on the server, not with the agent.
A hot-updated tool list is an unreviewed permission change
A well-intended version bump can widen the attack surface just as much. Adding or removing a tool should go through permission change review, not through the model adapting after a hot reload.
Return values enter the next turn
If a tool result contains secrets or personal data, the next turn may send them back to the model or into another tool’s arguments.
Third-party MCP is a supply-chain problem
Source, update channel, data residency and where crash logs go should be asked as you would of a new integration. An MCP whose provenance you cannot explain is unauthorized software.
03How we test
How we test
MCP security testing is not another host scan. It follows task playbooks: which functions were actually registered, where credentials landed, and whether discovery itself can be approved. Yofune Labs brings that layer into a standardized AI agent security assessment. KUROSHIO handles planning, exploration, tool calls and evidence.
- 01
Confirm provenance before capability
Who maintains the server, how the image or binary is pinned, who approves updates. Put MCP on the asset inventory, in the same class as third-party CI actions and production sidecars.
- 02
List the real tool table after startup
For each function: read or write, outbound, command execution, secret access. A brochure that says “search plugin” is not enough. Archive the functions that actually registered.
- 03
Issue credentials per tool, not per server
Deal cards to the task; do not hand the server a master key. A search token must not export, delete or administer, and must not be reused across workspaces.
- 04
Treat discovery and calls as audit objects
Afterwards you should be able to say which tools the model saw, who provided them, where arguments came from, whether external text could fill them, and whether records line up with user and task.
- 05
Validate swap and drift in a controlled playbook
In an authorized isolated environment, watch whether a same-name service, a tool-list change or a version bump widens permissions. KUROSHIO records the path and whether policy blocked it — not destruction of production data.
05What you receive
What you receive
When the assessment ends, someone who did not build the stack should still see where data enters, where it leaves and which key is too broad. A demo without evidence does not count as complete.
MCP asset and trust-boundary diagram
Models, agents, MCP servers, accounts, external inputs and internal systems on one picture, with provenance, runtime location and data residency marked.
Tool list versus permissions
Registered functions, read/write and outbound attributes, credentials held, and whether they exceed the current task description. The hot-update channel is called out on its own.
Supply-chain and provenance findings
Maintainer, how versions are pinned, who approves updates, public-registry risk. Anything whose source you cannot explain is written as a launch blocker.
Attack paths and validation evidence
Which discovery or swap, which tool call, which result. Includes an input digest, tool request and response, and whether policy intercepted — reviewable by a third person.
Remediation and retest
Pin source and version, send tool-list changes through approval, trim credentials per tool, complete discovery and call logs. Walk the same path again on items already fixed.
Management summary
Within two pages: which MCP servers were in scope, the three things that matter most, suggested launch conditions. KUROSHIO owns the evidence segment, not the launch decision.
06How the assessment runs
How the assessment runs
KUROSHIO is the validation engine for planning, exploration, tool calls and evidence. Scope and the go-live decision stay with you.
- 01Collect assets: MCP provenance, version, install approval, runtime location and where credentials land
- 02List the tool table: registered functions, read/write and outbound, checked against the task
- 03Run controlled playbooks: search, export tendency, source swap, tool-list change
- 04Hand over evidence and launch conditions: pinned versions, approved changes, trimmed credentials, retest
Explore the KUROSHIO workspace
Switch between Scope, Explore, Validate and Report in an interactive workspace. See how authorized scope, task orchestration, linked evidence and a report summary fit together, using sample data to illustrate a general assessment workflow.
07Questions
Before you start.
01How is MCP security testing different from API review?
API review looks at interfaces already registered. An MCP capability table comes from runtime discovery; a server can add or remove tools without changing business code. Testing has to face the functions that actually registered, the credentials and the update channel — not a landing page that says “search plugin.”
02Can we give production agents an MCP from a public catalog?
Not on the name alone. You should be able to name the maintainer, how versions are pinned, data residency, credential scope and how to exit. If provenance is unclear, treat it as unauthorized software. The assessment writes those conditions as launch gates instead of bolting on a firewall afterwards.
03Will you run destructive operations against our production MCP?
A standardized assessment stays inside written authorization. High-impact actions such as export, delete and outbound calls are validated in isolation or read-only by default; write operations are agreed in advance. KUROSHIO records the call request and whether policy blocked it. It does not destroy production data.
Assess MCP as a new integration layer.
Yofune Labs offers a standardized AI agent security assessment. MCP security is the execution plane inside it: provenance, permissions, the tool list and call evidence. KUROSHIO is the validation engine that turns discovery into a path you can review. Start with the server you are connecting now.