Security

The trading key is restricted by the protocol, not by our promise

Arming trading approves a Hyperliquid agent key — a key the exchange itself restricts to trading actions. It can never withdraw or transfer, regardless of what our server asks it to sign.

Server-side, a single allowlist decides what any key may ever sign: place an order, cancel an order, update leverage. Anything else is refused before a signature is produced. Adding to that list is a deliberate change to the platform’s custody posture, not a configuration tweak.

Approved agent keys are stored encrypted with AES-256-GCM under a key derived through HKDF, are excluded from query results by default, and are never returned by any API or MCP tool.

Agent trading is off until you turn it on

Every connector key is read-only when issued. Order execution requires a separate, explicit opt-in on your account, and a platform-wide kill switch sits above that.

Orders placed through the connector run under server-side caps on margin, leverage and order rate, re-read from configuration at execution time and re-checked immediately before the order is sent.

An order cannot be placed that was never quoted: place_order refuses to execute without a matching preview from the last ten minutes, keyed on the exact arguments and consumed on use.

There is no withdrawal or transfer tool in the MCP surface. Closing a position and cancelling an order are risk-reducing and deliberately not rate-limited as tightly as opening one.

Accounts are isolated structurally

No MCP tool accepts an account, address or user parameter. Every tool derives the account from the authenticated session, so there is no argument through which one user could request another user’s data. On the web API, identity comes only from the signed session token — never from a query string, body field or header.

This is not left to review: an automated suite drives two live accounts on every release and asserts that neither can read or act on the other across the REST API, the MCP surface, the admin tools and the internal service. A failure there blocks the release.

Sign-in, sessions and revocation

Sign-in is Sign-In with Ethereum (EIP-4361): the server issues a nonce, your wallet signs a message naming this site, and the server rebuilds and verifies that message itself. A failed verification burns the nonce. The site also refuses to sign a message that does not name its own origin, which is what makes the domain line real phishing protection rather than decoration.

Revocation takes effect immediately rather than when a token expires: every request re-reads your account, and signing out or deactivating invalidates the existing sessions. Revoking a connector key takes effect on its next call.

Handling your connector key

Your connector key is shown once and stored only as a hash — we cannot recover it, only replace it. Anyone holding it can read your account, and trade it if you armed trading, so treat it like a password.

Where your client supports it, send the key as an Authorization header rather than in the URL. Both forms work, but the header form keeps the key out of browser history and out of any intermediary’s logs. On our side the edge strips the token from the logged request line and no service logs request URLs at all.

What we never collect

No email address, no phone number, no name and no identity documents — there is no field for them. No advertising or cross-site trackers. What we keep is your wallet address, your settings and the audit trail of your own orders and connector calls, which is what lets you reconstruct what an AI did on your account.

Reporting a vulnerability

If you find a security issue, report it to security@mcpify.trade before disclosing it publicly. Include enough detail to reproduce the problem. We will not pursue legal action against good-faith research that avoids privacy violations, service degradation and access to accounts that are not your own.

What this page is not

None of this makes trading safe. Perpetual futures are leveraged instruments and you can lose your entire deposit through ordinary market movement, an unwise prompt or an AI that reasons badly — none of which a security control can prevent. The caps described here are abuse guards, not a promise about outcomes.