CXI binds LLM agent actions to real authority
New research argues most agent failures aren’t “prompt injection” but authority laundering: untrusted context ends up authorising tools, parameters, or the call itself. Context-to-Execution Integrity (CXI) ties field permissions, exact-effect validation, and invocation rights to one action manifest, blocking escapes in evaluated runs while preserving utility.
We keep calling it prompt injection. It isn’t. The failure that keeps biting Large Language Model (LLM) agents is authority laundering: attacker-writable text gets mistaken for permission to choose a tool, flip an approval flag, run SQL, or hand work to a more privileged agent. If you let untrusted prose pick a protected field, shape an interpreted payload, or trigger the call, you’ve already lost.
A new execution boundary, Context-to-Execution Integrity (CXI), treats this as a permissioning problem, not a vibes problem. It only admits an action when three separate things line up on one canonical manifest. First, field authority: protected sink fields must be set by trusted state or by narrow, destination-scoped typed releases, not by whatever the model read off GitHub or a ticket. Second, exact-effect authorisation: adapters compute the intended side effect under a trusted snapshot and validators approve that specific effect, not a free-form payload. Third, invocation authority: a manifest-bound capability ledger issues a one-shot lease to actually run. A deterministic gate checks all three bind to the same manifest before anything fires. Opaque evidence slots keep untrusted context as evidence, not as permission.
The numbers back the boundary. In 400 repository episodes with a code agent using exact-effect checks and lease-bound execution, the system completed 231 tasks safely with zero observed escapes across field, effect, or invocation. A broader live evaluation (720 episodes, 1,739 LLM calls) showed the same admission rule holding: many unauthorised proposals, no admitted escapes. Mechanism ablations matter: CXI blocked 20 of 20 attack cases that baselines let through, while still getting work done in clean cases.
This reframes agent security. The model will propose dodgy actions because proposal pressure is real; the fix is to starve those proposals of authority at the boundary. That shifts the attacker’s attention to where it should always have been: the host and its ledger, any unmediated helper APIs, weak validators, sloppy field classification, or mismatched assumptions about hosted provider internals. Those are tangible systems problems you can test, audit, and break.
My view: CXI is the first grown-up control for agents with side effects. It matches how real organisations already enforce payments, database writes, and workflow transitions: capability accounting and effect validation, not clever prompts. The guarantee is narrow and deployment-heavy by design. Good. If your agent can change the world, you don’t want broad guarantees. You want exact ones.
Additional analysis of the original ArXiv paper
📋 Original Paper Title and Abstract
Context-to-Execution Integrity for LLM Agents
🔍 ShortSpan Analysis of the Paper
Problem
This paper studies how language-model agents that read attacker-controllable context can inadvertently cause privileged side effects when writable context gains authority to select or parameterise protected sink fields, interpreted payloads, or the invocation event. The core failure mode is authority laundering: writable text appears as evidence but is wrongly treated as authorisation for actions such as choosing a tool, flipping approval state, running SQL, or delegating to a more privileged agent. Preventing this is critical because agents routinely read untrusted inputs and then call tools, modify repositories, run commands, or trigger workflows.
Approach
Context-to-Execution Integrity (CXI) is an execution-boundary design that enforces that three distinct authority objects bind to one canonical action manifest before the host admits execution: (1) field authority for protected sink fields, expressed via trusted state or destination-scoped typed releases; (2) exact-effect authorisation for sink-interpreted payloads, provided by validators and adapters that compute the effect under a trusted snapshot; and (3) invocation authority consumed from a manifest-bound capability ledger which returns an execution lease. CXI classifies fields, declares opaque evidence slots, requires fail-closed validators, records provenance (open-weight backend evidence or hosted/API construction evidence), canonicalises actions into manifests, and enforces a deterministic gate that checks field, effect, and invocation predicates before issuing a lease.
Key Findings
- CXI admits execution only when field, effect and invocation authority bind to the same manifest; evaluated sinks showed no executed escapes when admission succeeded.
- In a live code-agent exact-effect benchmark (400 repository episodes with exact-effect authorisation and lease-bound execution) the system produced 231 safe task completions and observed zero field, effect, or invocation escapes.
- AgentDojo live evaluation covered 720 episodes and 1,739 LLM calls; across the broader task-bank runs CXI produced 306 backend field-evidence records, 204 leases and exact-effect authorisations, and 199 safe task completions under the evaluated conditions.
- Proposal pressure is high: models often propose unauthorised fields before admission (e.g. hundreds of unauthorised proposals across tests), but the CXI gate prevented unauthorised execution in the evaluated rows.
- Mechanism ablations show CXI’s combined checks matter: CXI blocked 20/20 attack cases while preserving utility in representative clean cases, whereas simpler baselines left various escape modes.
Limitations
CXI’s guarantee is narrow and deployment-dependent. It assumes complete mediation of all side-effect paths, correct and complete field classification and declassifier design, fail-closed validators, conservative provenance tracking, and a trusted host runtime and ledger. Hosted/API deployments cannot expose provider internal state (masks, attention, KV-cache lineage) so they rely on host-observed construction evidence rather than backend internals. CXI does not ensure validator completeness, task correctness, external exactly-once delivery beyond adapter contracts, or remote attestation against a compromised host.
Implications
Offensively, adversaries can still shape model proposals by writing issues, logs, memories or PR text to increase proposal pressure but cannot convert such proposals into privileged actions if CXI is correctly deployed. Practical attack routes therefore focus on bypassing or compromising the CXI boundary: compromising the host or ledger to forge or consume invocation capabilities, substituting backend evidence records, exploiting unmediated helper APIs or alternate side-effect paths, abusing mis-scoped typed releases or weak validators to reuse authority across fields, or leveraging opaque evidence to influence humans or later agents. Hosted-provider internals remaining hidden creates an additional attacker surface if the provider enforces different semantics than the host assumes.
