Semantic transactions: securing untrusted agent workflows at the OS runtime boundary
SubscribeSign in
Semantic transactions: securing untrusted agent workflows at the OS runtime boundary<br>Trust the system, not the prompt: Securing untrusted LLM tools with transactional boundaries and effect outboxes.
Latent Dynamics<br>Jul 15, 2026
Share
At 2:14 a.m., a reconciliation agent at a regional payments processor opened the night’s vendor remittance batch. Its task was routine: match incoming invoice files against open ledger entries and flag discrepancies for the morning finance team.<br>One remittance file carried a hidden instruction inside an optical-character-recognition memo field. The instruction told the agent to treat an attached routing correction as authoritative. It asked the agent to issue a transfer of $340,000 to a “corrected” account before flagging anything.<br>A standard tool-exposure model has no way to stop this. The agent’s planning loop has no reason to distrust a memo field. It is just text inside a document the agent is authorized to read. Once the agent decides to call a transfer function, a classical runtime dispatches the packet immediately.<br>That is not what happened. The transfer request was generated, but the runtime never sent it. The request sat in an effect outbox as a staged, inactive record, waiting for the full task trajectory to pass validation. A reference monitor traced the transfer’s input back to the untrusted memo field and rejected the trajectory. The outbox record was purged before any packet reached the payment network.<br>This is the working claim behind the semantic transaction model. Agent tool calls are not a series of independent operations that commit the moment they run. A task is one transaction, staged in a shadow copy of local state and an effect outbox, checked against the full trace before anything irreversible happens. Two systems make this claim concrete: the Cordon transaction runtime [1] and Agentic Transaction Processing (ATP), implemented in the Mnemosyne runtime [3].<br>The failure of stateless RPC agent runtimes
Most agent deployments expose databases, filesystems, and external application programming interfaces through direct, stateless remote procedure calls. Each tool call executes in place. It changes host state the moment it runs.<br>This is a version of the dual-write problem, long studied in distributed systems. A service that must update its own state and also notify an external system cannot do both atomically. It needs a coordination mechanism. Microservice architectures solved this with the transactional outbox pattern. A service writes the outbound event into the same database transaction as the local state change, then drains it asynchronously. Most agent runtimes skip this step. A tool call and its side effect are one event.<br>The result is structural blindness to multi-step attacks. Reading a poisoned file looks benign by itself. Writing a command derived from that file also looks benign by itself. Only the combination is dangerous, and a filter that checks one call at a time cannot see the combination.<br>Even without an attacker, stateless execution corrupts state on its own. The AppWorld benchmark evaluates coding agents across nine applications and 457 APIs, populated with roughly 100 simulated users. It checks results with an average of eight state-based unit tests per task, run directly against the underlying SQL databases. AppWorld separates two metrics. Task Goal Completion checks whether one task succeeds. Scenario Goal Completion checks whether a full chain of related tasks succeeds, without breaking state that earlier tasks already established.<br>A GPT-4o agent running a standard ReAct loop reaches 48.8% Task Goal Completion and 32.1% Scenario Goal Completion on the benchmark’s normal split. On the harder challenge split, the same agent reaches 30.2% and 13.0% [2]. A model that solves half its individual tasks completes barely a third of full scenarios. Errors accumulate across steps, and nothing in a stateless runtime rolls them back.<br>Two zero-click injections that model-level filters missed
Two disclosures from 2025 show why a filter running inside the model’s own reasoning cannot be the security boundary.<br>Aim Labs discovered CVE-2025-32711, known as EchoLeak, in Microsoft 365 Copilot. Aim Labs rated it 9.3 on the Common Vulnerability Scoring System. The National Vulnerability Database lists a lower score of 7.5, because its scoring model assumes fewer preconditions are already met [3].<br>The attack arrived as an email containing a hidden prompt, written to bypass Copilot’s Cross-Prompt Injection Attack classifier. When a user later asked Copilot to summarize the inbox, the model read the hidden instruction and retrieved private context along with it. To exfiltrate that context, the hidden prompt told Copilot to format its answer as a markdown reference link split across two lines. Copilot’s output sanitizer did not recognize the split link...