Laxmikant Sharma

[writing]

What Would a Markets Regulator Ask of an Agent?

I tried to file one agent tool call as an order record under the EU trading rules. Of the eighteen fields that apply, six map to something standard and four have no source at all. Those rules have been binding since 2018, and in February the regulator pointed them at GenAI.

[agents][security][governance][agentic-web]

Part 3 of three on agent accountability. The record, then the revocation. This one is about the rules.

Parts 1 and 2 left three technical gaps to consider and one open question. The execute_tool span has two Required fields and none for whose authority the call ran under. The GenAI conventions still have no release and no tag, so nothing on a trace says which version of them produced it. Revocation latency came out as R = min(T_signal, A), and most deployments have no signal. The open question was what joins a decision to the action it authorised, given that the identifier travelling between services is one the caller supplies. I’d filed those as open problems. Then I went looking for whether anyone had solved them for a different kind of autonomous software, and found relevant answers in the technical standards under MiFID II, governing algorithmic trading in the EU since January 2018.

One trace drawn as a waterfall. An invoke_agent span runs the width of the figure and a nested execute_tool span sits inside it. A dashed line marks the moment the authority was revoked, and the tool call sits entirely to the right of it, in the shaded region labelled R equals min of T_signal and A. The attributes hanging off the tool call are gen_ai.operation.name and gen_ai.tool.name, both Required, and gen_ai.tool.call.id, Recommended If available. Below them an empty dashed row reads: on whose authority, no attribute.

So this part works through that rulebook with the agent stack open. I put each article next to the findings it answers, filled in the regulator’s self-assessment form for an agent, and filed one tool call as an order record. The mapping is a script, linked at the end, so you can argue with any line of it. If you’ve worked under these rules, you’ll see what I’ve missed, and I’d like to hear it.

Which rulebook actually applies

Start with the AI Act and there is nothing to work with yet. AI-based algorithmic trading is not on its high risk list to begin with, and the Digital Omnibus deferred the whole high risk regime, record-keeping and log retention along with it.

The markets regulator moved the other way. Its February briefing is below, marked up. Paragraph 46 carries the exclusion, and paragraph 48 points firms at the two RTS 6 provisions. Paragraph 85 sets out the systems it has in mind, GenAI among them, generating signals that get acted on “often directly with no human intervention.”

ESMA’s February briefing, the two paragraphs that matter, taped up with the AI Act’s deferral beside them.

One regulator postponed, then, and the other pointed at a rulebook written before meaningful transformers existed. ESMA is careful about it: the briefing is non-binding and paragraph 48 opens by conceding that neither MiFID II nor RTS 6 addresses AI. What it does is name the hooks. I’d planned to argue that the trading rules were a good template for agents. ESMA made that argument first, inside finance, which leaves the question of how far the shape travels.

Reading it with Parts 1 and 2 open

The rulebook is MiFID II Article 17 and four technical standards made under it and under MiFIR. RTS 6 covers the organisational requirements for algorithmic trading. RTS 22 and 24 say what gets recorded about a transaction and an order, and RTS 25 is the one about clocks. Every finding from Parts 1 and 2 has a paragraph in there waiting for it, so here’s the table first and the walk-through after.

The crosswalk: each Part 1 and Part 2 finding, the article that already answers it, and what the agent stack has instead.

Identity: Part 1 found gen_ai.agent.name: Conditionally Required, a human-readable label the application supplies with no requirement to be unique or stable. There is a gen_ai.agent.version, but it sits on the create-agent and invoke-agent spans rather than the tool call. RTS 22 Article 8(3) requires an algorithm’s identifier to be “unique for each set of code or trading strategy that constitutes the algorithm,” “used consistently when referring to the algorithm or version of the algorithm once assigned to it,” and “unique over time.” A versioned, stable identity for the thing that decided, as law.

Revocation: RTS 6 Article 12 is titled “Kill functionality.” 12(1) requires the ability to “cancel immediately, as an emergency measure, any or all of its unexecuted orders.” 12(3), same article: the firm “shall be able to identify which trading algorithm and which trader, trading desk or, where applicable, which client is responsible for each order.” Attribution sits inside the kill-switch article because a switch with no owner field has nothing to aim at. It is enforced, too. The 2 May 2022 order below cost Citigroup Global Markets Limited £61.6 million across the FCA and the PRA, and the FCA’s share of that came under the rule requiring “effective systems and controls” for algorithmic trading.

The order drawn to scale: the full width is the $444 billion keyed, 57 per cent of it hatched as the notional the firm’s controls stopped, the rest reaching a trading algorithm, and a hairline at the end for the $1.4 billion sold. Below it a logarithmic axis shows the intended $58 million and the amount that got through 3,259 times further along, with the controls accounting for 0.37 of the 3.88 decades between them.

Retention and replay: MiFIR Article 25 requires keeping “at the disposal of the competent authority, for five years, the relevant data relating to all orders and all transactions,” and RTS 6 Article 13(7) requires a system that can “read, replay and analyse order and transaction data on an ex-post basis.” Part 1’s cost section had the vendors’ ceilings. Here they are against the same five years, with the Citigroup gap between the error and the regulator’s account of it marked on the same axis.

Five years drawn as one span, with four vendor retention ceilings measured off the same datum: fifteen days is 0.8 per cent of it, ninety days 4.9 per cent, four hundred days 21.9 per cent, fifteen months 25.0 per cent. A separate marker shows the 746 days between the 2 May 2022 order and the FCA and PRA Final Notices of 17 May 2024, which is longer than all four ceilings.

The join: Parts 1 and 2 left it open, because the context that travels between services is filled in by the caller, and W3C Trace Context’s own security section warns that an attacker could forge trace-id collisions. RTS 25 joins by time instead of by token, so regulators can “reconstruct these events over multiple trading venues on a consolidated level.” The tolerances are below, on one axis with what an agent trace actually reports.

A logarithmic axis from one nanosecond to one second. RTS 25’s fast lane runs from one microsecond of granularity to 100 microseconds of permitted divergence from UTC; everyone else sits at one millisecond for both. The Consolidated Audit Trail sits at 50 milliseconds for electronic events and one second for events entered by hand. The agent lane holds a single point at nanosecond resolution, from the trace timestamps, and an empty band across the whole axis where a bound on clock divergence would go.

Change control: So far, I haven’t seen anyone in the agent world propose it. RTS 6 Article 5(7) requires a record of every material software change capturing “when a change was made; the person that has made the change; the person that has approved the change; the nature of the change.” Every prompt edit, model swap and tool addition is a change to the software that decides, and no standard records who approved it.

The briefing adds the enforcement shape, and it’s the part I’d steal first. Paragraph 51: firms “shall conduct and document the required self-assessment on an article-by-article basis, covering all relevant articles of RTS 6,” stating per article whether they consider themselves compliant. So I filled one in for an agent stack on today’s standards, against the articles that have an analogue. It’s a judgment per row, on the board for you to argue with.

An RTS 6 self-assessment, article by article, filled in for an agent stack built on current standards.

I tried to file a tool call as an order record

The self-assessment is opinion. The order record is arithmetic, so I did that too. RTS 24’s annex lists 51 fields, which a venue must keep for an order insofar as they pertain to the order concerned. I took one agent tool call carrying everything the stack currently standardises: an OpenTelemetry GenAI span, the MCP request, an AuthZEN evaluation with the COAZ binding for MCP, and the token claims. For each of the 51 fields, I asked whether a source exists. The mapping is a script, published below, so every line is a thing you can disagree with.

Thirty-three of the 51 are prices, quantities and order-book state with no analogue for a tool call. Of the 18 that do apply, six are filled by a standard field and eight are filled weakly by something optional, unversioned or unsigned. The four that fail have no source at all: a direct-versus-gateway flag, a sequence number, a routing path, and field 4, investment decision within firm.

Field 4 asks which person or algorithm inside the firm decided to trade, and if an algorithm, under the identifier RTS 22 Article 8(3) describes: unique for the code, consistent across references, unique over time. Nothing the agent stack requires you to record on the call satisfies all three. gen_ai.agent.name is a human-readable label and need not be unique. There is a gen_ai.agent.id, but it sits on the create-agent and invoke-agent spans rather than the call. COAZ-MCP does carry an agent in context, and that agent is the OAuth client_id, which names the application rather than the code that decided.

Field 5, execution within firm, is worth reading beside it. Field 4 may be left blank when no person or algorithm inside the firm made the decision. Field 5 has no such escape: where responsibility is shared, the regulation tells the firm to work out who was primarily responsible and name them anyway. Of the two fields the regulation uses to pin an order on someone, the agent stack fills one weakly and the other not at all.

One cell per RTS 24 field, 51 of them in a row. Six are solid: the token subject, its expiry twice over, its audience, the tool name and the span status. Eight are hatched as weak. Four are drawn hollow and called out by name above the strip: direct versus gateway, investment decision within firm, sequence number and routing strategy. The remaining 33 are dotted, with no analogue for a tool call.

How USA does it

The US answer has a different shape, and it goes at the people rather than the records. FINRA’s 2016 notice, below, requires whoever is “primarily responsible for the design, development or significant modification of an algorithmic trading strategy” to pass the Series 57 exam and register as a Securities Trader. It has been in force since January 2017. The person who writes the algorithm holds a licence and sat an exam. Nobody who ships an agent has either.

The record side is the Consolidated Audit Trail, which joins order events in NMS securities across every US exchange and FINRA member. That is the joined trail Part 1 wished for, deployed at market scale. It is also where the honest bill comes due. The SEC has spent two years taking the most sensitive fields back out of it, first in February 2025 for natural persons reported with transformed tax IDs, then in January 2026 for all customers including legal entities. A joined trail at scale is not free. Anyone proposing one for agents should say that part out loud.

A calendar from 2017 to 2026 with four bands. The Series 57 requirement for the person behind the algorithm runs unbroken from 30 January 2017. The 50 millisecond clock requirement runs unbroken. The customer’s name, address and year of birth run solid until February 2025, hatched through the exemptive relief, then hollow after the January 2026 codification. The transformed SSN or ITIN that ties the person to the order runs solid throughout.

Where the standards bodies have got to

Against all of that, here’s where the agent world’s rulebook stands. The IETF’s agent protocols effort took a draft charter to a working-group-forming BoF in Vienna in July, and the datatracker still reads “Not chartered yet.” At the W3C, three community groups work agent protocols, agent identity and agent memory, a layer each, and they are three of more than a dozen now open. The six specifications from Part 2 are mapped below, one layer apiece, and RFC 8693’s own text marks its chain “informational only” for access control.

Six specifications, but five groups: RFC 8693 and Token Status List are both IETF OAuth documents. Two of those groups are further along than I’d assumed. OAuth’s charter was revised in June to take on authorization of automated agents acting across multiple administrative domains. WIMSE has been chartered since March to bridge OAuth, JWT and SPIFFE, which its charter says “have existed in relative isolation,” and its architecture draft treats AI agents as delegated workloads in which “each hop in the chain MUST explicitly scope and re-bind the security context.” Its audit section requires every authenticated request to “leave a verifiable and inspectable trace,” then lists what a record may include. The trace is required and its contents are not. That is the gap where RTS 24 puts 51 numbered fields.

MiFID II wasn’t one document either. The Commission adopted the four technical standards over seven weeks in 2016, under four separate empowerments across a directive and a regulation, and the change log and the kill switch are two articles of the same standard. What they had was one process: all four came out of ESMA together, were published on the same day in the same issue of the Official Journal, and carry fields 4 and 5 of the order record as the join. That is a governance difference rather than a technical one. Five groups have shipped the agent technology, two are now chartered to work on agent delegation, and none is chartered to say which field is which.

Six columns for the links of one accountable call: who is calling, on whose behalf, what was permitted, what actually ran, what was written down, what survives five years. A seam is drawn between the third and fourth. The OAuth and WIMSE charter bars stop at that seam. The only bar over what actually ran is hatched and comes from the GenAI conventions repo, which has no tagged release. SCITT covers the last column alone. One dashed bar reaches from delegation to retention, and it is the AUDIT BoF request, marked Declined.

That was the state of it when I started reading. Last week it moved. A charter for an IETF working group called AUDIT, for Agent Use of Delegation and Interaction Traceability, went out for review on a new mailing list, with an architecture draft beside it. Its problem statement is the one this series has been circling: logs, tracing systems and authorization frameworks “capture individual aspects of system behavior but lack interoperable support for correlating user intent, delegation chains, authorization state, and resulting actions across domains.” The proposed scope is composition rather than invention, and it names the groups it would compose. One of the four record types in the architecture draft, the Authorization Transition Record, carries previous state, new state, triggering event and responsible actor. Those are RTS 6’s four change-log fields, reached from the other side.

Two things to read before treating it as settled. The BoF request behind it is marked declined, and the note circulating the charter says there is no working group yet and everything in it is open for discussion. The scope also rules out the field this piece has been chasing. The group would not work on new identity primitives, leaving those to other groups, and the architecture draft’s own worked example names the deciding agent agent-42, with no version. Field 4 comes out blank in the newest proposal too.

What a first agent rulebook would say

I don’t think the answer is to apply MiFIR to MCP. The trading rules govern licensed entities in one market structure, and agents are general-purpose. What travels is the shape, and ESMA has already moved it once, from human traders to AI signals inside finance. Move it one step further and most of a first agent rulebook is pointers to things that already exist, plus two things that don’t.

A first agent rulebook as a handwritten list: eight pointers to standards that already exist, then the two things nobody has, with a note that India already issues the join key.

Eight of the ten are pointers, and they don’t need a new specification written. The identity rule is RTS 22 8(3) restated, and the OpenTelemetry conventions could carry it next day! The change log needs no spec at all, only the discipline to write four fields down when a prompt changes.

I feel the row worth arguing about is the last one: ESMA’s annual, article-by-article self-assessment, signed by a named person. That is the mechanism that answers the reviewer’s point from Part 2, about whether the conditions a decision point evaluates still represent reality. The trading rulebook doesn’t assume they do. It makes you re-check, on a schedule, and sign.

The two inventions: A way to prove that a delegated scope only narrowed across hops, and a join key the audited party doesn’t get to choose. Neither exists in any of the six specifications, and the second one isn’t in MiFID II either. RTS 22 Article 8(3) has the investment firm “assign a designation for identifying the computer algorithm,” so the identifier that pins the decision is chosen by the party being audited.

Something caught my eye, India market seems to have closed that gap. A circular SEBI issued in February 2025 requires every algo order to be tagged with “a unique identifier provided by the Exchange in order to establish audit trail,” requires the broker to “seek approval from the Exchange for any modification or change to the approved algos,” and requires exchanges to retain “the ability to use the kill switch for orders emanating from a particular algo id.”

A trust boundary drawn down the middle, the audited party on the left and the party asking on the right. Under RTS 22 article 8(3) the firm mints the designation itself, but it crosses the boundary into a transaction report filed the next working day and kept five years, carrying three conditions: unique per set of code, consistent across versions, unique over time. Under the SEBI circular the exchange mints the identifier and hands it across, and every change to the algorithm goes back for approval. In the agent stack gen_ai.agent.name is set by the caller, is human-readable with no uniqueness rule, and nothing on the far side of the boundary ever holds a copy.

Whatever the agent stack eventually copies, that is the version I’d copy.

The IETF AUDIT architecture draft’s action record beside RTS 24 field 4 and SEBI’s exchange-issued algo id: the delegation chain and the scope are present, the deciding agent has no version, and the trace id is still the caller’s.

Five numbers to leave the room with

The self-assessment format is the useful export, so these are the five rows of it you can fill in this afternoon for your own fleet.

Five checks against the rulebook: agent identifiers unique over time, the four change-log fields, measured clock divergence, retention against five years, and who signs.

Still open on the whiteboard

Three open questions: who the primarily responsible person is for an agent, whether the AI Act’s annual review reaches agents before the markets rulebook does, and whether periodic re-validation is enough to keep a decision point honest.

Three pieces, with one claim across them. The record of an agent’s action has two required fields and none for authority, and the revocation of that authority is bounded by a token lifetime and a set of caches nobody publishes. The rules that would fix both were adopted for trading algorithms a decade ago, applied from 2018, enforced with fines in the tens of millions, and pointed at GenAI by their own regulator this year.

Both gaps close the same way: a group chartered to say which field is which, and a named person who signs the assessment every year. The charter for the first went out for review last week. The second is outside its scope by its own words, and I have not seen anyone else propose it.

The scorecard script is here: the order-record scorecard. Python 3, standard library, no network. The mapping is the whole file, so the argument is in the diff.