Skip to content

MCP Safety and Scope

VerifiedOwner Native clients and MCPLast verified macos@984bdf6cb7b7fe187931665a4b8d022bae8330d9

This page states, as plainly as possible, what the local macOS MCP host (see The macOS MCP Host) can and cannot do, what requires a human to act first, and what has and has not actually been reviewed. For the backend's own MCP surface, see Backend MCP; the claims on this page are scoped to the local macOS host only.

Read-only vs. mutating operations

The local host's tool families are not all read-only. Under the default scopes (read, application control, draft editing, and backtest submission):

  • Chart tools can change what the loaded chart displays (symbol, resolution, indicators) — local UI state inside the WebView, not a server-side record.
  • Strategy Workspace tools can edit and persist draft strategy content, when an authenticated ONIX session is present — including saving that draft, not merely viewing it.
  • Backtest tools can submit a backtest to the backend for the strategy currently open in the workspace.
  • Screener tools can apply, reset, sort, or change the selection of the screener's own state, not only read it.
  • Connections tools can control venue-connection console state, not only read it.

None of these mutations place an order, cancel an order, activate a strategy, or start or stop a sandbox/execution runtime. Order placement, order cancellation, and strategy activation are not present in the local host's default, supported tool registry — this is not a low-risk default that a scope could raise; no such tool is defined there at all. A separate diagnostics capability exists for support use, is off by default, and is outside this supported-scope boundary; this page does not describe what it exposes.

What requires human confirmation

  • Enabling the host at all requires opening the ONIX Mac app and starting the server; nothing enables it remotely.
  • Obtaining the credential a client needs to connect requires the human at the machine to copy that credential out of the running app into their own AI client's configuration. There is no automated provisioning path.
  • Enabling the diagnostics capability is a separate, explicit toggle inside the app, off by default, reserved for support use and described in the app's own guidance as something to leave off otherwise.
  • Every scope beyond the always-available read tools is something the human running the app has chosen to leave enabled; the enabled-scopes set is a small, explicit list rather than "everything unless flagged."

What is denied by default

  • The diagnostics scope, as above.
  • Any scope name the app does not recognize: an unrecognized or previously-valid-but- now-removed scope value simply fails to load rather than falling back to some broader default.
  • Any connection that is not recognized as coming from the local, already-configured client — including a connection that omits identifying information entirely, which fails closed by design rather than being treated as a special case.
  • Any request path that resembles a money-moving or account-mutating route, evaluated independently of whether a tool that could reach such a path exists at all, as a second layer beneath the tool registry.

The honest statement of review status

  • What is verified, source-level: the reviewed commit's tool registry does not define order-placement, order-cancellation, strategy-activation, sandbox-control, or generic-HTTP tools; a dedicated automated test suite exercises the host's authentication, origin-matching, and money-route safeguards; and a dedicated test file exists whose specific purpose is proving that the test suite runs against the real shipped source files rather than a hand-copied stand-in.
  • What that does not mean: it does not mean this surface has received independent, external security review, and it does not mean every conceivable bypass has been found. Internal adversarial testing by this codebase's own authors is evidence of diligence, not evidence of completeness.
  • What is explicitly out of scope for this page: whether the ONIX frontend's own browser bridges (the JavaScript surfaces the native tools call into) are themselves free of vulnerabilities is a question about the frontend, not about this local host, and is not addressed here.
  • The one caveat that most affects trust in this surface today is documented on ONIX macOS Client: the bridge contracts this tool registry was verified against are pinned to a frontend commit that is now behind the frontend commit this documentation set otherwise treats as current. Full revalidation against the current frontend has not happened yet, and any claim depending on that parity carries status: unverified until it does.
Evidence and source pins for this page

Verified. Current behaviour, confirmed in source at the pinned commit.

Verified on against the following immutable sources:

  • macos@984bdf6c:MCPEgress.swift (blob bc8d9ea68a19ec4469cbd812edb4ac1f953ed3c3)
  • macos@984bdf6c:MCPTools.swift (blob a03bb24902511f8e20430092e2e47acd581d88fd)
  • macos@984bdf6c:MCPSecurityTests/Tests/MCPSecurityTests/MoneyPathTests.swift (blob 9929d6b51dc94013c4b804cf81489f5eea8b6c68)

Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.