Agent ID Permissions: Isolation, Limits, and How to Revoke Access

A name is just a doorplate — permissions are the key

Since Agent ID launched, most of the attention has gone to who grabbed the best name. The question that actually matters for your money is a different one: what is this AI agent allowed to do? Readable addresses make wallets easier to identify; they do not add any protection.

Binance's Agent OS announcement lays out a permission framework worth checking your own setup against, point by point.

The core idea behind Agent OS is isolation plus authorization: an AI agent does not operate your main account directly. It works inside a dedicated agent subaccount, with permissions granted item by item.

1. Understand the isolation model first

According to the official announcement, MCP access runs through a dedicated agent subaccount that is isolated from the main account. The agent can read that subaccount's balances, positions, and account records. With explicit user authorization, it can also view the main account in read-only mode. The implication: if the agent is compromised, losses should be confined to the subaccount — provided you never park large balances there.

2. What the agent can and cannot do

"No external withdrawal" is the single most important line of defense right now. Even if an API key or the agent's logic is abused, funds are hard to move out directly. But that protection only holds as long as you do not move the money out yourself.

3. Five settings to complete before going live

1. Open a separate subaccount and fund it narrowly: put in only the capital this strategy needs, never shared with the main account;
2. Set funding limits: cap both per-order and per-day size so one bad instruction cannot wipe out the whole position;
3. Enable only the products you need: no futures unless the strategy uses futures, no margin unless it uses margin;
4. Attach an IP allowlist to the API key: restrict calls to your server's egress IP, shrinking the window if the key leaks;
5. Turn off unneeded read access: if read-only access to the main account is not essential, do not grant it.

4. How and when to revoke

Binance states that developers can revoke access at any time. In practice, handle three situations differently:

• Strategy retired: revoke API permissions first, then close positions, then sweep the subaccount balance back to the main account;
• Key possibly leaked (committed to GitHub, pasted into a chat window): delete the old key immediately, generate a new one, and audit the subaccount's trade history;
• Abnormal agent behavior (unusual order frequency, sudden size increases, trading pairs you never configured): revoke permissions immediately. Do not simply tell the agent to behave.

5. Three common misconceptions

"An Agent ID means it is officially verified"

It does not. An Agent ID is just a name, and anyone can attach one to their own Agentic Wallet. Judge trust by the underlying address, the scope of permissions, and observed behavior — not by the suffix.

"No withdrawals means it is safe"

It is not. The agent can still place orders. A runaway strategy can burn through a subaccount in minutes through high leverage or illiquid pairs. The withdrawal block prevents theft, not losses.

"Grant broad permissions to keep things simple"

The broader the permissions, the larger the damage when something goes wrong. An AI agent earns reliability through constraints, not trust. Treat it like an intern: give it the minimum access needed to do the job, and expand only after it proves itself.

6. A checklist you can actually run

• □ The agent uses a separate subaccount with funds kept apart from the main account
• □ Per-order and per-day funding limits are set
• □ Only the product categories the current strategy needs are enabled
• □ The API key is bound to an IP allowlist
• □ The main account has no unnecessary read permissions granted
• □ Subaccount trades and transfers are reviewed weekly
• □ You know exactly where to revoke access, and have tested it once