Which protections have shipped, and which are in development?
v0.4.6 is the published desktop alpha. The October 9 hardening described here is tested development work and is not included in those downloads. Arynwood MCP is one owner's local creative workspace with supervised automation. Its experimental remote-control gateway remains off by default.
The published security posture includes exact-call approval for destructive and publishing agent tool calls, untrusted-data framing, and exact Host and browser Origin validation. Read the v0.4.6 release notes and security policy for the baseline and documented limits.
What are six practical MCP security risks?
Tool poisoning, schema poisoning, tool shadowing, command injection, shadow servers and context oversharing affect different parts of an AI tool workflow. Each needs a control at the point where data becomes an instruction or an action.
| Risk | What can go wrong? | Control and boundary |
|---|---|---|
| Tool poisoning | A description or result tries to steer the model into an unauthorized action. | Results are framed as untrusted data. Development adds live definition rechecks. Neither proves that a server's behavior matches its description. |
| Schema poisoning | A parameter definition changes, or a call violates its constraints. | Development validates arguments with JSON Schema and detects definition changes. External schema retrieval is disabled. A malicious first schema still needs review. |
| Tool shadowing | A duplicate name redirects a call to another tool. | Existing dispatch binds names to one selected server. Development rejects duplicate names within a server catalog. Cross-server clashes retain the first registration. |
| Command injection | Input changes what a subprocess executes. | Source-only developer tools constrain subprocesses. No new shell runner was added in this work. Application checks and timeouts are not an OS sandbox. |
| Shadow servers | An unexpected server or changed endpoint receives a tool call. | Calls use the owner's registry and selected server. Development refuses changed or removed registration before dispatch. Configuration binding is not server attestation. |
| Context oversharing | Credentials appear in model context or stored execution evidence. | Development redacts common credential keys and token patterns in tool context and evidence. Arbitrary secrets can evade pattern matching; an enforced egress policy remains absent. |
What does human approval authorize?
One approval authorizes one exact agent tool call, once, before it expires. The existing grant binds the caller, server configuration, tool, arguments, schema and policy tier. Changed arguments require a new review. A timeout or unavailable approver denies a destructive or publishing call.
The development changes also bind discovered tool metadata. A fresh server catalog is checked before execution, and a changed definition prevents dispatch. Manifest annotations and a client-supplied approved flag cannot grant execution permission. The MCP tools specification treats annotations from untrusted servers as untrusted and recommends human oversight.
Can a pinned tool definition guarantee safety?
No. A definition snapshot detects advertised changes; it cannot inspect the server's implementation. The development check compares the discovered metadata with a fresh tools/list response, rather than comparing a stored copy with itself. Snapshots last for the turn or call, not across restarts.
A server can advertise the same definition while changing its behavior. Selecting tools for a turn also does not create an authenticated per-agent identity system. Keep server trust, execution permissions and the data a model receives as separate decisions.
How were these security changes tested?
The October 9 development checkout passed 735 backend tests, with 39 live-model evaluation tests excluded. The run reported one Starlette deprecation warning. Tests used disposable data fixtures and mocked model and MCP responses; they were not a penetration test or a packaged-release certification.
Regression coverage included definition changes during approval, removed tools, duplicate names, approval replay, changed server configuration, nested argument constraints, blocked external schema references and credential redaction. The configuration report retained four warnings and returned release_ready=false.
Frontend, packaged-client, live-model, GPU and publishing checks were not run for this backend change. The additions remain unreleased development work. Test counts describe this checkout, not the v0.4.6 release.
Is Arynwood MCP ready for shared or internet-facing use?
No. Its stated scope remains one owner on one machine. There is no OS sandbox or enforced offline mode. Direct owner-action APIs, including studio, deployment and social actions, are outside the MCP agent approval grant. Local-first operation does not mean that no data can leave the machine.
For deployment decisions, consult the public security policy and known limits alongside the official MCP security guidance. Report suspected vulnerabilities privately to [email protected].
Where can you check the sources and release status?
- Arynwood MCP security policy: the public baseline and documented gaps.
- Arynwood MCP v0.4.6 release: the published downloads, separate from this development brief.
- MCP tools specification: tool definitions, schemas, annotations and human oversight.
- MCP security best practices: protocol-specific trust and authorization risks.
This brief was prepared with AI assistance from Arynwood's source review and recorded test results. External specifications provide context; they do not certify Arynwood. Published October 9, 2026.