Connectors are in the news, trading is not the point
Meta's assistant, Muse, supports connectors to apps and services. Public's MCP page documents connecting Muse to a Public account for trading; that is not a LeverUp integration. This post compares approval with pre-authorization. What they do show is a pattern worth understanding before any agent touches a leveraged position: how much of the decision stays with a human at the moment an order is placed.
Two clarifications up front. "Muse Wonder" is a model series, not a trading product. Meta's research post describes it as a model for personal and professional agents, and its examples are a running plan, custom merchandise and a seating chart. It does not describe trading. And nothing in this article says Meta Muse, or any other consumer assistant, connects to LeverUp. We are not aware of any such connector, partnership or endorsement, and none is implied.
This is the eighth post in the Agentic Trading on Perps series. Earlier posts covered what scoped keys can do to a perp position. Here the narrower question is about delegation models: approving each action versus authorizing a key in advance.
Two ways to delegate
Strip away the branding and there are two common designs.
Approve each order. The agent proposes, a human confirms, and only then does anything execute. The agent can research, draft and prepare, but every consequential action passes through a person at that moment. The human is a gate on each action.
Pre-authorize a scoped key. The human grants a signing key permission once, within limits. After that, the agent acts without a per-order prompt, inside whatever the grant allows. The human is a gate on the setup, and on whatever monitoring and revocation they do afterwards.
Neither is automatically safer. They fail differently.
| Approve each order | Pre-authorized scoped key | |
|---|---|---|
| Where the human decides | At every order | When the key is granted |
| Speed | Bounded by how fast a person responds | Not bounded by a person |
| Main failure mode | Approval fatigue; rubber-stamping; stale prompts | A broad grant used in a way you did not foresee |
| What limits damage | Declining an order prevents that order; approved positions still carry risk | Action permissions restrict allowed operations; exposure needs separate limits, monitoring and revocation |
| Typical wording | "Confirm this trade" | "This key may open and close positions" |
An approval prompt is only as protective as the attention behind it. A scope is only as protective as the care taken when it was written. The rest of this post looks at where each model shows up.
Consumer assistants: a pattern of approval by default
Meta's Help Center page on Connectors says Muse can connect to services through Settings, and states that by default Muse "will not take many important actions, such as sending an email, without your approval." The page adds that this can be changed in Settings and that many connectors can be limited to retrieving data. It also says Meta does not review custom connectors or how they use your information, and that credentials for custom connectors are held in a secure credentials store. The page does not mention brokerage or trading, and we do not extrapolate from it.
Meta's research post says something similar at the model level: the Muse Wonder description says the model "asks for clarification when needed and checks in before taking important actions." That is a statement about a model's design intent, not a guarantee about any specific product setting.
So the pattern, in the generic sense, is: an assistant plus a connector to an outside service, with a human approval step for important actions that the user can loosen or tighten.
Brokerage connectors: one third-party example, with its own terms
The same pattern appears in brokerage. Public.com publishes an MCP trading page describing how outside AI assistants can connect to a Public brokerage account. This is a third-party brokerage connector, not LeverUp — an industry-pattern example only.
Its terms are worth reading closely, because they show the approval question is not settled by the word "connector." As of 2026-10-29, the Public.com MCP trading page says that by connecting an AI agent you authorize it to view your account data and place trades on your behalf, and that trades "may be executed by your AI agent without your direct input on each transaction." It also says Public does not supervise or audit third-party AI agents. The page includes setup text a user can send to an assistant that says "never place trades without my explicit confirmation," but that is an instruction the user chooses to give, not a requirement the page describes as built in. The page does not state a publication date.
The takeaway is not about Public in particular. It is that "human approval" can live in several places: in the assistant's defaults, in an instruction you type, or in the connector's own rules. If you cannot say which one applies, you do not yet know what approval means in your setup.
What LeverUp's hosted-agent model actually is
LeverUp's documented agent surface is different in kind. The gasless trading (1CT) overview describes One-Click Trading as letting a user authorize a signing key once, onchain, and then trade without wallet popups and without paying gas. After the authorization, "every subsequent order is an offchain EIP-712 signature that the protocol relays and executes."
That is the pre-authorized model from the table. Some details from the docs:
- One authorization, many orders. The authorization page describes a one-time onchain transaction from the trader's main wallet that grants a signing key permission to submit trade intents on their behalf.
- Scoped by permission bits. The authorization documentation describes a permissions bitmask, where each bit corresponds to an action. The docs show examples such as allowing only market opens, or market opens plus market closes, and note that the maximum value acts as a wildcard.
- Limited to trading intent. The 1CT overview says the signing key "can only express trading intent": it cannot transfer tokens, cannot withdraw, and cannot act outside the permission bits granted.
- Revocable. The authorization page lists functions to update permissions and to revoke an agent, and notes the app has an Agent Wallet Manager for inspecting and revoking authorizations.
- Hosted agent mode. The 1CT overview lists a "hosted agent" integration mode, a key held by a backend, with authorization that can be restricted per action.
The step-by-step setup is in our tutorial, How to Build a Grok Bot Trading Agent on LeverUp. This post does not repeat it, and it is not evidence that Grok Bot or any consumer assistant ships a LeverUp connector. It is a worked example of one developer pattern, in which you hold the key and the agent is code you control.
Two cautions from the authorization documentation. First, authorization grants permission to trade, not to move tokens; the trader still approves the protocol contract for the collateral and fee tokens. Second, the wildcard value is not "everything except what I forgot." An explicit mask is a snapshot, and the docs explain how new actions interact with older masks. Read the authorization page before choosing a scope.
What human approval still means after a key is authorized
Pre-authorization does not remove the human. It moves the human's job.
- Scope design. The permissions you pick are the approval you gave in advance. A key limited to opening and closing is a smaller decision than a wildcard.
- Capital design. LeverUp's authorization documentation separates agent action permissions from the trader's token approvals to the Diamond contract. Review permissions, token allowances and available collateral together. Neither action permissions nor initial funding set a cumulative-loss budget. Post #3 and our earlier piece on scoped permissions for trading agents go deeper.
- Monitoring. A position opened without a prompt still has to be watched. Nothing about a signing key tells you whether the agent's reasoning was sound.
- Revocation. The authorization documentation lists onchain revocation functions and warns to revoke and wait for the receipt before deleting local key material.
In the approve-each-order world, the human's job is attention. In the scoped-key world, it is engineering and housekeeping. Many people would find the second easier to get wrong, because nothing prompts them to revisit it.
Why the distinction matters under leverage
An unleveraged spot purchase and a leveraged position expose capital differently. Leverage creates notional larger than posted margin, so an adverse move can consume that margin faster. LeverUp's liquidation documentation describes liquidation when the market reaches the liquidation price or collateral becomes insufficient to cover outstanding fees. Its holding documentation explains ongoing holding and funding charges. Approving an opening order does not end the position's continuing risk.
That changes what an approval prompt is worth. A single "confirm" tap on an order tells you the size and direction, but it may not tell you how much margin buffer remains once fees accrue, what happens overnight, or how the position interacts with others. Our posts on funding and holding costs and liquidation and fee drift cover those pieces.
Likewise, a pre-authorized key under leverage can submit a series of orders without per-order approval. LeverUp's documented permission bits restrict action types; they do not specify a user-selected notional, leverage or cumulative-loss budget. Exposure controls need separate enforcement beside the protocol's market risk controls.
A few questions help in either model:
- Where exactly does approval happen, and can I point to the setting or the instruction that enforces it?
- If the agent is wrong, what is the largest thing it can do before a human notices?
- Can I revoke quickly, and have I tested that?
- Does anything outside the agent, such as a margin limit or a size limit, hold even if the agent misbehaves?
Closing
"Human in the loop" and "delegated key" describe two different designs, and an industry full of connectors uses both. Meta describes configurable approval defaults, while Public's MCP disclosure permits trades without direct input on each transaction. LeverUp's hosted-agent mode uses a backend-held signing key with onchain authorization, action permissions and revocation. None of this means one assistant or another works with LeverUp. Products and terms change; re-open the primary pages before relying on them.
For the series start, see the hub post.
This post is educational and is not financial advice. Trading perpetuals with leverage carries risk, including loss of your entire margin.
LeverUp uses a protocol-managed virtual liquidity system powered by the VMMV, where trades reference oracle pricing while execution, settlement, and risk management are handled at the protocol layer. See the documentation on VMMV-based settlement, oracle-referenced pricing, relayed execution and protocol risk controls.