Which protections have shipped in 0.5.4?
v0.5.4 is the official latest desktop alpha. The October 9 hardening described here is included in these 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.5.4 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. Version 0.5.4 includes 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. | Version 0.5.4 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. Version 0.5.4 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. Version 0.5.4 refuses changed or removed registration before dispatch. Configuration binding is not server attestation. |
| Context oversharing | Credentials appear in model context or stored execution evidence. | Version 0.5.4 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 hardening included in 0.5.4 binds 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 0.5.4 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 local 0.5.4 default backend suite passed 899 tests, with one skip and 39 live-model evaluations excluded; all 290 frontend tests passed. Required CI, Windows packaging and frozen-backend smoke checks passed. Official package hashes, versions and GitHub attestations were verified before the owner signed the combined checksums. The published signature and all three package hashes were checked again after publication.
The exact Linux bundle passed WAV, MP3, MP4, WebAudio, oscillator recording and synthetic microphone capture. Trusted-click tests reached recording review, exported a nonzero WAV and played its first audition. A disposable connected Grove loaded calendar data, Files and a sandboxed preview with external CSS, script and image. No fixture CSP events were observed; the parent observer covered interactions after startup. No live-model, GPU-generation or real-data tests, or clean-machine Windows installation, were run.
Hashed Python CI dependencies and bounded IRC property fuzzing are in place. Five Scorecard alerts were marked fixed; seven dependency findings and the independent-review, repository-age and badge limits remain documented in the Scorecard follow-up. Passing tests do not certify that software has no vulnerabilities.
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 through GitHub private vulnerability reporting.
How can you check that a download came from Arynwood?
Starting with 0.5.4, each release's combined checksum list is signed with the Arynwood release key. The fingerprint of that key is:
C536 F3C4 689A 1734 920A 0E5B F1F8 0C83 C593 8FF0
The key is Ed25519, used only for signing. It was created on October 25, 2026 and expires on October 24, 2028 unless it is extended. The public key is published in the repository. Before trusting a signature, check that the fingerprint gpg reports matches both this page and the repository; this page is the copy outside GitHub. Releases up to and including 0.5.3 are not signed. Check those with their published SHA-256 checksums, and packages from 0.5.4 on also with their GitHub build attestations. The release signing guide has the commands.
Where can you check the sources and release status?
- Arynwood MCP security policy: the public baseline and documented gaps.
- Arynwood MCP v0.5.4 release: the published downloads, including the hardening in this brief.
- Release signing guide: the release key, signed checksums and how to verify a download.
- MCP tools specification: tool definitions, schemas, annotations and human oversight.
- MCP security best practices: protocol-specific trust and authorization risks.
This brief summarizes Arynwood's source review and recorded test results. External specifications provide context; they do not certify Arynwood. Published October 9, 2026.