Introducing REA ControlPlane: cost, policy, and runtime control in one hop.

REA ControlPlane operates in that gap.

Bring your own model key. REA does not host your model or bill you for vendor tokens. It sits between your agent and the model vendor and applies cost control, a declared-policy check, runtime enforcement, and an audit receipt on a single request path.

Your agent makes the decisions. REA controls the boundaries.

LoopGuard identifies repeated code by structure, not by the wording of the prompt. Incoming code is parsed into an abstract syntax tree and reduced to a 64-bit structural hash. Comments and whitespace do not create a new identity. Two loops with different wording and the same structure match.

A new structure is probed in a Firecracker microVM. If the code is still running when the probe's time budget ends, REA stops it before the vendor is called. The caller receives a normal completion. The assistant text says the model was not called and includes the structural hash. The status is BLOCKED_TIMEOUT.

Once that structure has been stopped, a later match is served from cache. The cache stores the stop, not the vendor's answer, and the cache hit does not create a new vendor call.

A structure that finishes, or crashes, is not that stop. The first time, the model can still be called. If the sandbox cannot run the probe, the status is SANDBOX_BUSY, the code check is skipped, and the request can still be forwarded. REA does not claim a universal savings percentage. What is saved is the structures that were stopped.

PreFlight checks the rules you declared before a request reaches the vendor. It reads the declared-path headers, not the prompt:

• X-PF-Protect
• X-PF-Declared-Paths
• X-PF-Declared-Targets

A secret marker on a declared path is a refusal. The caller receives HTTP 403, task_refused, reason protect.prod-secrets. No model text is generated, and no vendor request is made. The console keeps the decision and the rule. It does not keep the prompt.

If PreFlight cannot decide, the caller receives HTTP 503 and the request is not processed. That is an enforcement failure, not a verdict on the call.

Built-in markers apply until the key saves its own list. An empty saved list matches nothing. A secret that appears only in the prompt is not this check. A secret marker on a declared path is PreFlight. A tool name is TraceGuard.

A clean call continues, on the same hop, to LoopGuard and TraceGuard.

The tool list belongs to the key. You choose the tool names it may use and lock the list. A key can keep 10 lists. Applying a saved list locks that list for the next run. Until a list is locked, tool calls are recorded and not stopped.

The first use of a tool that is not on the locked list is Direct. The call is not stopped, and the tool is not removed. The same tool again, in that session, is Contain. That one tool is blocked for the rest of the session.

Contain is also two other cases, and they are not the same action. An egress path the key was not given blocks that egress class. The first attempt to leave the sandbox freezes the session's tools, network, and sandbox. The model is still called. The hop stays up.

Kill is the next step in a session that was already contained. A second attempt to leave the sandbox, or a secret-shaped call after that session was contained, wipes the session's tools, egress, and sandbox. Wiping is not a freeze. Kill is not a 403, and it does not end the request.

On that reply, rea_meta.tg_action is stripped. A client that shows only the assistant text does not show Contain or Kill. The console records the step: Observe, Direct, Contain, or Kill, with the tool name, the class, and the signal. The receipt does not store the message or the tool arguments.

Two failures do return an HTTP error, and neither is a verdict that the call was malicious. If the tools cannot be removed from that request, the caller receives HTTP 403, reason TG_STRIP_UNSUPPORTED. If enforcement is on and the checker cannot run, the caller receives HTTP 503.

A refused request ends before the vendor. Contain and Kill do something else. They change what the session can do, and the request continues.

Contain is the narrower step. A repeated tool is blocked. An unauthorized egress class is blocked. The first attempt to leave the sandbox freezes tools, network, and the sandbox. Kill is the later step: the session's tools, egress, and sandbox are wiped, not frozen. Neither action is a vendor refusal. Neither is a 403. Neither ends the hop.

The person in the chat sees the model's reply. The console is where the step is named.

A request follows one path: PreFlight, then LoopGuard, then TraceGuard, then the model vendor.

PreFlight applies the declared rule before the request is forwarded. LoopGuard checks the structure and probes a new structure when the sandbox can run it. TraceGuard records the tool activity and, once the list is locked, enforces the session.

Only a request that is still going forward becomes a forwarded call. A PreFlight refusal never becomes a vendor request. A LoopGuard stop never becomes one either. TraceGuard can let the model answer while the unauthorized tool, egress, or sandbox capability is taken off the session.

A forwarded call is one request REA sends to the vendor. A request stopped or refused before that is not counted, and it does not create a vendor call.

REA does not replace your model, your vendor, or your agent framework. You bring your own model key. The vendor relationship stays yours. REA is the control layer between the agent and the model: cost, declared policy, tool permissions, and the session boundary. The receipt records the step without the message and without the tool arguments.

LoopGuard, PreFlight, and TraceGuard are included on every plan. Contain and Kill are TraceGuard. There is no add-on for them.

Your agents decide what to do. REA ControlPlane governs what they are allowed to do.

The controls are PreFlight, LoopGuard, and TraceGuard. Later letters are listed on the letter page.