The Dealer Had Permission to Hedge. Your Bourse Let an AI Agent Use It Too.

Every AI trading launch this year has answered the same question about whose money is at stake and who approves spending it. Robinhood answered it for a customer's own brokerage account. Binance answered it for a customer's own exchange subaccount. Your Bourse answered a different question entirely, and the difference is worth being precise about before drawing any conclusion from it.

Your Bourse is not a retail platform. It is infrastructure. Founded in 2017, it builds Trade Server, the backend a broker, prop firm or liquidity provider runs to handle accounts, orders, routing, margin and reporting for its own book of clients. The people who log into Trade Server are not retail customers deciding what to do with their own portfolio. They are the broker's own dealers, risk managers and operations staff, doing their jobs inside the broker's own production infrastructure. On 18 August 2026, Your Bourse opened that infrastructure to AI assistants.

What Your Bourse actually described

Your Bourse's own content hub article, published 18 August 2026 and titled how MCP for Trade Server helps automate trading operations, introduces MCP for Trade Server as a connection that lets a broker link a compatible AI assistant of its choice to Trade Server, and use natural language instructions to query authorized data and initiate permitted actions. Finance Magnates corroborated the same day, in a piece headlined Your Bourse Opens Trade Server to AI Prompts for Hedging and Position Closures, reporting that broker staff can query live data and initiate permitted hedges or position closures. Independent syndication of the same underlying content hub material, through InvestMacro, describes the same capabilities in matching detail. Moona Intelligence treats the content hub article, the Trade Server product page and the reporting on both as one underlying launch, not several independent developments, in keeping with how this desk already treats a single vendor announcement corroborated by press coverage of the same event.

The examples Your Bourse's own material gives are specific rather than generic. A risk manager could request total EUR/USD exposure or a list of accounts in negative equity. A dealer could initiate a hedge or close a position. Operations staff could carry out permitted changes to accounts and groups. That is a broker's internal risk and dealing desk work, made conversational, not a customer facing trading assistant. Reads, such as an exposure query or an account list, appear to execute immediately: Trade Server serves current data at the moment of the request rather than the stale export a manual report would carry.

Inheritance, not a new scope

The central technical claim, and the one this record verifies most carefully, is permission inheritance. Your Bourse's own material states that MCP inherits the permissions attached to the connected user's Trade Server credentials, and that this is a deliberate limit: the assistant does not gain access beyond what that employee's login already carries. Reporting corroborating the same launch is consistent on this point and adds a specific framing worth quoting in substance: MCP adds a conversational route to existing functions rather than a separate set of trading permissions.

That sentence is the whole finding, stated plainly, and it is worth sitting with rather than rushing past. Moona Intelligence found no description, in Your Bourse's own material or in corroborating reporting, of an Agent specific permission object, a scope grant, a narrower role, or any construct that sits between the employee's ordinary Trade Server permissions and what the connected assistant can do. There is no evidence of a subset relationship, the way Grantex enforces that a delegated grant can only narrow, never widen, what a parent token already holds. There is no evidence of an isolated, capital bounded account, the way Robinhood and Binance each wall off an agent's reach to a dedicated balance a customer funds on purpose. What this record found is a single permission surface, the employee's own Trade Server role, and a conversational interface layered directly on top of it. The assistant is not a differently authorized actor. It is the same authority, reached a different way.

That is also the answer, on the evidence available, to whether Trade Server can constrain the agent independently by account, group, book, instrument, position size, exposure, action type, fund amount, time or environment. Ordinary Trade Server role permissions already carry some of those dimensions, account and group access among them, and an MCP connected assistant inherits whichever of those the employee's role already has. Moona Intelligence found no description of a distinct, Agent specific policy layered on top of that inheritance, and does not import Trade Server's ordinary functionality into a claim about Agent specific policy that this record could not independently verify.

Two authority models, kept separate

Your Bourse's own material describes a second, structurally different arrangement that this record deliberately does not fold into the employee case above. A broker running Trade Server, which Your Bourse's own material refers to as its client, may in turn offer MCP enabled access to its own traders, for API tools or AI powered strategies. Reporting on the same launch adds that each broker decides which data and functions its own clients can access through that path.

Read those two sentences side by side and two different authority models emerge, not one extended to cover both. In the employee case, the authority already exists, inside the broker's own organization, attached to a working Trade Server login, and MCP is a new interface onto it. In the retail client case, the broker is the one constituting a new grant, deliberately, for a customer who did not previously hold Trade Server credentials at all. Moona Intelligence found no evidence that Your Bourse's own material collapses these into a single permission system, and this record does not either. What remains unverified is how a broker technically configures the client facing grant, whether it uses the same inheritance mechanism as the employee case or a separately built permission surface, and whether the two paths share any audit or revocation mechanism. Your Bourse's own material does not say, and this record preserves that as undocumented rather than assumed.

Preview, confirmation, and the question of where it is enforced

For any instruction that affects a position or funds, Your Bourse's own material describes a specific sequence: the assistant returns a preview rather than executing the instruction, execution follows only once a person approves it, and Trade Server then records the resulting action the same way it records one completed through its ordinary interface. That sequence, verified consistently across the content hub material and its syndication, is a genuine execution time control, and this record credits it as one: a person, not the model, makes the final decision on the specific instruction in front of them.

What that sequence does not establish, and what Your Bourse's own material leaves open, is where it is enforced. The Model Context Protocol, the open connection standard Your Bourse is building on, defines a general mechanism called 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 whichever client and host application the broker's employee chose to connect. It is not, by itself, a guarantee the server can compel independently of that client's behavior. Nothing in the material reviewed for this record states whether Trade Server itself refuses to execute a position or fund affecting instruction that arrives without a completed confirmation step, or whether the preview and approval Your Bourse describes is, in practice, a pattern the connecting assistant is expected to follow rather than a boundary Trade Server enforces on its own. Moona Intelligence does not treat a model instructed to seek confirmation as equivalent to a boundary the receiving system enforces independently of that model's behavior, and preserves this as APPROVAL ENFORCEMENT LOCATION UNKNOWN rather than assuming server side enforcement the evidence does not establish.

A cluster of further questions about that confirmation step is also not resolved by any material this record could verify. Whether the confirming person must be the same authenticated employee whose credentials initiated the instruction, or could be a different person with sufficient Trade Server permission, is not stated. Whether an approval binds to the instruction's exact parameters, so that a changed size, instrument or account after the preview would require a fresh approval, is not stated. Whether a pending preview expires, whether it covers one action only, and whether several proposed actions can be approved together as a batch, are all not stated. Whether the approval itself exists as a durable artifact separate from the resulting Trade Server action, rather than being inferred after the fact from the action alone, is not stated either. Each of these is preserved here as unknown, not inferred from what would be a reasonable design.

What actually executes, and what does not

On the evidence Moona Intelligence could verify, three categories of behavior are documented, and a fourth is not. Reads, such as exposure queries and account listings, execute without a described approval step. Position and fund affecting instructions, hedges, closures, account and group changes, generate a preview and require human confirmation before proceeding. Confirmed instructions are then executed and recorded. What is not documented anywhere this record could verify is any consequential operation executing without that human confirmation step, unattended, once permissions are configured. That is a meaningful absence to state plainly: Your Bourse's own material does not claim autonomous execution for position or fund affecting instructions, and this record does not either. Moona Intelligence also does not claim, and found no basis to claim, that a connected assistant can independently execute every Trade Server API capability. The material reviewed describes specific examples, exposure queries, hedges, position closures, account and group changes, and this record does not generalize beyond them to a broader claim about Trade Server's full API surface.

What the audit record actually is

Your Bourse's own material states that a confirmed action is recorded in Trade Server the same way an action completed through the ordinary interface would be. That is a real and useful property: an MCP initiated hedge does not disappear into a separate, less visible log. It is also, on the evidence available, an ordinary action log, not a distinct authorization decision record. Nothing this record found describes the resulting audit entry as separately identifying the employee whose credentials were used, the AI assistant or MCP connection involved, the instruction as originally proposed, the human confirmation as its own linked event, and the final executed action, as four connected facts rather than one resulting entry. Moona Intelligence does not call an ordinary Trade Server action log an authorization decision record merely because the action behind it happened to be confirmed through MCP, and preserves the distinction here rather than rounding an activity log up into an evidentiary chain the material does not describe.

The Authority Provenance ledger

Moona Intelligence separates what Your Bourse's launch technically permits from what it establishes about who was entitled to grant that permission, the same discipline this desk has already applied to Binance Agent OS and to Grantex's delegation protocol, rather than letting a documented technical control stand in for a fully proven chain of authority.

Authority grantor. Documented only at the level of a working Trade Server login. The immediate authority an MCP connection uses is whatever the authenticated employee's own Trade Server credentials already carry, whether that employee is a dealer, a risk manager or operations staff. This record does not collapse that authenticated employee identity with the broker organization's own ultimate authority. Your Bourse's material identifies who is logged in. It does not identify, beyond that, who at the organization is the principal ultimately responsible for the resulting instruction.

Mandate or basis. Undocumented. A working Trade Server credential proves the employee has technical permission to reach certain data and functions. It does not, by itself, establish that the broker organization, a compliance function, a risk manager, or any other legitimate principal separately authorized that specific employee to connect an AI assistant to those credentials in the first place. Moona Intelligence found no material from Your Bourse describing an approval step, a policy acknowledgment, or any other organizational gate an employee passes through before connecting an assistant, distinct from simply having a working login. This record preserves that gap as undocumented rather than inferring an approval process a broker's own internal policy might or might not require.

Delegated scope. Documented as pure inheritance rather than a separate grant. The connected assistant reaches whatever data and functions the employee's existing Trade Server permissions already cover, and reporting corroborating the launch specifically frames MCP as a conversational route to existing functions rather than a separate set of trading permissions. Moona Intelligence found no evidence of an Agent or MCP specific scope object distinct from the employee's ordinary role.

Explicit limits. Not established beyond whatever account, group, instrument or other constraint the employee's existing Trade Server role already carries. No material reviewed here describes an Agent specific limit on position size, exposure, fund amount, time of day or operating environment applied independently of that employee's ordinary permissions. This record does not import Trade Server's general functionality into a claim about Agent specific policy the evidence does not support.

Inherited permissions or assumptions. This is the central finding. The connected assistant is documented as receiving the full set of permissions the authenticated employee already holds, mirrored rather than reduced. Moona Intelligence found no evidence of attenuation, a subset relationship, a separately configured role, or tool specific permissioning distinct from the employee's own access. Authority here appears to mirror the human principal rather than narrow relative to them, and this record does not infer attenuation the material does not describe. Separately, and kept apart deliberately, a broker may configure independent MCP enabled access for its own retail clients, under permissions the broker itself defines, which this record treats as a second authority model rather than an extension of employee inheritance.

Revocation or modification. Undocumented. No material reviewed here describes what happens to an agent's effective authority when the underlying employee's credentials are revoked, their Trade Server role changes, or the MCP connection is disconnected, whether that change takes effect immediately or on the agent's next action. Equally undocumented is what happens to a pending preview or an already given confirmation if the employee's permissions change between the preview and the execution step, or what becomes of an in flight session at the moment any of those changes occur.

Challenge authority. Documented only as the pre execution confirmation itself, and worth stating precisely rather than generously. A person confirming a specific proposed instruction before it executes demonstrates that a human re entered the decision at the moment that mattered. It does not, by itself, establish that the confirming person was the legitimately entitled principal for that specific institutional trade, and it is not a mechanism for a third party, such as a compliance function or a risk oversight role, to contest an instruction's underlying legitimacy separately from the binary act of approving or declining it in the moment. No material reviewed here describes such a separate challenge channel.

Recovery path. Undocumented, and external to what this record could verify as Agent specific. Your Bourse's own material describes no dedicated handling for an incorrect hedge, a duplicate execution, an erroneous instruction traced to the assistant, or an emergency disable specific to an MCP connected session, distinct from whatever ordinary account and position management Trade Server already offers any user. Moona Intelligence does not treat an ordinary offsetting trade as a documented reversal mechanism for this feature, because no material reviewed here frames it that way.

Provenance evidence quality. Uneven, and worth stating in parts rather than as one number. What is well documented: that the assistant inherits an existing employee's Trade Server permissions rather than receiving a separate grant, that position and fund affecting instructions generate a preview requiring human approval before executing, and that the resulting action is recorded in Trade Server. What is undocumented: any organizational mandate behind an employee's decision to connect an assistant, any Agent specific limit distinct from the employee's ordinary role, where the confirmation step is technically enforced, who may supply that confirmation and under what constraints, what happens to authority and to pending actions when credentials or roles change, any challenge mechanism beyond the pre execution approval itself, and any Agent specific recovery process. The strongest evidence in this launch is about what an agent inherits and about a person's ability to stop a specific proposed instruction before it executes. The weakest is about who was entitled to authorize the underlying delegation, and what happens once a confirmed, executed instruction turns out to have been the wrong one.

Why this is a different case from Robinhood and Binance, not a smaller one

Robinhood opened Agentic Trading and the Agentic Credit Card to a customer's own connected agent, inside a dedicated account the customer funds on purpose. Binance opened Agent OS to a customer's own connected agent, inside a dedicated subaccount isolated from the customer's main holdings. In both cases, the human principal and the account being acted on are the same person, and the platform's own architecture creates a fresh, bounded envelope specifically for the agent to operate inside.

Your Bourse's launch is not a smaller version of that pattern. It is a different one. The account being acted on is not a customer's own holdings. It is the broker's own production infrastructure, reached through an employee whose job already includes hedging exposure and closing positions on the firm's behalf. Nothing is created fresh for the agent to operate inside. The agent operates inside exactly the same permission surface the employee already had, because that is precisely what inheritance without attenuation means. That is the distinctive contribution this record credits Your Bourse's launch with: institutional permission inheritance, an AI assistant reaching a broker's own operational infrastructure through an employee's existing authority, rather than a customer directing an agent inside their own bounded account. It is also why the undocumented mandate question matters more here than it does for a retail customer connecting an agent to their own money. A customer delegating authority over their own account answers, by definition, whether they were entitled to delegate it. An employee delegating authority over a firm's operational infrastructure does not answer that question by having a working login. Somebody else in the organization is supposed to have a view on that, and Your Bourse's own material does not describe one.

The question this launch actually raises

Robinhood and Binance each answered a version of who gets to decide once an agent can act inside a bounded account a customer chose to expose. Your Bourse raises a different question, upstream of that one: when an institutional employee connects an AI assistant using credentials the organization already gave them for their own job, does that employee's technical permission automatically become delegated machine authority over the firm's own infrastructure, or does something else have to happen first that nobody has yet documented.

Access permission, delegated agent authority and a human confirmation immediately before execution are three separate facts, and this launch keeps only the third one visible. The first two, whether the employee was entitled to hand their permission to software, and what, precisely, that software then holds, remain exactly where this record found them: undocumented.