💻 computer science

Context-to-Execution Integrity for LLM Agents

This paper introduces Context-to-Execution Integrity (CXI), a system that secures LLM agents by enforcing strict authority checks on protected sink fields, payloads, and invocation events to ensure that only actions with binding field, effect, and invocation authority are executed, thereby achieving zero observed security escapes across diverse benchmarks.

Original authors: Igor Santos-Grueiro

Published 2026-07-08

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Igor Santos-Grueiro

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a highly skilled but gullible assistant (the AI agent) who is trying to get things done for you, like sending emails, editing files, or running code. This assistant reads a massive notebook filled with instructions, notes, and messages. The problem is that a clever trickster (the attacker) can sneak notes into that notebook, trying to trick the assistant into doing something dangerous, like deleting a database or sending money to the wrong person.

The paper introduces a system called Context-to-Execution Integrity (CXI). Think of CXI as a super-strict security guard standing at the door of the "Action Room." Its job isn't to read the whole story or decide if the task is a good idea; its job is to check if the assistant has the specific, valid keys to open the door for this specific action.

Here is how it works, using simple analogies:

1. The Problem: "Authority Laundering"

Usually, if the assistant reads a note in the notebook that says, "The file failed, so run the delete_all command," it might just do it. The paper calls this Authority Laundering. It's like a thief taking a legitimate-looking ID card (the note about the file failure) and trying to use it to open a bank vault (the delete command). The note explains why something happened, but it shouldn't have the power to make something happen.

2. The Solution: The Three-Part Security Check

CXI acts as a gatekeeper. Before the assistant can actually do anything (like write a file or send an email), the gatekeeper checks three things. All three must match the same specific plan (called a "Manifest").

Check 1: The "Who" (Field Authority)
- Analogy: Imagine the assistant wants to write a letter to a specific person. The note in the notebook might say, "Send to Bob." But the security guard checks: "Did a trusted boss or a verified system actually say 'Send to Bob'?"
- If the name "Bob" just came from a random note the attacker wrote, the guard says NO. The name must come from a "Typed Release"—a special, verified slip of paper that says, "Yes, this specific name is allowed for this specific field."
Check 2: The "What" (Effect Authority)
- Analogy: Imagine the assistant wants to apply a patch to a computer program. The note says, "Apply this code." The guard checks: "Does this code actually do what we think it does?"
- The guard doesn't just look at the words; it looks at the result. If the code is a "patch," the guard verifies exactly what changes it will make to the system. If the attacker tries to sneak in a command that looks like a patch but actually deletes files, the guard catches it because the "effect" doesn't match the authorized plan.
Check 3: The "When" (Invocation Authority)
- Analogy: Imagine the assistant wants to press the "Go" button. The guard checks: "Does the assistant have a valid ticket to press the button right now?"
- Even if the name and the plan are correct, the assistant needs a specific "capability" or ticket to trigger the action. If the attacker tries to trick the assistant into pressing the button twice or at the wrong time, the guard says NO because the ticket is missing or expired.

3. The "Manifest" (The Master Plan)

The paper calls the final approved plan a Manifest. Think of this as a contract.

The assistant proposes an action.
The guard checks the "Who," "What," and "When."
If all three match perfectly and are tied to the same contract, the guard stamps the contract and hands the assistant a "Lease" (permission) to execute.
If even one part is missing or doesn't match (e.g., the name is right, but the "When" ticket is wrong), the guard shuts the door.

4. What About the "Bad" Notes?

The paper notes that the assistant can still read the attacker's notes.

Opaque Data: If the attacker writes, "The system is broken," the assistant can copy that text into a "Comment" or "Evidence" box. This is like putting the note in a glass display case. It's visible for humans to read, but it has no power to open doors or trigger actions. It's just data, not a key.

5. What Did They Test?

The authors tested this system in a few ways:

Live Simulations: They used a "dojo" (a training ground) with 720 real-life scenarios where attackers tried to trick agents. The system blocked every single unauthorized action.
Code Agents: They tested agents that write code. Even when attackers tried to inject bad commands, the system only allowed actions that had the correct "keys."
Result: In all the tests, zero unauthorized actions got through the gate. The system successfully stopped "authority laundering."

Summary

CXI is a system that stops AI agents from being tricked. It ensures that just because an AI reads a dangerous instruction in a note, it doesn't mean it has the power to do it. The AI can only act if a trusted system explicitly gives it the specific keys for that specific job, at that specific time. It turns the AI from a gullible reader into a disciplined worker who only follows verified orders.

Technical Summary: Context-to-Execution Integrity (CXI) for LLM Agents

1. Problem Statement

Large Language Model (LLM) agents increasingly operate by reading attacker-writable context (e.g., CI logs, issue comments, retrieval chunks, tool outputs) to propose actions that trigger real-world side effects (e.g., file writes, database queries, API calls). The core security failure identified is authority laundering: a system where untrusted text, which should serve only as evidence, gains the authority to select tools, authorize operations, or parameterize privileged side effects.

Current security approaches often rely on schema validation or whole-call trust, which are insufficient. A tool call may be syntactically valid (correct JSON structure) while its semantic fields (e.g., tool, operation, approval_state) are derived from untrusted sources. The paper argues that the security boundary must shift from "is the text plausible?" to "does the specific value in each protected field carry the necessary authority to execute this specific side effect?"

2. Methodology: Context-to-Execution Integrity (CXI)

CXI is an execution-boundary system designed to mediate the transition from model proposal to sink execution. It enforces a strict admission policy where a side effect occurs only if three distinct authority components bind to the same canonical action manifest:

Field Authority: Protected sink fields (e.g., file paths, tool names) must be authorized.
Effect Authority: Sink-interpreted payloads (e.g., patches, SQL, shell commands) must be authorized for their specific semantic effect.
Invocation Authority: The event of calling the sink (including retries, batching, and scheduling) must be authorized.

Core Mechanisms

Typed Releases (D): Untrusted writable context ( $W$ ) cannot directly authorize protected fields ( $X$ ). Instead, trusted code (declassifiers) must validate $W$ and mint a narrow, destination-scoped Typed Release. For example, a log line may be validated to produce a FilePath release for the file_path argument, but that same text cannot authorize the tool selection.
Opaque Data (O): Untrusted text can be copied into "opaque data slots" for evidence (e.g., comments, logs) but carries no authority. If this data re-enters a side-effecting boundary later, it is treated as writable context again.
Exact-Effect Authorization: For constructive payloads (patches, SQL, CI YAML), the system does not just check the payload bytes. It uses Effect Adapters to compute the exact semantic effect the sink will apply under a trusted snapshot (e.g., repository state, policy epoch). The execution is bound to this specific effect commitment.
Manifest-Bound Gate: A deterministic gate canonicalizes the proposed action into an Action Manifest. This manifest records the action nonce, field evidence digests, effect authorization digests, and call-authority digests.
Invocation Capabilities: The gate consumes a manifest-bound Invocation Capability (a linearizable lease) before execution. This prevents replay attacks, unauthorized retries, or batch cardinality changes.

Provenance and Evidence

CXI tracks the provenance of influence, not just byte origin.

Open-Weight Path: For models with access to internal state (e.g., vLLM), the system generates backend evidence records that bind protected-field decoding to specific token ranges and attention masks, ensuring no untrusted context influenced the protected field generation.
Hosted/API Path: For APIs where internal state is hidden, the system relies on field-local construction evidence. Here, the host ensures that field writers only see trusted state and valid typed releases, while opaque data is excluded from the writer's context.

3. Key Contributions

The paper defines and evaluates three primary contributions:

Definition of CXI: A formal requirement that protected selections, sink-interpreted effects, and invocation events must each carry authority for the same canonical action before a model proposal becomes executable.
Manifest-Bound Admission System: A design that composes protected-field evidence, exact-effect authorization, and consumable invocation capabilities into a single sink decision, enforced by a deterministic gate.
Comprehensive Evaluation: An evaluation across open-weight field-projection paths, AgentDojo live episodes, a code-agent exact-effect benchmark, ledger fault injection, and hosted/API compatibility traces.

4. Evaluation Results

The evaluation separates task utility (did the agent solve the problem?) from admission integrity (did unauthorized authority cross the boundary?).

AgentDojo Live Episodes: Across 720 live episodes and 1,739 LLM calls, CXI observed zero field, effect, or invocation escapes in protected admissions.
Code-Agent Exact-Effect Benchmark: In 400 repository episodes, the system yielded 231 safe task completions. Crucially, there were zero observed field, effect, or invocation escapes.
- Note on Failures: Non-completions were attributed to parse failures (73 cases), lack of effect authorization (61 cases), or task-quality issues (35 cases), not security breaches.
Proposal Pressure: The system observed significant "proposal pressure" where models attempted to select unauthorized fields (e.g., 196/300 unauthorized proposals in utility adversarial settings). However, the gate successfully blocked all such attempts, resulting in zero executed escapes.
Ledger Faults: In manifest-bound ledger tests, the system successfully rejected duplicate admissions and suppressed double-spends, confirming the integrity of the invocation capability consumption.
Comparison to Baselines:
- Schema-only validation: Allowed 100% of unauthorized executions (W-derived values filled protected fields).
- Argument-role provenance approximations: Failed to block call-event and backend-binding failures.
- CXI: Blocked 20/20 attack cases while preserving 6/6 utility cases in mechanism baselines.

5. Significance and Claims

The paper positions CXI as a concrete systems property for mediated sinks rather than a general solution for all agent safety issues.

Explicit Boundary: CXI makes the transition from context to execution explicit, checkable, and fail-closed. It does not claim to make validators complete, tasks correct, or provider internals observable; rather, it ensures that if an action executes, it is because the specific authority chain for that action is complete.
Modest Scope: The authors explicitly state that task quality, validator completeness, and external exactly-once delivery are separate obligations. CXI ensures that the authority to execute is correct, not that the content of the execution is desirable or that the model's reasoning is sound.
Policy-Centric: The system relies on trusted policy work (field classification, declassifier contracts, effect validators). It does not infer missing policy; if a field is not classified or a sink is not mediated, the guarantee does not hold.
Evidence Variance: The paper acknowledges that evidence differs by deployment regime. Open-weight deployments can prove backend enforcement via attention masks, while hosted/API deployments can only prove host-observed construction boundaries. Both, however, feed the same manifest-bound gate logic.

In summary, CXI provides a mechanism to prevent authority laundering by ensuring that untrusted text can only influence side effects through explicit, validated, and scoped channels (typed releases, exact-effect commitments, and invocation capabilities) that are bound to a single canonical action manifest.