A prompt is not a mandate

The first version of this idea was too simple.

Bloomberg reported that JPMorgan strategists tested eight AI-powered asset-allocation agents against a traditional 60/40 portfolio. Across roughly two decades of in-sample simulations, the best reportedly exceeded the benchmark by 0.7 percentage point a year with lower volatility. This was not live autonomous trading. Still, it made me wonder whether investment infrastructure, built for people and conventional trading algorithms, would need a different authorisation model when an AI agent began choosing the calls.

My initial intuition was that APIs approve one request at a time while an agent acts across a sequence. That would make each call look valid even if the complete sequence moved beyond what a person intended.

Finance has dealt with sequence-level risk for years.

Financial systems already handle aggregate limits, repeated execution, partial fills, cancellations, suitability across a series of transactions, algorithm attribution, kill switches, and reconciliation. The more interesting problem appears one layer above those controls:

How do we preserve a machine-verifiable relationship between a human mandate, an adaptive plan, deterministic risk decisions, asynchronous execution, and a reconciled outcome?

That relationship is easy to lose. A prompt is ambiguous, and an access token can be far broader than one workflow needs. Meanwhile, the model may revise its plan as market and order state change underneath it. One instruction can become several partially filled orders, leaving the system to decide whether the next retry is safe or a duplicate.

The primitive I would build is not a larger permission token. It is a mandate-to-outcome control loop.

This is not a claim that the industry has ignored delegation. Most of the pieces already exist. I am testing how they might fit together for one deliberately narrow product: an internal, low-frequency rebalancing agent at a regulated investment firm, operating inside one trust domain with a restricted instrument set and an existing order management system. It is not a high-frequency trading architecture, and it does not describe systems at my current or future employer.

Finance has already seen the sequence problem

Before designing something new, it helps to recognise what the current system already gets right.

The UK Financial Conduct Authority’s suitability guidance contains an unusually direct example. COBS 9.3.2G says that a series of transactions can be unsuitable because of its frequency even when each transaction is suitable on its own. The unit of judgment is not always one order.

European algorithmic trading rules are also explicitly stateful. Commission Delegated Regulation (EU) 2017/589, usually called RTS 6, requires controls over price, order value, volume, message rates, repeated automated execution, and strategy positions, including time-window controls and immediate inclusion of submitted orders in applicable limits. It requires firms to identify the trading algorithm and the trader, trading desk, or client responsible for each order, provide kill functionality, and reconcile internal records against venues, brokers, clearing members, and other partners.

The FCA’s 2025 review of algorithmic trading controls found that all reviewed firms had pre-trade controls, often implemented at an internal gateway before an order could leave the firm. ESMA’s 2026 supervisory briefing also warns that many small AI recalibrations can accumulate into a material untested change, and that outsourcing does not transfer accountability. In the United States, the SEC’s Market Access Rule requires broker-dealers with market access to use preset thresholds and erroneous-order controls, restrict systems to authorised persons, and send immediate post-trade execution reports to appropriate surveillance personnel.

These controls do not form one universal legal baseline. Duties vary by service, instrument, client, and jurisdiction. I use them as engineering evidence that finance already reasons across sequences.

OMSs generally preserve lineage within an order chain. The design gap I am interested in is the link back to the mandate, plan, and policy decision, then forward to the outcome that consumed the authority.

What the agent changes

A conventional algorithm can also act quickly, make many requests, and cause correlated failures. An AI agent is not the first system that needs limits or oversight.

What changes is the planning boundary.

An ordinary application normally turns a known product action into an API request through deterministic code. With an agent, a probabilistic system may interpret an open-ended goal, choose tools, create intermediate objectives, recover from errors, and alter its route as new information arrives. The same high-level instruction can produce different action sequences.

That does not make the model malicious. It makes the plan less stable than the authority under which it operates.

Consider the instruction: “Reduce risk without realising more than £3,000 in losses before the market closes.” It contains a goal, a constraint, and a deadline. It does not identify the affected accounts, instrument universe, treatment of open orders, market-data freshness, approval threshold, permitted venues, or what to do after a partial fill. It is useful planning context. It is not an authorisation policy.

The system needs to keep several identities separate:

• The client or institution whose assets are affected.
• The regulated entity that remains accountable.
• The person or policy that delegated the task.
• The agent application and its running workload.
• The agent session, model, prompt, and configuration used to form the plan.

The runtime can be bound to a cryptographically verifiable workload identity. The model itself usually does not have one. Model and prompt versions belong in provenance, while the authenticated runtime belongs in the security subject.

This distinction matters because a firm cannot treat the model as the accountable party. Delegation records who may act and within which bounds. It does not transfer the firm’s responsibility.

The pieces are already here

The architecture does not need a new security vocabulary from scratch.

OAuth Rich Authorization Requests, RFC 9396, can represent fine-grained rights as structured data. Its payment example includes an amount, currency, creditor, and action. The standard also makes an important limitation explicit: there is no standard mechanism for deciding whether two arbitrary domain-specific authorisation objects represent more or less authority. Investment constraints therefore need their own comparison and policy semantics.

OAuth Token Exchange, RFC 8693, distinguishes delegation from impersonation. It can preserve both the subject and the actor. FAPI 2.0 provides a high-security OAuth profile designed with financial APIs in mind, including sender-constrained access tokens.

Even those protections have boundaries. The FAPI 2.0 Security Profile notes that DPoP does not sign an HTTP request body or most headers. An attacker who obtains the access token and a reusable proof may be able to replay it with a changed amount or destination. For an investment workflow, a permit should therefore be bound to the exact canonical order plan, not only to the caller and endpoint.

The UK Open Banking Variable Recurring Payments model provides a valuable product analogy. A customer can establish durable consent with a fixed payee, per-payment and cumulative limits, time windows, expiry, and revocation. Future payments can proceed inside those constraints without a new authentication ceremony every time. The VRP data model turns those controls into typed fields.

Google’s evolving Agent Payments Protocol offers another adjacent pattern. It uses mandates, a trusted user surface, deterministic verification, cryptographic binding to checkout content, and signed receipts. In its autonomous mode, a user approves open constraints and an agent later presents a closed mandate for a specific checkout. This is commerce rather than portfolio management, and the specification is still evolving, but the shape is useful: translate open intent into a closed, verifiable action, then return evidence of the outcome.

The IETF OAuth working group’s current Transaction Tokens draft carries short-lived, immutable transaction context across service call chains. It is promising vocabulary for internal propagation, but it is an Internet-Draft, not a final standard. The draft also states that its tokens are not replay-resistant by themselves and are designed to last minutes or less. A durable market workflow can outlive such a token.

Together they suggest a division of labour. Tokens can carry narrow identity and context. A stateful investment service must own changing limits, order state, and reconciliation.

A control loop, not a bigger token

The design has eight stages. The agent participates in proposing intent and, depending on the product, a candidate plan. It does not control the binding of authority, the risk decision, the reservation, or the authoritative account state at closure.

1. A versioned mandate

The mandate is a durable, revocable resource. It is closer to an Open Banking consent record than to an access token.

It identifies the accountable parties, affected accounts, permitted intents and instruments, cumulative limits, approval thresholds, validity window, and policy and revocation versions.

The mandate should contain both per-action and cumulative constraints. “No order above £2,000” and “no more than £10,000 of new exposure today” answer different questions.

Sensitive suitability information does not need to travel in every token. The durable record can retain it, while downstream services receive only the claims they need to enforce.

2. Typed portfolio intent

The model should propose a typed objective rather than issue raw broker calls.

An intent might be rebalance, invest_cash, reduce_risk, raise_cash, or harvest_losses. It should include the target portfolio change, deadline, acceptable drift, portfolio and market-data snapshot versions, expected turnover and costs, and provenance for the agent configuration that produced it.

A human-readable rationale helps review. It never grants authority.

Typing the intent is a product decision as much as an engineering one. It creates a stable surface for approval, explanation, policy, simulation, and failure messages. It also forces the product to define what it actually supports instead of exposing an unrestricted “do anything” tool.

3. A canonical order plan

A deterministic planner, or deterministic validation of an agent-produced plan, converts intent into explicit proposed actions. The hash only helps if both sides encode the economic fields identically, so a real implementation needs a canonical schema and fixed representations for money and quantity.

If human approval is required, the trusted approval surface displays the material facts and binds the approval to that exact plan hash. A material change creates a new version. The system must never show one plan and execute another.

This is the boundary between a useful explanation and an enforceable object. Natural-language rationale can be reviewed. Canonical economic fields and permitted tolerances can be verified exactly.

4. Deterministic policy and risk evaluation

The policy engine evaluates mandate scope, applicable account restrictions and suitability controls, holdings, cash, open orders, worst-case exposure, cumulative turnover, restricted lists, market-data freshness, venue rules, and approval requirements.

It should return a structured decision such as:

{
  "decision": "APPROVAL_REQUIRED",
  "reason_code": "CUMULATIVE_NOTIONAL_THRESHOLD",
  "mandate_version": 7,
  "policy_version": "2026-07-12.3",
  "plan_hash": "sha256:…",
  "required_approval": "authorised_role"
}

The reason code matters. “The agent failed” is not a useful operational message. A user, support team, or engineer needs to know whether the plan was outside the mandate, based on stale state, waiting for approval, or blocked by unavailable capacity.

This first evaluation can power a preview or approval screen. It must not become a stale voucher. When the system is ready to issue a permit, it revalidates the mandate version, plan hash, bound approval, state-dependent controls, and remaining capacity, then commits the final decision and reservation together. Otherwise a change between evaluate and permit creates a time-of-check to time-of-use gap. The authorised role may be the client, portfolio manager, risk officer, compliance function, or another role defined by the service.

5. Atomic reservation

My first design put the remaining headroom inside the signed permit. The two-worker example below killed that idea.

Assume a mandate has £10,000 of remaining headroom. Two agent workers each request £6,000 at the same instant. If both hold a self-contained token that says “£10,000 remains,” both can pass a local check and jointly commit £12,000.

An idempotency key does not solve this. It helps a service recognise the retry of one action. RFC 9110 is careful about retrying non-idempotent methods such as POST, and an idempotency mechanism still cannot stop two different valid actions from spending the same shared budget.

The system needs an atomic reservation against the mandate and account state. Permit issuance and reservation should be one atomic conditional state transition. A serialisable transaction is one way to implement it. The £10,000 example is one dimension; a production reservation is closer to a worst-case capacity vector across cash, notional, turnover, concentration, leverage, open orders, and frequency.

Once an order has been submitted, permit expiry must not release the reservation. The reservation follows the live order until an authoritative terminal state. A request to cancel is not a terminal state because a fill can arrive while cancellation is pending.

Plan-level reservations need their own terminal states. If a plan expires, is superseded, or is abandoned, the service releases only the capacity covering actions that were never submitted. Capacity attached to a submitted or ambiguous order remains reserved until its authoritative order state is terminal.

6. A short-lived execution permit

After the decision and reservation, the system issues a narrow permit for the next action.

It references the mandate version, plan hash, policy decision, reservation, exact allowed action, audience, authenticated workload, expiry, one-time identifier, and any bound approval.

I would issue one permit per state-changing command or plan leg, not one reusable bearer permit for an entire mutable plan. The multi-order plan remains the reviewed object, while each permit binds the action index and canonical payload. A partial fill can then stop the next action without pretending the earlier one never happened.

The permit should be short-lived, audience-bound, sender-constrained, one-shot where practical, and unable to broaden the parent mandate.

For an internal first version, I would use an opaque permit that references the control-plane ledger. Portable signed tokens become worth the added complexity when independent verification is needed across trust boundaries.

For the first version, an agent cannot mint or attenuate a permit for another agent. Every acting workload obtains its permit from the central authority service. Agent-to-agent and cross-domain delegation remain later design problems.

7. Existing execution rails

The control plane should not rebuild the order-management layer.

FIX already models order chains, cumulative and remaining quantities, replacements, cancellations, rejections, and corrections. Its Execution Report distinguishes the quantity executed for a chain of orders from the quantity still open. The FIX order-state scenarios show why a fill can arrive while a cancel or replacement is pending.

The agent layer adds mandate_id, intent_id, plan_id, decision_id, reservation_id, and permit_id above the existing OMS identifiers. One stable action ID maps to one order command. A logical-order ID identifies the wider chain, while new orders, cancellations, and replacements receive distinct client order identifiers linked through OrigClOrdID.

The gateway still performs final safety checks before mapping the action into the OMS. A plan hash detects mutation only if a trusted control-plane component anchored it and the enforcement point sits below the potentially compromised tool.

Permit consumption, the durable action record, and an outbox event should be written in one local transaction. The adapter sends from the outbox. This does not make the venue exactly once. It makes the internal action durable before the uncertain network boundary, so a worker can retry with the same action identity and reconciliation can resolve an ambiguous acknowledgement. Execution reports should enter through an idempotent inbox or equivalent projection.

8. Reconciliation and closure

A successful API response is not a completed investment outcome.

Reconciliation compares the original mandate, typed intent, approved plan, orders accepted, fills and corrections, fees, cash movements, positions, settlement, and the final policy state. The result is a closure record or an exception that requires investigation.

Standards such as W3C Trace Context and PROV-DM help with correlation and provenance vocabulary. They do not turn ordinary traces into tamper-evident audit evidence.

Authority consumption must update incrementally as orders are accepted, filled, cancelled, or corrected. A fill settles the corresponding reservation into actual portfolio and limit deltas in the same state transition. Depending on the side, instrument, and settlement policy, that may consume turnover, create exposure, reduce concentration, or change cash headroom. Terminal unfilled quantity releases only the corresponding reservation; ambiguous order state releases nothing. Reconciliation detects divergence in that accumulated state and drives an explicit repair or exception workflow rather than being the first time a fill becomes visible. Closure can therefore be staged as EXECUTION_RECONCILED, BOOKING_RECONCILED, and SETTLEMENT_RECONCILED. Capacity may change after a fill, well before final settlement. Exceptions can freeze future activity, and the next decision starts from authoritative state.

Failure is part of the product

Authorisation limits what an agent may do. It cannot prove that an in-scope action is wise or uncompromised. That still requires narrow tools, trusted data, anomaly detection, and meaningful approval boundaries.

The user experience should expose these states clearly. APPROVAL_REQUIRED, STALE_PORTFOLIO, NO_CAPACITY, and MANDATE_REVOKED are different situations. They imply different recovery actions. Good infrastructure gives the product enough information to explain that difference without revealing sensitive internal policy.

Approval design deserves special care. Asking a person to approve every order creates fatigue without necessarily increasing safety. A better product asks for approval at meaningful boundaries: a new mandate, an expanded scope, a material plan change, a threshold breach, or an exception the agent cannot resolve. The screen should show what changed, which constraint triggered, how much headroom remains, and which exact plan is being authorised.

Cancel and kill paths should remain independent of the main planning service, but cancellation is not automatically risk-reducing. Cancelling a hedge can increase net exposure. Cancel commands still need identity, stable action IDs, current state, and an emergency policy that distinguishes reducing gross activity from increasing residual risk.

Why the simpler versions break

There are at least four reasonable alternatives.

Existing OAuth scopes plus OMS controls are the smallest change. They may be enough for tightly bounded internal agents. Their weakness is broad credentials and weak mandate-to-intent provenance.

A self-contained capability token is portable and can be verified offline. Its weakness is stale dynamic state. Revocation, concurrent spending, large claim sets, and partially completed workflows all push the system back toward online state.

A central mandate and policy ledger can provide strongly consistent limit updates and immediate revocation checks. Used alone, it can couple every service to one availability and latency boundary.

Human approval for every action is easy to explain. It also scales badly, encourages blind confirmation, and weakens the value of bounded autonomy.

The hybrid is more complex for a reason. The ledger owns changing authority and cumulative constraints. The permit carries the narrow next action. The OMS owns execution state. Reconciliation turns external outcomes back into authoritative internal state.

The API I would start with

The product can remain small even if the model underneath is rigorous.

POST /mandates
POST /intents
POST /intents/{id}/plans
POST /plans/{id}/evaluate
POST /decisions/{id}/approve
POST /plans/{id}/authorise
POST /plans/{id}/cancel
POST /plans/{id}/actions/{index}/authorise
POST /actions
GET  /actions/{id}
POST /actions/{id}/cancel
GET  /intents/{id}/outcome

This API separates proposal, preview, authority, and effect. POST /intents does not trade. POST /plans/{id}/evaluate produces a non-binding decision preview. POST /plans/{id}/authorise revalidates current state, atomically commits the final decision and worst-case plan reservation, and issues only the first action permit. POST /plans/{id}/cancel releases only the uncommitted portion of that reservation. Capacity attached to a submitted or ambiguous order remains governed by its order lifecycle. Later legs are authorised individually through POST /plans/{id}/actions/{index}/authorise against updated order and portfolio state. POST /actions consumes a permit into a durable action record and returns its identifier, not a promise that the market outcome is complete.

The exact boundary can change. These invariants should not:

1. The agent cannot grant itself authority.
2. Every risk-creating effect is linked to one mandate and one evaluated plan. Emergency cancel and kill actions instead link to the affected orders and the governing emergency policy.
3. Shared limits are reserved before an external commitment.
4. Retries reuse action identity rather than creating authority.
5. Partial outcomes remain visible to the next decision.
6. Revocation blocks future authority without pretending to reverse history.
7. Reconciliation closes the original intent or raises an explicit exception.

Those invariants are more valuable than a particular token format.

How I would judge the pilot

The first pilot should optimise for control quality, not agent volume. I would measure duplicate external effects, attempted effects outside the mandate that reached execution, leaked or oversubscribed reservations, reconciliation exceptions, and lineage reconstruction time. A replay suite of adversarial scenarios would test policy false negatives before live use.

The most important success test is simple: given one surprising fill, can an authorised reviewer reconstruct the accountable party, mandate version, model provenance, approved economic plan, policy decision, reservation, exact order command, external execution events, and resulting constraint state without joining evidence manually across several teams?

Where the argument stops

Three boundaries matter. A signature can prove integrity and possession of an approver-bound key; it cannot establish suitability. Idempotency gives stable retry behaviour, not exactly-once execution across an external venue. Revocation can stop future authority, not reverse a completed fill.

The controls should also scale with consequence. A read-only assistant does not need the architecture of an autonomous execution system.

Close the loop

Agents do not make existing financial infrastructure obsolete. They make its boundaries more visible.

An agent may be useful for turning an objective into a candidate plan. That does not make it the right place to enforce authority. The control loop should still answer five questions after every action:

1. Who was accountable?
2. What authority existed at that moment?
3. Which exact plan was evaluated?
4. What did the external system actually do?
5. How did that outcome change the remaining authority?

A prompt cannot answer those questions. A generic access token cannot either.

That is the job I would give a mandate-to-outcome control plane.