Cordon’s Core Idea: Semantic Transactions
Many agent runtimes still treat tool calls as a sequence of isolated RPCs:
The agent requests a tool → the runtime checks or approves it → the tool executes immediately → the result is returned to the context.
This interface is convenient, but it gives the runtime the wrong security boundary. Many risks are not obviously dangerous within any single tool call. They become dangerous only when several seemingly normal steps are combined.
The paper presents the example of an incident-diagnosis agent that:
- Reads application logs.
- Runs a command to summarize the incident.
- Writes a remediation note.
- Sends the summary to the on-call Slack channel.
Each step appears reasonable on its own. Reading logs supports troubleshooting, running commands is routine, and writing a note and posting to Slack are both consistent with incident-response workflows. But if the logs contain an API key, the later summary is derived from those logs, and that summary is ultimately included in a Slack message, the risk does not lie in whether one individual step violates policy. It lies in the entire chain:
secret-bearing log → derived summary → Slack message
The real question is whether this entire task execution should be committed.
Cordon proposes the concept of a semantic transaction.
It borrows the intuition of database transactions, but the transaction no longer consists of a few database writes. Instead, it encompasses the tool intents, result provenance, local state, external side effects, authority, and recovery evidence associated with an agent task.
A semantic transaction binds together:
- Tool intents: Which tool operations the agent intends to perform.
- Result lineage: Where each result came from and what downstream operations it influenced.
- Staged local state: Local writes, deletions, and configuration changes that are staged before being applied.
- Pending external effects: Messages, API calls, and network requests that have not yet been released.
- Delegated authority: The scope of authority granted to the current task.
- Audit and recovery metadata: What happened, why an action was allowed or denied, and how the system can recover from failure.
How a Semantic Transaction Works
The paper models a semantic transaction as a task-level commit protocol. In plain terms, it has three phases.
Step 1: Prepare
Tool intents generated by the agent enter the transaction. Reversible local changes—such as writing or deleting files and modifying configuration—first enter staged state. External effects, including Slack messages, API requests, and network transmissions, first enter a pending effect set.
Step 2: Validate
The system evaluates more than the final payload. It considers lineage, authority, staged state, and pending effects together. For example: Was a Slack message derived from a log containing secrets? Was a configuration write triggered by untrusted input? Does a proposed deletion set exceed the policy threshold?
Step 3: Commit or Abort
If the transaction is valid, local state is promoted to the real workspace and external effects are released. If it is invalid, staged local state is rolled back, pending external effects are blocked, and an audit record is retained.
Three Core Mechanisms
1. Result Lineage: Track Where Results Come From
Cordon treats tool outputs, file contents, command output, summaries, temporary artifacts, and candidate final responses as result objects. Each result object carries provenance and dependency edges. Risk assessment therefore goes beyond checking whether a string contains an API key. It asks:Was this outbound content derived from a sensitive result?
This covers cases that conventional DLP systems or regex-based secret scanners may miss, including summarization, encoding, rewriting, and information carried across turns.
2. Shadow State: Keep Local Changes Out of the Real Workspace Until Commit
Local changes produced when an agent writes or deletes files or runs commands first enter transaction-scoped shadow state. Later steps within the same task can see these speculative changes, but the real workspace does not expose them before commit. If validation fails, the shadow state can simply be discarded. If validation succeeds, it is promoted into the real workspace.
3. Effect Outbox: Hold External Side Effects Before Release
Local files can be rolled back, but the external world is much harder to reverse. Once an email or Slack message has been sent, a webhook called, or an API update applied, the system cannot pretend it never happened.
Cordon therefore places external effects in an effect outbox. An effect is released only after the transaction has passed validation and the appropriate authority has been confirmed.
This reflects Cordon’s clear boundary model: it does not claim that it can recall an effect already observed by the outside world. Instead, it stages effects whenever possible before release.
Runtime Architecture: A Transactional Control Plane at the Tool-dispatch Boundary
Cordon does not require the entire agent to be rewritten. It inserts a transactional control plane at the tool-dispatch boundary.
This position is important: the tool name, parameters, resource path, and target sink have already become concrete, but the actual file mutation, network transmission, or service update has not yet occurred.
At runtime, Cordon creates or restores the transaction context for the current task. This context records:
- Semantic intents.
- Result objects and lineage.
- Staged writes and deletions.
- Pending external effects.
- Authority and approval obligations.
- Audit and recovery evidence.
The validation engine consumes this context and decides whether to commit, abort, request approval, or enter audit and recovery.
The Goal Is Not to Block One More Point, but to Stop the Entire Chain
The latest paper evaluates 45 risk-bearing multi-tool workflows, five deterministic rollback trajectories, and two standard benign-agent benchmarks.
Across the 45 risky workflows:
- Plain execution: committed a policy-violating effect in 45/45 workflows.
- Strategy adapters abstracted from existing defense boundaries: stopped only 14/45 workflows before commit. The remaining 31/45 were either missed or detected only after the fact.
- Cordon: stopped 45/45 workflows before commit.
These results show that Cordon’s advantage does not come from a stronger point classifier. It comes from validating result provenance, local changes, external effects, and authority together within one transaction.
The paper also examines two representative cases:
- Routine helper command: appears to be an ordinary command but writes to a sensitive path such as .ssh/config.
- Cleanup command: runs inside an allowed workspace, but its combined effect is a high-fanout deletion.
Neither problem is necessarily obvious from the tool request or sandbox boundary alone. Cordon’s transaction view makes hidden writes and staged deletion sets explicit, allowing the runtime to block them before commit.
Performance: Transaction Overhead, but Fewer Wasteful Long-running Chains
The end-to-end performance table in the latest paper covers 45 risky workflows, with task time including approval wait time.
When approval wait time in the current prototype is included, average task time under reject-on-risk falls from 25.55 seconds to 23.64 seconds, a 7.5% reduction. The approve-all and mixed modes increase end-to-end latency by 21.8% to 22.7% because of approval interactions.
At the same time, every transaction-mediated mode significantly reduces model workload:Token usage decreases by 23.6% to 28.4%. LLM calls decrease from 162 to between 119 and 127.
The paper’s abstract also emphasizes that, when approval wait is excluded, transaction-mediated execution reduces average task time by 24.6% to 27.9% compared with plain execution. The reason is that, in long-chain risks such as derived-secret egress, Cordon reaches the validation boundary earlier and prevents the agent from continuing along the full unsafe execution path.
Rollback: More Than a Post-hoc git reset
Cordon’s rollback suite evaluates failure recovery across five deterministic failed-agent trajectories.
The results show that Git restore/reset may appear fast, but it leaves behind untracked artifacts and staged-effect traces.
reset + clean removes more state, but still fails on a permission-drift trajectory.
Cordon’s advantage is that it does not perform coarse-grained recovery across the entire workspace. It discards staged state within the transaction scope while preserving the effect, authority, and audit semantics required for recovery.
Does It Affect Successful Completion of Normal Tasks?
The paper also runs a sanity check on a subset of benign benchmarks.
Across these standard benign tasks, Cordon does not significantly reduce benchmark-visible correctness.
Limitations and Boundary Conditions
Cordon’s guarantees depend on one prerequisite: relevant tools and side effects must pass through its mediated transaction runtime.
If a plugin bypasses the runtime entirely, or an external service hides side effects that cannot be observed, Cordon cannot claim to provide complete rollback. It can still record lineage, authority context, and recovery metadata, treating the event as a crossed boundary that enters audit or compensation.
Cordon also does not make the external world physically reversible. A message already sent, an API already called, or a network request already observed by a remote system cannot simply be undone.That is why Cordon focuses on staging: validate whenever possible before an irreversible commit.
Conclusion
The risk of tool-using agents is not merely whether a model says something wrong. It is whether tool-driven side effects should be committed.
Cordon transforms agent tool execution from a sequence of immediately effective RPCs into a task-level semantic transaction.
Other mechanisms often inspect a single point. Cordon evaluates the entire task execution and gives it a commit boundary that can be validated, rolled back, and audited before side effects become durable or externally visible.