You Can Approve Every Trade. Or You Can Delegate the Subaccount in Advance.

Almost every AI agent launch this year has answered the same question the same way: a person stays in the loop, one action at a time. Binance Agent OS is worth reading closely because it does not answer that question once. It lets a user answer it twice, and pick either answer in advance.

What Binance actually launched

On 20 August 2026, Binance introduced Agent OS, described in its own announcement, distributed the same day through PR Newswire, as a developer platform and standardized access layer connecting AI applications to Binance's trading, market data, wallet, payment and onchain capabilities, spanning crypto and traditional markets. The platform brings together pieces that already existed separately: Binance's API, its Wallet Agentic Hub, its x402 payments infrastructure, a Skill Hub of discoverable modular capabilities, and newly added support for the Model Context Protocol, the open standard, originally released by Anthropic, for connecting an AI system to external tools through one interface rather than a custom integration per service. Binance's own material names ChatGPT, Codex, Claude Code and Cursor as compatible applications, and states that the Binance MCP Server lets a compatible application reach Binance without a user manually managing API keys.

The permission model Binance describes is straightforward to state and easy to miss the weight of: which Binance data and which trading capabilities are available to a connected agent is a user configured setting, not a default. Binance also states plainly what it can and cannot see once an agent is connected. It can monitor the trading activity that results, including the orders an agent actually places. It cannot see the agent's broader workflow or the reasoning behind a given order, because that reasoning runs inside whichever AI application the user chose, on the user's own side of the connection, not inside Binance's systems. Jeff Li, Binance's VP of Product, put that limit in blunt terms to TechCrunch: "We really cannot see the reasoning of what the user's action is." Binance can evidence what happened. It is explicit that it cannot evidence why the agent decided to do it.

The subaccount is where the actual constraint lives

Binance's own material describes the permission system in general terms. TechCrunch's reporting, built on an interview with Li, is more specific about the mechanism doing the actual work: a dedicated subaccount. A user assigns an agent to a subaccount and configures which activities are available inside it, TechCrunch's examples being spot or futures trading. Withdrawals from that subaccount are blocked by default. Other reporting on the same launch describes an agent as able to view balances, portfolio information and transaction history for its assigned subaccount, and balance and portfolio information for the user's main account, while being unable to reach non trading personal account information such as an email address or KYC data, and describes a user retaining the ability to revoke an agent's access at any time, including through a described emergency stop that can disconnect connected agents and cancel open positions and orders across a subaccount at once. Moona Intelligence could not independently verify those specific mechanics against Binance's own technical documentation directly in this environment, and treats them as corroborated secondary detail rather than confirmed first party specification.

Read plainly, subaccount isolation is doing the same job an isolated, spending capped account did in Robinhood's Agentic Trading launch: it bounds what an agent-directed loss can reach before anything else about the agent's behavior matters. Robinhood already established that a brokerage would isolate an agent's authority to a dedicated, pre funded account rather than exposing a customer's full holdings to it. Binance's subaccount is the same architectural idea, applied to an exchange rather than a brokerage, with withdrawal blocking as an added structural constraint neither the agent nor, on Binance's own framing, an attacker who compromises the agent's reasoning can casually route around.

The claim that actually needs careful handling

The most consequential Agent Authority claim in this launch is also the one with the thinnest paper trail, and it deserves to be stated at exactly the size the evidence supports rather than rounded up into confirmed product behavior.

TechCrunch reports that Binance told it users can choose whether an agent must seek approval for every order, or can execute trades autonomously once its permissions are configured. Li's own framing of the philosophy behind that choice, quoted directly: "Instead of total freedom, we put the power in users' hands to give them the granular access control of what they can do through the agent," and, on where that control sits, "we put it at the account level to protect the users' funds."

The distinction matters because of what it would mean if the claim is accurate as stated. A per order approval mode keeps a human as the transaction level authority: the agent proposes, a person still authorizes each specific trade before it executes. An autonomous mode is a different architecture entirely. The human's authorizing act happens once, in advance, when the account, its available capabilities and its capital boundary are chosen. Every trade after that point executes without a new human decision, inside whatever envelope that earlier choice defined. Both are legitimate control models. They are not the same control model, and a launch that genuinely offers both, rather than only ever the second one dressed up as the first, is offering something Moona Intelligence has not seen an exchange state so explicitly before. Whether Binance's implementation actually enforces that choice the way it was described to TechCrunch is a separate question this record does not claim to answer, and it is the question worth watching for independent technical documentation or a demonstrated audit to close.

What the MCP Server's own documentation says about confirmation

Moona Intelligence's radar observed a modification to Binance's MCP Server documentation dated 21 August 2026, one day after Li's interview with TechCrunch ran, and this record independently checked that documentation against the per order versus autonomous execution claim above. Direct fetch of Binance's developer documentation was blocked by the network egress proxy in this environment, the same limitation already disclosed in the sourcing for this record. Moona Intelligence corroborated the documentation's content through multiple independent search passes that returned consistent, matching detail across outlets summarizing it, including at least one that led with the finding as its own headline. The documentation describes every order, every order cancellation and every transfer between wallets inside the Agentic sub-account, such as moving funds from Spot to USDⓈ-M Futures, as an action the platform confirms with the user before it executes. Reads, meaning market data and checks of the sub-account's own balances and positions, execute immediately and do not wait on a confirmation.

That is a narrower claim than the one Li described to TechCrunch, and it deserves to be stated exactly as narrow as the documentation makes it. Nothing in the material reviewed for this update describes how a user would instead configure an agent for the autonomous mode Li told TechCrunch users can choose, or what the MCP Server does differently once that mode is on. Until first party documentation or a demonstrated deployment describes that mode operating through this integration, this record treats confirm before execute, not user selectable autonomy, as the current documented behavior of the Binance MCP Server for every consequential action, and treats Li's account of a configurable choice as a statement of company intent this record has not yet been able to verify against a specification or an observed system.

A separate question, and one this record cannot close on the evidence available, is how that confirmation is technically enforced. The Model Context Protocol itself defines a general mechanism, elicitation, through which a server can ask the connecting client to collect explicit user consent before a consequential tool call proceeds. That mechanism is honored by the client and host application a user chose, such as Claude Code, ChatGPT or Cursor. It is not a guarantee the server itself can compel. Nothing in the material reviewed here states whether the Binance MCP Server refuses to execute an order or a transfer that a client submits without having first surfaced a confirmation step, or whether the confirmation Binance describes is, in practice, an instruction the connecting agent is expected to follow rather than a boundary Binance's own systems enforce independently of that agent's behavior. This record does not assume a model instructed to ask for confirmation is equivalent to an external authorization boundary, and treats the precise enforcement point as undocumented rather than resolved in either direction. For the same reason, whether an approved action is bound to its exact submitted parameters, meaning the symbol, side, order type, quantity, price where relevant, wallet source and destination for a transfer, and whether a changed parameter after confirmation would require a fresh one, is not established in any material this record could verify, and is preserved here as unknown rather than inferred.

A 25 August 2026 pass added one further, independent secondary account of the same claim. HackerNoon, reporting separately from TechCrunch, describes the MCP Server as restating an order for the user and waiting on a confirmation, and describes a user who wants fuller automation as able to adjust that setting. That is a second outlet describing the same adjustable behavior Li described to TechCrunch, which this record credits as additional secondary corroboration that the claim reflects more than one reporter's account of a single interview. It is not first party documentation this record could read directly, and it does not identify where that setting lives, what it changes at the protocol level, or how Binance's systems would enforce it differently once set. This record still treats confirm before execute as the only mode described in material it could verify as Binance's own published text, and treats the adjustable autonomous setting as a claim now corroborated by two independent secondary accounts rather than one, not as a documented product specification.

The empty subaccount and what is structurally excluded

Several further facts about the Agentic sub-account are specific enough, and consistent enough across independent reporting on the same documentation, to state as verified rather than as reported claims. The sub-account starts empty. A user must transfer assets into it from their main Binance account through Binance itself before an agent has anything to trade with, and the agent cannot perform that initial transfer on its own. That is a resource boundary created by account isolation and a manual funding step, not a numeric spending limit Binance's systems enforce as policy the way Robinhood describes a customer set spending cap on its Agentic Credit Card. The two produce a similar practical effect, a ceiling on what an agent can lose, but they are different controls, and this record does not describe Binance's isolation as a spending limit merely because the outcome rhymes with one.

The documentation also states there is no withdrawal scope: the MCP integration cannot move funds from the Agentic sub-account to an external address, categorically, not as a default a user could toggle off. That exclusion is scoped to this integration as documented. Nothing reviewed here establishes whether a different Agent OS pathway, such as the separately governed Wallet Agentic Hub or x402 payments, could give a connected agent external withdrawal authority Binance does not grant through the MCP Server, and this record does not generalize the MCP restriction to every Agent OS component absent that evidence. A user can optionally grant an agent a read only view of the main account's balance and portfolio, separate from the sub-account it actually trades in. That is a read grant. It does not carry transaction authority, and this record treats the two as distinct even where a user has enabled both.

Revocation is documented across several distinct channels rather than one: a user can disconnect an individual agent, revoke an application's access through an Authorized Applications setting, change a connected agent's permissions by disconnecting and reconnecting it, or trigger an Emergency stop that disconnects every connected agent at once. Binance's own documented language for Emergency stop is that it cancels all spot, margin and futures positions and orders in the Agentic account. That phrasing does not cleanly separate two different things: cancelling an order that has not yet filled, and closing a position that is already open and carrying real market exposure. This record could not independently confirm the underlying mechanics, such as whether an open leveraged position is closed at market and what that means for slippage, beyond Binance's own stated language, and does not infer more recovery than that language supports. What none of these mechanisms are documented to do is reverse a trade that already completed. Cancelling an order removes exposure that has not yet filled. Emergency stop, on its own stated terms, reaches open positions and pending orders in the account, not the settled outcome of a trade that already executed before it was triggered.

Regional availability is not established as universal. Agent OS runs on top of Binance's existing account infrastructure, and the capabilities available through it depend on the scope a user grants, the underlying account's own product eligibility, and Binance's ordinary regional restrictions on its global platform, which independently exclude some jurisdictions from the exchange entirely. This record does not infer that Agent OS itself is available everywhere from an announcement written in global terms. Separately, the exact mechanism behind scope selection, meaning whether a granted scope is an OAuth 2.1 scope, a Binance specific authorization object, or another mechanism entirely, is not established in material reviewed here. Binance's Developer Center supports OAuth application registration for API access generally, but no material found specifically documents the Agent OS connection flow as using OAuth scope grants rather than a proprietary permission screen, and this record preserves that mechanism as unknown rather than assumed from the presence of OAuth elsewhere in Binance's developer platform.

What sets the ceiling, and what does not change it

TechCrunch also reports a specific financial exposure claim: Binance does not impose a separate platform level cap on how much an AI agent can trade or lose inside its assigned subaccount. On that reporting, the amount a user transfers into the subaccount is the effective maximum capital exposed to the agent under that configuration.

That claim needs a qualification that is easy to lose in a headline. It is a statement that Binance does not add a further, agent specific loss cap on top of what already governs that subaccount. It is not a statement that no risk mechanics apply once an agent is trading inside it. Whatever margin requirements, position limits and liquidation mechanics ordinarily apply to spot, margin or futures trading on Binance, for any account, agent directed or not, apply the same way here. Li told TechCrunch that Binance's existing security, risk control and anti money laundering policies for subaccount APIs apply to Agent OS at launch. A subaccount funded with a fixed amount of spot capital cannot lose more than that amount by construction. A subaccount configured for leveraged futures trading is subject to Binance's standing margin and liquidation mechanics precisely because that product always carries those mechanics, not because Agent OS added a new one. The correct reading is narrow: the user's transferred capital sets the ceiling on what the user chose to expose, under the risk rules that product already carries. It is not a claim that an agent can mechanically forfeit every asset in every Binance product with no risk system in the way at all.

Two products, two very different limits

It is worth stating plainly because it is the easiest detail in this launch to blur: Agent OS exchange trading and Binance's Agentic Wallet are not governed by the same numbers, and TechCrunch's reporting is specific about the Agentic Wallet side. Agentic Wallet transactions, separate from subaccount trading, carry their own Binance imposed daily limits: regular swaps capped at a reported 50,000 dollars a day, DeFi activity at a reported default of 100,000 dollars a day, and x402 payments capped far lower, at a reported 20 dollars a day. Those are fixed platform ceilings on a specific wallet product used for swaps, decentralized finance interaction and machine to machine payments. They are not the mechanism that bounds an agent's exchange trading exposure, and TechCrunch's reporting does not describe them as such. Applying the Agentic Wallet's daily caps to subaccount trading, or concluding that exchange trading has no controls at all because it lacks an equivalent daily cap, would both misread what was actually reported.

Naming the layers separately, because the launch does not

Binance's own material and TechCrunch's reporting, read together, touch several distinct control layers without ever naming them as separate. Doing that naming is Moona Intelligence's reading, not Binance's framing, and it is worth being precise about which layer each fact actually belongs to.

• Permission scope: which Binance data and trading capabilities a connected agent can reach at all, set by the user when the agent is configured.
• Subaccount isolation: the boundary that separates an agent's funds and activity from the user's main account and holdings.
• Capital allocation: how much the user actually transfers into that subaccount, which functions as the loss ceiling under whatever risk mechanics the enabled product carries.
• Transaction limits: fixed daily caps, documented for the Agentic Wallet specifically, that are a separate mechanism from subaccount capital and do not apply to exchange trading.
• Withdrawal restrictions: blocked by default on an Agent OS subaccount, a constraint on moving funds out rather than on trading them inside.
• Per order human approval: the mode the MCP Server's own documentation currently describes for every order, cancellation and transfer, where a person confirms each specific action before it executes. Li described this to TechCrunch as one of two configurable modes.
• Autonomous execution: the other mode Li described to TechCrunch, where the agent would trade inside its configured envelope without a new human decision per trade. No first party documentation of this mode operating through the MCP integration was found for this update.
• Revocation: the user's ability to disconnect an agent or cancel its access, reported to extend to an emergency stop across open positions and orders.
• Binance risk controls: the exchange's ordinary margin, position and liquidation mechanics, which Li told TechCrunch continue to apply to subaccounts used by Agent OS.
• AML controls: Binance's existing anti money laundering policy for subaccount APIs, which Li told TechCrunch also applies at launch.

Collapsing any two of those into one mechanism is where a reading of this launch goes wrong. A subaccount being isolated says nothing about whether it requires per order approval. A user choosing autonomous execution says nothing about whether normal margin rules still apply inside it. Withdrawal being blocked says nothing about how much can be traded, and lost, before a withdrawal would even be attempted.

The Authority Provenance ledger

Everything above answers what Binance Agent OS technically permits, and who Binance says can turn each permission on or off. It is a different, and harder, question to ask where the authority to grant those permissions in the first place actually comes from, and what happens once a technically permitted action has already executed and turns out not to be what the user wanted. Moona Intelligence separates the two on purpose. A strict Agent Authority reading treats "the platform enforced the permission it was given" and "the person who set that permission was entitled to give it" as different claims, verified differently, and does not let the first stand in for the second.

Authority grantor. Documented at the account level only. The authenticated Binance account holder is the party who assigns an agent to a subaccount, configures its permissions and chooses between per order approval and autonomous execution. For an individual retail account, control of the account is itself the platform authority being exercised, and nothing further needs establishing. Binance's own material and reporting on the launch reference institutional accounts using the platform, but for a corporate, fund or otherwise managed account, this record found no first party documentation of a distinct process confirming that the specific individual configuring an agent held internal authority, a board mandate, a client agreement or any other upstream basis to delegate trading authority over capital that is not personally theirs. Agent OS documents who clicks the button. It does not document what entitled them to.

Mandate or basis. Undocumented beyond platform account control. Binance's material addresses account level permissioning, not the organizational governance question of whether a given employee, officer or manager was authorized by their own institution to grant an AI agent trading authority. This record treats that gap as unresolved rather than assumed closed, the same way this desk has read the identical gap in Nuggets' Authority Control Plane, which documents that an agent's authority traces to a specific human without documenting that the human's own mandate was checked, and in Rain's Agentic Payments Alliance, where the same distinction between identifying a grantor and verifying a grantor's standing remains open at coalition scale. Identifying who configured the agent is not the same fact as confirming they were entitled to.

Delegated scope. Documented, and specific: a dedicated subaccount, the trading activities enabled inside it, such as spot, margin, convert, USDⓈ-M futures or COIN-M futures, the data an agent can read, reported as subaccount balances, positions and transaction history plus an optional read only view of the main account's balance and portfolio, the ability to transfer funds between wallets inside that subaccount, and the capital the user transfers into it. Not documented: any time bound or session limit on that grant. Nothing in Binance's own material or in corroborating reporting describes a delegation that expires on its own after a set period. On the evidence available, a configured agent's access is a standing grant until a human actively revokes it, not a bounded session that lapses by default. Available trading capability is also the intersection of what the agent's granted scope allows and what the underlying account is itself eligible to trade; this record does not describe an agent as reaching a product or a capability the account it operates inside does not already hold.

Explicit limits. The subaccount starts empty and requires a manual transfer from the user's main account through Binance itself; the agent cannot fund it. That is a resource boundary from isolation and manual funding, not a numeric spending policy, and this record does not describe it as a spending limit for that reason. Withdrawals to an external address are documented as categorically unavailable through this MCP integration, not a default a user could switch on; this record does not extend that exclusion to other Agent OS pathways, such as the Wallet Agentic Hub or x402, absent evidence covering them specifically. No separate Agent OS specific loss ceiling exists on top of the subaccount's capital: ordinary margin, position and liquidation mechanics for whichever product is enabled apply the same way they would to any account trading that product, agent directed or not. The MCP Server's own documentation additionally describes every order, cancellation and transfer inside the subaccount as requiring the user's confirmation before it executes, with no first party description found of an autonomous mode operating through this integration.

Inherited permissions or assumptions. Binance's existing security, risk control and anti money laundering policy for subaccount APIs apply to Agent OS automatically at launch, on Li's own account to TechCrunch. Those are standing platform controls attached to the subaccount and its API access. They are not evidence about whether any individual trade matched what the human actually wanted. A trade can satisfy every inherited control and still be a trade the user did not intend. Inherited controls answer whether an action was permitted. They do not answer whether it was intended.

Revocation or modification path. Documented across several distinct channels: a user can disconnect an individual agent, revoke an application's access through an Authorized Applications setting, change a connected agent's permissions by disconnecting and reconnecting it, or trigger an Emergency stop that disconnects every connected agent at once and, on Binance's own documented language, cancels all spot, margin and futures positions and orders in the Agentic account. That language does not clearly separate cancelling an order that has not filled from closing a position that is already open, and this record does not claim more precision about the underlying mechanics than Binance's own stated language supports. None of these channels are documented to reach an order or a transfer that already completed. What happens to an action already in flight at the instant revocation is triggered is not addressed in any material this record could verify.

Challenge authority. Split, and worth stating as two different claims rather than one. On the current MCP Server documentation, a user holds real pre execution decision authority over each specific proposed order, cancellation and transfer: the platform confirms with the user before it executes, and the user can decline. That is a genuine ability to stop a specific consequential action before it happens, and this record credits it as such. It is not a mechanism for challenging whether the underlying delegation, the account configuration and scope grant that put the agent in a position to propose that action at all, was itself legitimately constituted. No material reviewed here describes a channel by which anyone other than the user who configured the agent, an internal compliance function, an exchange level review, a counterparty or a regulator, can dispute or invalidate an agent's authority after an action it proposed has already been confirmed and executed. Binance's standing risk and anti money laundering controls are not a challenge mechanism on their own terms: those controls decide whether a trade is permitted to occur, not whether an already occurred, already permitted trade's authority can subsequently be disputed.

Recovery path. Undocumented beyond what revocation, Emergency stop and order cancellation already cover, and those reach forward, not backward. Revoking an agent or triggering Emergency stop stops its next action and, on Binance's stated language, reaches open positions and pending orders in the account. Neither is described as undoing a trade or a transfer that already settled. This record found no first party or independently corroborated description of a dispute, reversal or compensation process for a confirmed, executed action that was technically authorized inside its configured envelope but was not what the user actually meant to have happen, and does not infer one from ordinary financial remedies that Binance's material never describes as applying here.

Provenance evidence quality. Uneven across the questions this ledger asks, and worth stating separately rather than as one blended confidence level. Who configured the agent: documented, at the account authentication level. What authority was technically delegated: well documented, specific to subaccount, enabled product, granted scope and capital. Whether the grantor held legitimate upstream mandate: undocumented for anything beyond individual account control. Whether authority remained valid at the moment of execution: undocumented, since no session or expiry mechanism is described. Whether a specific proposed action was confirmed by a person before it executed: documented as current MCP Server behavior for every order, cancellation and transfer, though whether that confirmation is enforced by Binance's own systems or relies on the connecting client honoring it is not established. Whether execution stayed inside technical scope: partially observable, because Binance states it can monitor the orders that result, though nothing describes a pre trade check confirming a specific order matched the agent's configured permissions rather than a record of what already happened. Whether the action reflected the grantor's actual intent: explicitly not established beyond the user's own confirmation of that specific action, and Binance says so itself, in Li's own words, that it cannot see the reasoning behind an order. Whether a completed execution can be challenged or recovered: undocumented. The strongest evidence in this launch is about what an agent was permitted to reach and about a person's ability to stop a specific proposed action before it executes. The weakest is about who was entitled to permit the delegation in the first place, and what happens once a confirmed, executed action turns out to have been the wrong one.

Where this sits next to what Moona Intelligence has already covered

Binance is not the first record in this desk's coverage to describe authority a human sets in advance rather than approves instance by instance, and it is worth being exact about how it differs from what came before it rather than treating every predelegated authority story as the same story.

BNB Chain's Altana wallet, covered here on 21 August 2026, bounds an agent's onchain spending through a session key, an owner set spending limit, a contract allowlist and an expiry, recorded on a public, outside checkable registry, with the platform itself never holding the authority to widen that bound. Binance Agent OS is describing something structurally related but mechanically different: a centralized exchange account, not a self custodial onchain wallet, where the subaccount and its permissions are configured and enforced inside Binance's own systems rather than checked against a public chain record. Both are predelegated, capital bounded authority. Neither is evidence for the other, and this record does not claim Binance's subaccount enforcement carries the same outside verifiability Altana's onchain Keystore is described as providing.

AWS and Solv Labs' governed payments workflow answers a different question entirely: whether a specific already authorized payment can carry a signed record, produced at the moment of authorization, proving why that one transaction was allowed to settle. Binance's own statement is that it can monitor the orders an agent places but not the reasoning behind them. That is closer to an activity log than to a policy engine that evaluates and signs off on an individual order before it fills. Nothing in the material reviewed here describes Binance producing evidence of why one specific autonomous trade was authorized, only that a user configured the envelope the trade occurred inside. This record and the payments evidence record are answering adjacent but different questions, and neither substitutes for the other.

What is genuinely new here, on the evidence available, is how explicitly Binance is reported to frame the choice itself: not a single default with an optional override, but two named, opposite postures, approve every order or trade without asking, offered side by side as a setting a user picks once. Moona Intelligence has not previously covered a mainstream exchange stating that distinction this plainly, even accounting for the fact that the plainest statement of it currently rests on one interview rather than on Binance's own published specification, and that Binance's own MCP Server documentation currently describes only the confirmation half of that stated choice.

That last point is where the comparison with Robinhood sharpens rather than dissolves. Robinhood's own reporting describes a customer funding a dedicated, isolated account and, from that point, letting a connected agent place a real trade inside it with an order preview but without a fresh approval click on each one; a purchase on the Agentic Credit Card gets an approval gate only if the customer turns one on. That is bounded autonomous execution: the human's authorizing act happens once, when the account and its capital boundary are set, and trades proceed inside that envelope afterward. Binance's Agent OS, on the documentation this record could verify, currently does something different for the same category of action: the sub-account is just as isolated and just as dependent on a capital boundary the user sets, but the MCP Server confirms every order, cancellation and transfer with the user before it executes, rather than letting confirmed subaccount access alone carry an agent through repeated trades unattended. Both platforms give an agent real access to real financial assets inside a boundary a human constituted in advance. They currently place the final execution decision in different locations: Robinhood's documented behavior lets isolation and a spending boundary carry the authority to execute, while Binance's documented behavior keeps a person in that decision for every consequential action regardless of the boundary already in place. Whether Binance's own reported intent to also offer an autonomous mode closes that gap is unresolved on the evidence this record could verify, and this record does not treat Li's account of that intent as equivalent to the documented behavior it currently sits beside.

What actually changed, and what still has to be watched

The interesting question this launch raises is not whether a human stays in the loop today, because on the documentation this record could verify, one currently does, for every consequential action. It is whether Binance's own reported intent to let a user instead delegate the boundary in advance, the way Robinhood's documented behavior already does, shows up in a specification or a demonstrated deployment rather than only in an interview. Binance's answer for what currently bounds an agent, as documented, is the subaccount, its configured activities, its granted scope, and the balance the user put into it, confirmed order by order. That is a real, specific, checkable answer, considerably more specific than a general assurance that safeguards exist.

What remains unverified independently of Binance's own statements is whether an autonomous mode exists as a shipped, configurable behavior of the MCP integration at all, distinct from the confirm before execute pattern its own documentation currently describes, and whether the emergency stop and revocation mechanics behave as documented under real conditions rather than only in a controlled demonstration. Those are the claims a future update to this record would need first party technical documentation, or an observed enforcement failure, to move beyond vendor statement and beyond secondary reporting of one interview. Until then, the honest description of Binance Agent OS is the one this record gives: per order confirmation as the documented current behavior, an autonomous mode as a stated but not yet independently verified company intent, and revocation and Emergency stop mechanics described in terms this record credits as far as their own stated language reaches and no further.

The same applies, with even less currently documented, to the provenance question underneath the mechanics: whether the person configuring an agent for capital that is not personally theirs was ever entitled to, and what happens to a trade that was technically permitted but economically unwanted after it has already executed. Binance Agent OS advances the first question, the mechanics of what an agent can be permitted to do. It has not yet answered the second, who was entitled to permit it and what happens when a permitted action goes wrong.