An agent with a key is not an agent with your wallet

Agent products such as Grok Bot run tasks from a cloud computer, which makes them a concrete place where a trading key could end up. Grok's launch page does not mention trading, crypto or leverage, and nothing here claims Grok Bot ships a LeverUp connector. LeverUp's official gasless documentation describes a hosted-agent mode for backend-held signing keys. Our tutorial, How to Build a Grok Bot Trading Agent on LeverUp, explores that setup.

This post is the third in the Agentic Trading on Perps series. The second, AI Trading Bot vs AI Agent on Perps, covered how leverage changes failure modes. Here the question is narrower: when you hand an agent a key, what can that key do to a leveraged perp position, and what can it not do?

For the general argument for why agent access should be narrow, see AI Trading Agents Need Scoped Permissions. This post does not repeat it. It stays on the permission layers and on LeverUp's documented boundaries.

Three layers of access

"The agent has access" can mean three different things. Treating them as one is a common source of confusion.

  1. Read access. The agent can see prices, markets, positions, history and portfolio data. It cannot change anything.
  2. Trade-intent access. The agent can submit instructions to open, close or adjust positions, but only inside the account's existing structure.
  3. Collateral movement. The agent can transfer tokens out of a wallet or withdraw funds. This is the layer that turns a bad trading day into an empty account.

A well-scoped agent key sits on layer 1, layer 2, or both. It does not reach layer 3. Whether a given system actually enforces that split is a property of the venue, not of the agent, which is why the rest of this post reads the documentation instead of assuming.

What "scoped" means for a perp position

A perp position is a bundle of choices: direction, size, leverage, margin, and optional take-profit and stop-loss orders. A scoped key can be allowed to touch some of those and not others. In practice, the sensible questions are:

  • Can the key open new positions, or only close existing ones?
  • Can it adjust (add margin, change TP/SL), or is the position fixed once opened?
  • Can it reduce collateral on a position?
  • Is it limited to specific actions at all, or does it hold a wildcard?

The answers decide the worst case. A key that can only close positions can end exposure but cannot create it. A key that can open positions can create leveraged exposure using whatever collateral the account has made available. Those are very different risks, and a prompt asking the agent to "be careful" changes neither.

LeverUp's 1CT hosted-agent boundaries, as documented

LeverUp's gasless interface, One-Click Trading (1CT), lets a trader authorize a signing key once onchain. After that, each order is an offchain EIP-712 signature that the protocol relays and executes, according to the gasless overview. The same page lists a "hosted agent" mode: a key your backend holds, authorized with authorizeAgent(botAddress, …) and "optionally restricted per action."

The gasless overview states the boundary plainly: the signing key "can only express trading intent. It cannot transfer tokens, cannot withdraw, and cannot act outside the permission bits the user granted." The overview also says the main wallet key is not used after setup.

The permissions themselves are set in the authorization docs:

  • authorizeAgent(agent, name, permissions) is a one-time transaction from the trader's main wallet.
  • permissions is a bitmask where bit n grants action n. The docs' examples show MARKET_OPEN as bit 0 and MARKET_CLOSE as bit 1, so an open-and-close-only agent is a two-bit mask.
  • type(uint256).max is a wildcard that skips per-bit checking and grants everything. Any other value is checked bit by bit.
  • A trader can have several agents, each with its own name and permissions.
  • The same call can update an agent's permissions later, and separate functions revoke one agent, an agent by name, or all agents.

Two details matter for scoping. First, an explicit mask is a snapshot: the authorization docs say an agent authorized before a new action existed does not hold that action's bit, while a wildcard agent picks up new actions automatically. A wildcard therefore grows with the protocol; a narrow mask does not. Second, the docs' own example of "everything except one action" is written as noWithdraw, excluding REMOVE_MARGIN. That is the docs' label for the mask. This post does not characterize where removed margin goes, because the pages reviewed do not say. The takeaway is simpler: margin removal is a separate bit, and an operator who wants an agent that cannot touch it has to leave it out explicitly.

The gasless overview lists fourteen operations the interface supports, including market and limit open, market, batch and partial close, add and remove margin, and several TP/SL create, update and cancel actions. The permissions page does not publish a separate, smaller "safe subset." Which of those fourteen an agent receives is the trader's call.

The step-by-step setup is in the Grok Bot guide, so it is not repeated here. One short pointer: the Agent Wallet Manager in the app lets a trader paste an agent address, name it, tick individual actions, and later update or revoke it. The docs say the app does not ask for the private key.

Authorization is also not the same as funding. The authorization page states that it "grants permission to trade, not to move tokens," and that the trader must still approve the Diamond contract for the collateral token and the execution fee token. Without those approvals, intents are accepted by the endpoint and then skipped onchain.

Read-only data needs no trading permission

Layer 1 is separate from layer 2. LeverUp's REST API at service.leverup.xyz is described as "read-only HTTP access to prices, markets, positions, trade history, portfolio analytics and leaderboards," with no authentication required. Open positions and portfolio data for an address are among its endpoints. The same page says placing trades goes through the onchain or gasless routes instead.

That gives an agent builder a clean split. A research or monitoring agent can read positions and prices with no trading key at all. A second component, with a narrow mask, can be given the ability to submit intents. Keeping those apart means a compromised reader holds nothing that can place an order. The REST API docs ask integrators to cache where permitted and poll no more than once per second per endpoint; that is a rate courtesy, not a security feature.

If a scoped key leaks: what an attacker can and cannot do

Take a hosted-agent key whose mask covers market open and market close only. Using the documentation, here is the bounded picture. Items marked assumption are reasoning from the docs, not statements in them.

Cannot, per the gasless overview: transfer tokens, withdraw, or take an action whose bit was not granted. Those are the stated limits of a signing key.

Can, within the granted bits: submit signed intents to open or close positions on that trader's behalf, as described in the authorization docs. For a leveraged account, that is the real exposure. An attacker with open permission can create positions in markets the interface supports, and market-close permission can end positions the trader meant to hold. The permitted actions expose the trader to trading losses and fees; the key has no direct token-transfer permission. Positions remain subject to LeverUp's documented liquidation conditions; how liquidations work on LeverUp explains the mechanics.

Bounded by approvals (assumption): because the authorization docs say intents are skipped without the collateral and fee-token approvals, the size of the Diamond's allowance on the trader's wallet plausibly caps how much collateral an intent can draw. The pages reviewed do not spell this out as a security control, so treat it as inference, and check the allowance you have set.

Stopped by revocation: the trader can call revokeAgent, revokeAgentByName or revokeAllAgents from the main wallet, as described in the authorization docs. The docs warn to revoke onchain and wait for the receipt before deleting local key material, because the reverse order leaves a live authorization on a key nobody holds. Revocation stops future intents. It does not undo intents that already executed (assumption, from how onchain execution works; the pages reviewed do not address it).

Not described in the gasless overview or authorization docs reviewed: an expiry on authorizations, per-key size or leverage limits, or alerting on unusual intents. Absence from the docs reviewed is not proof that nothing exists. It means this post makes no claim either way.

The practical reading is narrower than "the agent could drain me" and narrower than "scoped keys make this safe." Restricting a key to opening and closing positions narrows its permitted actions, but does not cap the trading losses or fees those actions can cause.

Prompts still are not risk rules

A scoped key answers what the agent may do. It does not answer how much, how often, or under what conditions. An instruction like "keep leverage low" lives in a prompt; the permission bit for market open does not know about it. Turning those judgments into rules enforced outside the model is its own topic, and a later post in this series takes it up. For now the point is that permissions and risk limits are separate layers, and a key can be perfectly scoped while the position it opens is far too large for the account.

If you are new to the series, start with the hub post, then the bot versus agent comparison.

Closing

Read, trade and withdraw are different permissions, and a perp position is exposed mainly through the middle one. LeverUp's gasless overview puts the signing key on the trade-intent side and states that it cannot transfer or withdraw, with the specific bits left to the trader. Read those pages directly before relying on any summary, including this one.

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 settlement, protocol risk controls, and gasless execution.