How an investment policy statement becomes a constraint set an agent cannot argue with. The rails that now let AI agents place real orders expose almost no risk controls; the broker with the deepest control surface won't let an agent trade at all. Nobody has connected the two. This piece specifies the layer that should sit between them — and lets you run it.
Interactive Brokers has the richest pre-trade risk control surface available to a retail investor anywhere: price collars, total-value limits, size limits, tick-based fat-finger checks, separate ceilings for algorithmic orders. In July 2026 it opened an MCP endpoint to every major AI client. Its announcement is explicit about what the agent may do with it: "In this release, the client reviews each instruction and converts it to an order on an Interactive Brokers platform before it is submitted." Agent output lands in a review queue. The agent can analyse, research, monitor and draft; it cannot execute.
Note the hedge — "in this release." IBKR has described a property of the current version, not made an architectural commitment, and it would be wrong to read it as a permanent design stance.
Robinhood, Alpaca, Coinbase and eToro let an agent trade. Between them we could not find a single documented position cap, order notional cap, order rate limit, daily loss limit, drawdown circuit breaker, cooling-off period, or restricted-instrument list.
The broker with the controls doesn't allow execution. The brokers that allow execution don't have the controls. That is the whole gap this piece is about, and closing it is not a research problem — every component already exists in production somewhere.
One control does exist, at three of the four rails, and it is worth naming precisely because it is doing all the work: a segregated account funded with an amount the user chooses. Robinhood's agent "receives only funds deposited into dedicated account." eToro's agent operates in "a dedicated sub-portfolio." Coinbase offers isolation as an option rather than a default. This is a loss cap implemented as a balance ceiling — genuinely useful, entirely static, and blind to everything that happens inside the account. It cannot distinguish a considered position from a corrupted one. It caps how much you can lose, not how you can lose it.
Two structural details deserve more attention than they have received.
Order review and order placement appear to be two separate tools. Third-party MCP directories consistently document review_equity_order — "simulate an equity order and return pre-trade warnings" — alongside place_equity_order, with nothing documented that requires the first before the second. Robinhood publishes capabilities rather than tool schemas, so this rests on third-party enumeration, and an absence of documented sequencing is not proof that the server enforces none.
Robinhood's own phrasing points the same way: "Be aware that if you've asked your agent to take action without asking your approval, it can place trades without your confirmation." Approval reads as a property of what you asked your agent rather than a setting the broker holds. In fairness, the dedicated agentic account is a real out-of-agent control, and it is the one structural safeguard in the design.
Alpaca's MCP surface exposes update_account_config. The account's trading configuration — including suspend_trade, the closest thing to a kill switch on any retail agentic rail, and no_shorting, and the margin multiplier — is a tool the agent can call. The control plane is inside the agent's reach, with no confirmation step and no destructive-action gating — the kill switch is writable with the same ceremony as reading a quote. In fairness, the server defaults to paper trading and live trading requires explicitly setting a flag. But the architecture is the point, and we will return to why placing the controls inside the agent's own tool surface is the one design choice a fifteen-year-old SEC rule already forbids in the human case.
FINRA retired the pattern day trader rule effective 4 June 2026. Regulatory Notice 26-10 replaced the day-trading margin requirements "in their entirety," eliminating the day-trade count, the pattern-day-trader designation, the $25,000 minimum equity requirement and the day-trading buying power calculation. In their place is a continuous intraday margin standard requiring customers to hold equity "commensurate with the amount of market exposure they have at any given point in time during the trading day."
Be precise about what changed: the four-times day-trading buying power multiplier was abolished, not made available at a lower threshold. The $2,000 floor that remains is the long-standing general margin-account minimum, not a new leverage bargain. And the amendments were approved by the SEC in April 2026 — long in the pipeline, and unrelated to anything agentic.
What matters here is effect rather than intent. The PDT rule was never designed as an AI control, but it functioned as the hardest behavioural throttle on retail account turnover — a bright-line cap on round trips in a small account. Its replacement tests margin solvency continuously, which constrains leverage rather than frequency. The coincidence of timing with the agentic launches eight days earlier is just that, a coincidence. The consequence is not: the one accidental rate limit in the retail stack was retired in the same fortnight the stack acquired something that can trade without getting tired.
On 1 August 2012, Knight Capital deployed new code to eight servers and missed one. A repurposed feature flag reactivated dormant order-routing logic on the eighth. In roughly 45 minutes the firm lost, in the SEC's words, "over $460 million."
Two details from the SEC's order matter more than the headline, and both are usually told wrong. Knight's systems did generate 97 messages to staff before the market opened — but as the order puts it, Knight "did not design these types of messages to be system alerts, and Knight personnel generally did not review them when they were received." They carried an error string, not a diagnosis. The failure was not that a warning was ignored; it was that the firm had no alerting design at all, so the messages amounted only to a "potential opportunity" to catch the problem. That is a harder failure to fix, and a far more common one.
And the response that made things worse was subtler than "they pushed the bad code everywhere." Engineers uninstalled the new code from the seven servers where it had deployed correctly. The dormant Power Peg logic was already sitting on all eight; the new code had been suppressing it. Removing the new code un-masked a defect that had been present everywhere the whole time.
Every element of that failure has a direct analogue in an agentic trading deployment: a configuration change nobody validated, an automated system operating far outside intended parameters, alerts firing into a void, and a response that amplified the fault. The regime that followed is the closest thing to a working specification for what should sit between an AI agent and a market.
The Market Access Rule requires a broker to maintain controls "reasonably designed to manage the financial, regulatory, and other risks" of providing market access. Two of its requirements read as though they were drafted for this problem:
"Prevent the entry of erroneous orders, by rejecting orders that exceed appropriate price or size parameters, on an order-by-order basis or over a short period of time, or that indicate duplicative orders."17 CFR 240.15c3-5(c)(1)(ii)
Note "or over a short period of time." The rule already understands that a control checking one order at a time is insufficient — that the dangerous pattern is often a sequence of individually unremarkable orders. This is the single most important sentence in the rule for anyone building an agent control layer, and §04 lets you watch it matter.
But the paragraph that should govern agentic design is the one about who holds the controls:
"The financial and regulatory risk management controls and supervisory procedures described in paragraph (c) of this section shall be under the direct and exclusive control of the broker or dealer that is subject to paragraph (b) of this section."17 CFR 240.15c3-5(d)
Staff guidance makes "control" concrete. Answering a question about whether an affiliate may hold the controls, the SEC's Market Access FAQ states the broker must have "the ability to directly monitor, and the exclusive ability to adjust, as appropriate, the operation of the financial and regulatory risk management controls in real time." Third-party tooling is permitted, but only where the firm retains that exclusive adjustment authority, and mere representations of vendor independence are explicitly insufficient diligence.
Two caveats belong with that. It is staff guidance rather than rule text. And paragraph (d) is not absolute: a broker may allocate control over specific regulatory controls to a customer that is itself a registered broker-dealer, by written contract and after due diligence. The financial controls cannot be allocated at all, and responsibility never transfers either way.
Three portable requirements fall out: real-time observability, exclusive adjustment authority, and non-delegable accountability. You may outsource the tooling. You may not outsource the control. Set that against an MCP surface where the agent can call update_account_config, and the design defect is not subtle — the entity being constrained holds the constraint.
Worth studying as a mechanism. The rule contains no clause prohibiting unfiltered market access. It requires that controls "prevent the entry" of non-compliant orders by rejecting them, and the Commission then derived the architecture from the outcome. Addressing the credit and capital threshold controls specifically, the adopting release reasons that because those controls must prevent entry by rejecting orders, "the broker-dealer's controls must be applied on an automated, pre-trade basis, before orders are routed to the exchange or ATS." Which, as the adopting release states, "will necessarily eliminate the practice of broker-dealers providing 'unfiltered' or 'naked' access."
Naked access died as a structural consequence of a mandatory checkpoint in the path, not as a prohibition. That is precisely the move an agentic regime would need to make, and precisely the move no regulator has yet made. Note also FINRA's most common real-world finding on this rule: not missing controls, but limits "set at unreasonable thresholds based on a firm's business model" — thresholds so wide they never bind. A constraint that never binds is indistinguishable from no constraint, and it is much harder to notice.
An investment policy statement is prose. A constraint engine consumes numbers. Everything in this piece depends on the translation between them, so it is worth stating plainly what that translation is and is not.
We looked for one. FIX covers the instruction to trade, not the permission to hold — there is no mandate message type. FpML represents derivative trades and lifecycle events. ISO 20022's investment funds messages cover subscriptions, redemptions, statements and reference data; the investment policy appears there as narrative text, meaning the standard carries the prose rather than the constraint. ISDA's Common Domain Model formalises trade lifecycle events. None of them has a mandate object. Academic attempts exist — a fund regulation ontology, a handful of conference papers — with no industry uptake.
The absence is more interesting than it first appears, because the industry has not been waiting for a format. It solved the problem with labour instead. Charles River ships more than two thousand sample rules and sells a rule-writing service. BlackRock employs people whose job title is compliance rule coder — human beings who read mandate prose and emit machine-readable rules. An entire vendor niche exists to maintain traceability links from each coded rule back to the sentence of the original document that justifies it, with projects tracked at over ten thousand individual mapping tasks.
That traceability product is the tell. It exists because the mapping from prose to rule is many-to-many, contested, and auditable only by provenance. And a rule coded in one vendor's language cannot be exported to another's. There is no portable representation of what a portfolio is allowed to do.
| Failure mode | Example | What an engine can honestly do |
|---|---|---|
| Underspecified scalar | "Appropriate liquidity," "adequate cash reserves" | Import a convention — Rule 22e-4 buckets, a stated days-to-liquidate ceiling — and get sign-off. The number becomes the engine's, not the mandate's. Every such default is an unbooked interpretive liability. |
| Ordinal without a scale | "Moderate risk tolerance" | No accepted mapping exists. Observed practice puts the same word anywhere from 8% to 14% volatility. Force resolution at onboarding into an explicit tuple — volatility ceiling, tracking-error cap, drawdown trigger, beta band — and record it as a versioned interpretation with a named approver. |
| Predicate over an unobservable | "Prudent diversification," "quality investments" | Nothing. Prudence is a standard of conduct, not of outcome — a portfolio can pass every numeric diversification test and be imprudent. Compute diagnostics, assert documentation, do not claim compliance. |
| Compound goal with no trade-off rate | "Long-term growth with capital preservation" | Two objective functions and no exchange rate between them. The only well-posed reading treats preservation as a hard floor and growth as the objective — which is to say, a drawdown trigger. Anything else requires the client to pick a point. |
| Authority and timing ambiguity | "Without Investment Committee approval," "the CIO will take appropriate steps," rebalancing "need not occur immediately" | These convert hard constraints into workflow constraints. The engine needs a first-class waiver object — grantor, scope, expiry — or it will report violations the mandate itself blesses. |
The last row is the one most engine designs miss, and it is the one that determines whether anybody keeps using the system. An engine that fires alerts a mandate has already excused will be switched off within a quarter.
Suitability practice separates a client's ability to bear risk — objective, derived from horizon, wealth relative to liabilities, income stability — from their willingness to bear it, which is subjective and questionnaire-derived. Where the two conflict, the lower governs. The manager may educate; the manager may not act on the higher figure.
For an engine this is not a nuance, it is an arithmetic instruction: the risk ceiling is min(ability, willingness), never a blend. It is worth stating because a naive implementation — and a naive optimiser — will average two numbers that must not be averaged, and will produce a ceiling the mandate never authorised.
Below is a working pre-trade constraint engine. The portfolio is a specimen institutional mandate — $250M, eleven synthetic instruments, a deliberately simplified single-factor risk model. The constraints on the left are the compiled mandate. The scenarios fire sequences of orders at it, including several drawn from documented attacks on trading agents.
The engine evaluates every order against post-trade portfolio state, in sequence, and reports the binding constraint. Try to get something through.
| # | Order | Notional | Verdict | Binding constraint |
|---|---|---|---|---|
Select an agent behaviour above to run it against the mandate. | ||||
The split order is the one to run twice. Twelve orders of $4M each, every one comfortably inside a $5M per-order notional cap. With state evaluation on, the cumulative issuer and sector limits catch the sequence within a few orders. With it off — each order checked against the portfolio as it stood at session open — every single order passes, and the agent ends up with a position the mandate forbids, having never breached a single per-order rule.
That is not a hypothetical bug. It is the natural implementation if you build the control layer as a stateless order validator, which is exactly what a naive pre-trade check looks like, and it is why the Market Access Rule says "on an order-by-order basis or over a short period of time." Per-order controls and portfolio-state controls are different controls. Shipping only the first is the most likely way to build something that looks like a shield and is not one.
The other scenarios map to documented behaviour. The concentration run reproduces what researchers observed when they prompt-injected a trading agent: maximum single-position concentration went from 39% to 99.98%. The churn run reproduces the same attack's other signature — trade count from 47 to 391 — and is caught not by any risk limit but by a rate limit, which is the cheapest control in the entire stack and exists at no retail agentic rail. The volatility escalation reproduces the state-tampering result, where a procedural agent's maximum drawdown went from 1.6% to 92% and position utilisation reached 647% of capital.
A constraint is not a number. It is a number plus five other things, and omitting any of them is how control layers fail in production. Every rule needs: a metric with a stated computation, a threshold, an evaluation point in the order lifecycle, a breach action, and an owner who can waive it — with the waiver itself an object that expires.
// A constraint, fully specified. The threshold is the least interesting field. { id: "CONC-ISSUER-01", source: "IPS §4.2, sentence 3", // provenance — non-optional interpretation: "INT-2026-014", // the coded reading, versioned + approved metric: { fn: "issuer_weight", basis: "post_trade", // pre- vs post-trade portfolio lookthrough: "fund_exempt", // how pooled vehicles are treated aggregation: "parent_issuer" // the hard part — see below }, threshold: { op: "<=", value: 15.0, unit: "pct_nav" }, evaluate_at: ["pre_trade", "eod_batch"], on_breach: "BLOCK", // BLOCK | WARN | ESCALATE | LOG waivable_by: "CIO", waiver: null, // { grantor, scope, granted, expires } passive_breach: "GRANDFATHER" // drift vs. purchase — see below }
Provenance. Which sentence of which document authorises this rule. Without it you cannot answer the only question that matters in an examination — why is this number 15 — and you cannot safely change it, because nobody knows what it was protecting. This is precisely why the vendor traceability products in §03 exist.
Interpretation version. The rule is not the mandate; it is a reading of the mandate. When "moderate risk tolerance" becomes a 2.5% tracking-error cap, someone made a judgment. That judgment needs an identifier, a date and an approver, because it will be questioned later and because the same prose will be read differently by the next person.
Passive-breach semantics. Rule 22e-4's illiquid limit is instructive: it is a purchase prohibition, not a holding cap. Drifting above 15% illiquid because prices moved is not a violation; buying more is. Most real mandate constraints have this structure, and an engine that treats drift and purchase identically will either block legitimate rebalancing or fire alerts nobody can act on.
Issuer aggregation. The concentration test is trivial arithmetic on a weight vector and nearly impossible to get right in practice, because the unit is the issuer family — parent, subsidiaries, guarantors — which requires a maintained issuer hierarchy. This is a leading source of silent under-reporting in real compliance systems, and it is a data problem rather than a rules problem. Part III's argument about the data layer returns here in a sharper form.
| Metric | Computation | Evaluation point | Notes |
|---|---|---|---|
| Issuer / sector weight | w_i, or the sum over a group, post-trade, as a fraction of NAV | Pre-trade block | Cheap, deterministic, unambiguous. Do these first — they are the checks most likely to catch a catastrophic order and they cost almost nothing. |
| Tracking error | TE = sqrt(x'Σx) with x = w_p − w_b, annualised. Exact post-trade form: sqrt(x'Σx + 2x'ΣΔx + Δx'ΣΔx) | Pre-trade block | Cache the risk gradient Σx once per risk-model refresh and each what-if becomes cheap. Never ship a TE limit alone — see the row below. |
| Total volatility | σ_p = sqrt(w'Σw), annualised | Pre-trade block | Must be paired with the TE limit. Portfolio variance decomposes as σ_p² = σ_b² + 2w_b'Σx + x'Σx; the cross term means a TE-constrained optimiser can raise total risk while satisfying its TE cap. Jorion's remedy is an explicit total-volatility constraint alongside the TE limit. Its cost, in his Table 2, runs 0.01 to 0.42 percentage points of expected return per percentage point of volatility reduced — 1 to 42 basis points, not a rounding error. His argument is comparative: those ratios sit below an intrinsic information ratio of 0.50, so you surrender less return per unit of risk than the manager's own skill ratio implies. |
| Value at risk | Parametric: VaR_α = z_α · σ_p · sqrt(h) · NAV; z = 1.645 at 95%, 2.326 at 99% | What-if advisory and end-of-day batch; hard block only for regulatory limits | Not sub-additive, so a blocking gate is defeatable by order splitting. Latency and overnight covariance staleness make it a poor pre-trade primitive. Use marginal VaR as the pre-trade proxy. Always carry (α, h) with the number — a VaR limit without both is meaningless. |
| Days to liquidate | DTL_i = Q_i / (PR × ADV_i), with PR the assumed participation rate | Pre-trade block | Specify the ADV window — 20-day is common for equities, three-month for less liquid names — and the participation rate, where 20–30% is the standard band and stress work uses 5%. Both are free parameters and both move the answer materially. |
| Order notional and rate | Per-order value; order count over a rolling window | Pre-trade block | The two cheapest controls in existence, and the two most conspicuously absent from every retail agentic rail. The rate limit is the only defence against churn, which no risk metric detects. |
| Drawdown trigger | Peak-to-trough on portfolio value against a floor | Continuous monitor → ESCALATE | Deliberately not a pre-trade block. This is a state machine rather than an order test: a breach changes the mandate's operating mode. Its known pathology is path dependence — mechanical de-risking sells the low and ratchets exposure down through a whipsaw. |
Run the cheap deterministic checks first — set membership, then order notional, then rate, then weights — and the expensive covariance work last. That is not only about latency. The first binding constraint is what gets returned to the agent and written to the log, so ordering determines the explanation a human later reads. An engine that reports "tracking error exceeded" when the actual problem was a buy in a restricted name has told the truth and communicated nothing.
The engine in §04 evaluates in exactly that order, which is why the blunt concentration scenario reports the notional cap rather than the four risk limits it also breaches.
A constraint set is a specification, and an agent instructed to maximise anything will find its boundary. This is not a hypothetical property of future systems; it is the documented behaviour of current ones, and it changes what "the constraints held" means.
Researchers at Shanghai AI Laboratory built a testbed for attacking LLM trading agents across four surfaces — market intelligence, strategy formulation, portfolio state, and execution. The results are worth stating precisely because they define the shape of the threat. Under prompt injection, an adaptive agent's total return fell from 7.81% to 0.89%, its Sharpe ratio from 5.72 to 0.29, its maximum single-position concentration rose to 99.98%, and its trade count went from 47 to 391. Under state tampering, a procedural agent's return went from 0.91% to −61.02%, maximum drawdown from 1.59% to 91.97%, and position utilisation to 646.86% of capital. Under tool hijacking the authors document a case of "portfolio hallucination": in the illustrated example the agent believed it still held nine shares it had sold weeks earlier, and chose inaction — what the paper calls "strategic paralysis." That is a single qualitative case study rather than a measured aggregate, and the failure it shows is paralysis rather than runaway trading.
Three design conclusions follow directly.
The failure signature is concentration plus churn, together. Both of the headline numbers — 99.98% and 391 trades — came from the same single attack. An agent that has been manipulated does not drift; it converges hard onto one position and trades furiously getting there. That is a highly detectable signature, and it is detectable by the two cheapest controls in the stack. A position cap and a rate limit, neither of which requires a risk model, would have blunted the most severe documented attack on a trading agent.
Position utilisation above 100% is the tell that the control plane was compromised, not merely the strategy. No correctly-implemented constraint layer permits 647% utilisation regardless of what the agent proposes, because that is arithmetic on the account rather than a judgment about the portfolio. Any deployment where such a number is reachable has its controls inside the thing being controlled — which returns us to update_account_config.
Portfolio hallucination means the agent's belief state cannot be trusted as an input to the constraint check. The engine must compute from custodial position data, never from the agent's account of what it holds. This sounds obvious and is routinely violated, because reading state from the agent's context is faster and simpler than reconciling to the book of record.
The formal literature on safe reinforcement learning has a construct that fits this architecture well: a shield that sits between a policy and the environment, filtering proposed actions against a specification and substituting a safe alternative when the policy proposes something that would leave the safe set. The guarantee is attractive: safety holds regardless of what the policy does, including if the policy is adversarial, badly trained, or optimising the wrong objective.
It is worth being honest about how much of that guarantee transfers. Shielding results are proved over a known model of the environment with a formally specified safety property. An LLM agent trading real markets has neither: the environment model is a covariance matrix estimated from a trailing window, and the safety property is a compiled reading of a prose mandate. What transfers is the architecture, not the proof. The deterministic layer still catches what the stochastic layer proposes, and still does so regardless of why it was proposed — hallucination, injection, reward hacking or ordinary error are indistinguishable to it, which is exactly the property you want. But nobody should claim a guarantee. The shield is only as good as the constraint set, and the constraint set is an interpretation.
The institutional vocabulary above is richer than a retail agentic account needs. Most of it presupposes a benchmark, a risk model and a mandate document, none of which a self-directed retail account has. But the subset that does apply is small, cheap and almost entirely absent.
| Control | Needs a risk model? | Retail relevance | Robinhood | Alpaca | Coinbase | eToro |
|---|---|---|---|---|---|---|
| Segregated funded account | No | The loss cap. Genuinely useful and genuinely static. | Yes | No | Optional | Yes |
| Position size cap | No | Directly addresses the documented concentration failure. | No | No | No | No |
| Order notional cap | No | Catches the blunt error and the fat finger. | No | No | Announced | No |
| Order rate limit | No | The only control that detects churn. Cheapest in the stack. | No | No | No | No |
| Daily loss limit | No | Converts a static balance cap into a dynamic one. | No | No | No | No |
| Restricted instrument list | No | Set membership. Trivial to implement. | No | Shorting only | Announced | No |
| Broker-enforced order approval | No | The control everyone assumes exists. | Client-side | No | No | No |
| Kill switch | No | Manual disconnect exists everywhere. Automatic triggers exist nowhere. | Manual | Manual | Manual | Manual |
| Volatility / VaR / tracking error | Yes | Largely inapplicable without a mandate and benchmark. | not applicable to self-directed retail | |||
Read the column of "No" against the first column of "does this need a risk model." Every missing control is one that requires no risk model, no benchmark, no covariance matrix and no mandate document. They are arithmetic on an order and a balance. The reason they are absent is not that they are hard; it is that no one has required them and no incident has yet forced the question.
Coinbase is the closest to shipping them, and its language is instructive: "Soon, you'll also be able to set exact rules: maximum trade size, what it can interact with, how much it can spend." Future tense, as of August 2026. It is also the only rail that frames the control correctly — "think of it like giving a gift card rather than handing over your bank account" — while currently offering isolation as an option rather than a default.
Nowhere, precisely. FINRA's 2026 report enumerates the risks well — agents "acting autonomously without human validation and approval," agents that "may act beyond the user's actual or intended scope and authority," misaligned reward functions that could lead an agent to optimise decisions "that could negatively impact investors, firms or markets." Note that the first two describe the shipped default architecture of two named products. But its guardrail language is four open questions: firms should consider how to establish control mechanisms and where to put a human in the loop. No control is specified.
IOSCO published a supervisory toolkit in May 2026 that is "not intended to be a binding or prescriptive guide" and described agentic AI in financial products as mostly "in the proof-of-concept phase" — a characterisation that was 27 days from being overtaken by a production launch. The Financial Stability Board's June sound practices note that agent actions may be "difficult or impossible" for humans to override or remediate, and suggests treating agents as "synthetic employees." Eight members of Congress asked the SEC in June whether existing law suffices; the SEC's published 2026 regulatory agenda, issued two weeks later, contains no AI item at all.
The most candid official statement comes from the Bank of England:
"Relying on a human in the loop for all agent actions is unlikely to be realistic."Sarah Breeden, Deputy Governor, Bank of England — ECB Forum on Central Banking, Sintra, June 2026, proposing market-wide circuit breakers for AI-driven trading
That is a deputy governor conceding that the primary control every platform relies on does not scale, and reaching instead for a market-wide backstop. It is the opposite end of the stack from a segregated retail account, and the distance between the two is the space this piece has been describing. The only binding pre-trade regime remains Rule 15c3-5, written in 2010 for human and rules-based order flow.
A constraint set is code, and untested code that has never blocked anything is indistinguishable from code that cannot block anything. Six things to do, in order of how much they are worth.
update_account_config on an agent-callable MCP surface does not have.| Item | Status |
|---|---|
| A standalone Robinhood agentic trading agreement | No such document located. Terms appear as disclosure text on product and support pages plus the general customer agreement. Absence is suggestive, not confirmed. |
| Whether agent order approval has a broker-side default setting | Our reading of the documentation is that no broker-side setting exists at all — approval is a property of the MCP client and the user's prompt. One secondary source claims a default of "off." We treat "no broker-enforced approval gate exists" as the defensible claim and the default as unverified. |
| The Foster–Sherman letter's 13 enumerated questions | Press release only, which paraphrases into four themes. The letter PDF was not retrievable. |
| Share of Alpaca volume attributable to agents | Directional only. Growth of roughly 4× quarter-on-quarter is company-reported and attributed to AI; no clean percentage exists. Do not quote one. |
| Any published pre-trade constraint layer for an autonomous investing agent | None found, from any vendor, platform or institution. The published institutional guardrails belong to a non-executing assistant; the institutional systems that do execute publish no constraint layer at all. This appears to be genuine white space. |
| Any incident involving an AI agent placing erroneous trades at a regulated brokerage | None found as of 2 August 2026. Several circulating claims trace to low-quality sources and are not repeated here. |
| Percentage-of-ADV precautionary limits at Interactive Brokers | Not present in the precautionary-settings documentation retrieved. We do not assert it exists. |
| Robinhood MCP tool schema | No official Robinhood document enumerating tool names was located. The review_equity_order / place_equity_order split is documented consistently by third-party MCP directories only, and §01 is worded accordingly. |
A correction to Part I of this series: it listed Point72's Turion as an AI-managed strategy. Turion is an AI-themed fund investing in the AI supply chain — human-run, thematic, long/short. It uses AI tooling but is not an agentic deployment, and it should not have been characterised as one.
Part V takes up the other half of the control problem. This piece specified the deterministic layer — the part that does not care why the agent proposed something. Part V is about the stochastic layer: how you establish that a model behaves acceptably before it is allowed to propose anything at all. Evaluation design and what a finance-specific eval suite has to contain, backtest hygiene including deflated Sharpe ratios and combinatorial purged cross-validation, champion–challenger promotion, shadow deployment, drift monitoring, and treating a foundation-model version bump as the model change that FINRA already says you should be tracking.
The two halves answer different questions. The shield answers "what can this thing do to me." Validation answers "should it be here at all."
tool_registry.py and specs/trading-api.json, verified at repository level for the update_account_config tool and the suspend_trade / no_shorting / max_margin_multiplier fields