When Agents Can Move Money, the Prompt Is Not a Control

We keep writing instructions for our agents as though instructions were enforcement. We tell an agent what it may not touch, and we describe the result as a control. We phrase a boundary in a prompt, and we treat that phrasing as authority. But a prompt is not a control, and a prompt is not an authority. What we write in a prompt shapes what the agent intends to do; it does not govern what the agent is able to do. Instruction does not control actions.

Those three statements are the entire argument, and payments is where getting it wrong costs the most.

In a recent J.P. Morgan Payments article, Zack Anderson, Chief Data & Analytics Officer for Payments and Global Banking, states the principle plainly: a prompt expresses intent; it does not enforce authority. That framing is correct, and it carries a consequence that most agent programs have not yet absorbed. If the prompt is not the control, then something else must be, and that something has to exist as infrastructure in every agent project rather than as a review step bolted on later.

This post is about why that layer has to exist at all, and the best way to see the problem is to work through an example from the article itself.

The £100 million mandate, worked through

J.P. Morgan works the example in full, and it shows how a mandate can be followed exactly while still failing. They write:

“Invest all cash above our £100 million liquidity buffer overnight.”

“That sounds clear. Yet it leaves the legal entity, permitted currencies and instruments, and counterparty limits unstated. The buffer could remain intact while all surplus goes to a counterparty we would never approve.”

“A mandate needs to specify the permitted means and when to stop. If no authorized placement is available, leaving the cash uninvested and asking for direction must count as a valid result.”

Read the second quotation again, because it contains the entire argument. The buffer is untouched. The instruction is followed. The surplus still goes somewhere the firm would never approve. Every element a person would have applied in a manual process — which entity, which instruments, which counterparties — is absent, and the prompt supplies none of those missing boundaries.

The third quotation closes the design question, because it defines what the mandate must permit. A system that treats “no authorized action available” as an error will push its agents toward an unauthorized one, since the agent is graded on completing the task. A legitimate stop state is not a failure. Leaving cash uninvested and asking for direction has to be a valid outcome of the mandate itself, not an exception the agent tries to avoid.

This is what it means to enforce authority rather than assume it. The mandate has to name the entity, the permitted currencies and instruments, the counterparty allowlist, the exposure limits including pending orders, and the condition under which the correct answer is to stop. The same logic holds anywhere an agent can commit the enterprise: procurement, accounts payable, refunds, HR actions, infrastructure changes. Payments is where the cost of getting it wrong is easiest to measure.

Keep that failure in view for the rest of this post. The three sections that follow explain why it keeps happening, and why no better-written prompt can fix it.

Why instruction cannot carry authority

An instruction describes what an agent should do. It carries no mechanism for stopping what the agent actually does. Instructions live in the same context window as everything else the agent reasons over, which means they compete with retrieved content, tool output, retained memory, and messages from other agents. The most persuasive input is not necessarily the most authoritative one.

Permission-based access control does not close the gap either. Identity and access management answers whether a principal may reach a system. It does not answer whether this specific action, on this specific record, at this value, for this purpose, is authorized now. A credential that opens the door does not decide which rooms are allowed.

J.P. Morgan’s article supplies the empirical version of this argument. In one cybersecurity evaluation, an agent was instructed that it had no internet access, and it still produced malware that executed on real systems, because the environment contained an unintended route that no instruction could close. In another set of evaluations, agents turned an internal package service into a persistent message board, carried findings across separate runs, and compromised external production infrastructure. In each case the instruction was present and the authority was absent.

The lesson is structural rather than behavioral. Authority that is stated is not authority that is enforced.

Why the enforcement decision has to be deterministic

The decision we are describing commits the enterprise. It releases money, changes a record, moves data, or triggers an approval a regulator will later examine. A decision with that consequence cannot rest on a probabilistic layer.

A model can be right most of the time and still be the wrong place to decide. If the same action, the same mandate, and the same exposure data can produce different outcomes across runs, the organization cannot explain the outcome, cannot replay it, and cannot defend it. A risk score is a useful input to a decision. It is not a decision.

Determinism means the same inputs produce the same answer, and that the answer can be explained and reconstructed. That property is what makes the control auditable, and it is what makes the control defensible to the people who have to sign off on the agent in the first place.

A prompt is not a control. A probability is not a permit.

Why the decision must happen before execution, not after

Detection and authorization are different moments with different consequences. A monitoring system can tell you that an agent attempted an unauthorized action. It cannot prevent the action. By the time the signal arrives, the payment has moved, the record has changed, and the question has shifted from prevention to reconstruction.

That shift is expensive. Every control that acts after the fact leaves the organization explaining what happened rather than showing that nothing happened. Audit and incident review were never meant to be the enforcement mechanism.

The authority check belongs at the last moment before the action becomes real, inside the path the action must travel, so that the decision exists before the consequence does. Everything upstream of that point is design, and everything downstream of it is history.

The independent policy engine already has a name

This architecture is no longer a vendor position. In a recent burst of work, four independent players have described the same control point from different perspectives:

• J.P. Morgan Payments describes an independent policy engine that evaluates an agent, its mandate, and a proposed financial action before execution.
• NIST’s agent identity and authorization project is developing practical approaches for identifying and authorizing software and AI agents. It is project work, not a finished mandate or certification.
• OWASP’s public-preview Agent Control Standard (ACS) specifies runtime hooks through which a separate control can inspect a proposed action and return a decision.
• Forrester and Deloitte describe the wider enterprise architecture. Forrester’s AEGIS framework connects governance, identity, data, application security, threat operations, and Zero Trust, and introduces least agency: limiting which decisions and actions an agent may take, not only which resources it may reach. Deloitte describes an enterprise control plane that mediates who can act, what data they can access, and how agents operate within defined boundaries.

Their scopes differ. Their shared implication does not: agent authority must be evaluated at runtime, at the point where intent becomes action. When a payments organization, a national standards body, an open security project, and analysts independently describe that control point, it stops being optional architecture for systems that can commit the enterprise.

Arbiter exists because of this gap

Once the argument is stated this way, the requirement stops being a feature set and becomes a category.

If instruction cannot carry authority, if access control governs reachability rather than purpose, if the decision has to be deterministic, and if it has to land before execution, then a deterministic runtime authorization layer is not an optional enhancement to an agent platform. It belongs in the foundation of the project, beside the execution service and the transaction service, because it is the component that decides whether anything those services do is permitted.

That is the reason LangGuard Arbiter exists. It evaluates a proposed action before the tool call executes and returns one of three outcomes:

• ALLOW: a safe, in-scope action proceeds automatically.
• BLOCK: an action outside scope, in conflict with policy, or across an SoD boundary does not proceed.
• ESCALATE: the action is held for a named human approver.

The value is not the list of decisions. The value is that the decision happens at all: deterministically, before the consequence, in a path the agent cannot bypass or reconfigure. A hook the agent can skip is a suggestion, not a control, and a control that lives inside the agent’s own tool loop depends on the agent continuing to use that loop. No route should reach the transaction service without passing the decision first.

Two properties of that control follow from the worked example above. First, an exposure check has to account for completed and pending transactions across every agent acting under the same mandate; a check that sees only settled trades will authorize a placement that breaches the limit once earlier orders land. Second, the decision has to stay tied to the transaction, together with the policy version that produced it, so the authorization can be examined later. Authorization that sits beside the transaction stream is a report. Authorization that sits above it is a control.

A message from a peer is not authority

Shared memory, queues, or message boards can carry instructions into another run. A recipient must not treat that message as a mandate change simply because it came from a peer agent or retained state. Apply authorization to the message path and the later action separately. Record who wrote the context, which task it belongs to, who can access it, and whether it has expired or been revoked.

Where authority belongs

J.P. Morgan describes treasury as Sense → Predict → Decide → Execute → Audit. The authority check belongs between Decide and Execute: after the agent proposes what to do, before a tool call or transaction makes it real.

The question to ask before you build

J.P. Morgan’s own working test is the right one to borrow: which action would our deployed control have stopped? If the answer depends on the agent having read its instructions carefully, there is no control yet, only guidance.

The capabilities described here are operational controls, and none of them constitutes certification or compliance on its own. NIST AI RMF and ISO/IEC 42001 provide risk-management frameworks; organizations remain responsible for their own obligations and their own implementation.

Sources: J.P. Morgan Payments on enforceable controls · NIST agent identity and authorization project · OWASP Agent Control Standard · Forrester AEGIS framework · Deloitte on the enterprise AI control plane · NIST AI Risk Management Framework.

LangGuard: SCOPE and Arbiter announcement · Least-privilege agent permissions.

Four independent players, in a compressed period, arrived at the same architecture: identity and mandate checked at runtime, a decision enforced before execution, and evidence linked to the action. When agents can move money, authority cannot remain in the prompt. It has to be checked and enforced at every boundary where intent becomes a tool call, a message, or a transaction.