Risk controls an LLM cannot override

An AI agent that can place orders can also place the wrong one. Not because it is reckless, but because it is a language model. It works from a context window that can go stale, it can fire the same tool call twice, and it can be steered by text it reads mid task. Telling the model to be careful adds a sentence to a prompt. It does not add a limit the software cannot cross.

The fix is not a better prompt. It is to move the risk decision out of the model entirely and put it in a place the model cannot reach.

Why a prompt is not a control

A prompt lives inside the thing you are trying to constrain. Anything expressed as instructions to the model can be overridden by other instructions to the model: a jailbreak, a prompt injection buried in a data feed, or simply a long conversation where the earlier guidance falls out of context. If the only thing standing between an agent and a 40 lot is a line of system prompt, then the limit is advisory.

A control lives outside the model. It does not ask the agent to behave. It checks the order the agent produced and refuses the ones that break a rule. The agent can propose anything. The engine still only allows what fits your limits.

The threat model of an agent with order access

These are the failure modes a hard control has to survive:

• Size and symbol typos. A misplaced digit turns a 2 lot into a 20 lot. A cap on contracts per order refuses it.
• Stale context. The agent acts on a position it already closed, or a session that already ended. Position caps and the trading window refuse it.
• Duplicate tool calls. A retry or a loop fires the same order twice. Duplicate protection and per-minute rate caps refuse it.
• Runaway loops. An agent stuck in a cycle tries to spray the book. Rate limits and the kill switch stop it.
• Prompt injection. Text in a data source tells the agent to flatten and reverse. The engine does not read prompts, so it does not care what the text said. It checks the order against your rules.

Where the control has to live

In PitBridge, the guardrail engine is a pure, deterministic function. Given an order, the account state and the clock, it returns allow, block with a reason code, or require confirm. It performs no network calls and holds no model. Every order the agent sends over MCP or the local REST API passes through the same frozen pipeline, and no code path reaches the account without it.

What "cannot override" means in practice

• Rules load from a config file. The agent has no tool to read it and no tool to write it.
• Arming a live account is a command line ritual. It is deliberately not exposed as an agent tool.
• Un-arming the kill switch is command line only. An agent cannot re-open a bridge you closed.
• Changing a limit changes a config checksum that is written into the audit log, so a silent edit leaves a trace.

None of this promises a profit or a passed evaluation. It promises something narrower and checkable: the software refuses orders that break the limits you set, and it tells you why.