Context-to-Execution Integrity for LLM Agents Igor Santos-Grueiro International University of La Rioja
arXiv:2607.06000v1 [cs.CR] 7 Jul 2026
Abstract
laundering: a value that should be evidence gains authority to select, authorize, trigger, or parameterize a privileged side effect. A CI log may identify the file that failed; it should not choose prod_admin.run_sql, mark a change as approved, expand a retry budget, or trigger a second production write. An issue body may explain a bug; it should not rewrite CI policy or delegate to a more privileged agent. Consider a structured tool call with a tool name, operation, path, approval state, and retry budget. The call may be well formed even when those values come from writable context. A schema checks names and types; it does not check authority for the protected fields, interpreted effect, or invocation. The security question is then whether the invocation has authority to occur and whether each protected field has authority for the semantic value consumed by the sink. A sink is the side-effecting endpoint: a tool call, API call, file write, shell command, database operation, workflow update, or delegation step. A FilePath typed release may authorize file_path. The same log or issue text has no authority for approval_state. The failing log line may still be copied as opaque evidence in a comment. The model proposes; the host admits execution only when the invocation, protected fields, and sink-interpreted effects carry authority for the same canonical action. Recent work has moved agent security toward action boundaries. PACT shows that whole-call trust is too coarse and that argument-level provenance can recover utility while blocking untrusted content from binding authority-bearing arguments [12]. ARGUS audits decisions with influence provenance [46]; FORGE develops runtime policies for agentic systems [29]; and AIRGuard frames defense as action-time authority control [31]. CXI builds on this direction but makes a narrower admission claim for structured side-effect sinks. Plausible field values are not enough. Selection authority, effect authority, and event authority must all bind to the same canonical action before execution. Context-to-Execution Integrity (CXI) is an executionboundary system for that boundary. Its open-weight path generates protected selection fields under backend evidence; its
Language-model agents read attacker-writable context to solve tasks. Tool execution needs a separate authority check for protected sink fields, sink-interpreted payloads, and the invocation event. Context-to-Execution Integrity (CXI) is an execution-boundary system for this setting. Policies mark protected sink fields, typed releases carry narrow validated values from writable context to specific destinations, opaque data slots keep evidence as data, and a deterministic gate admits a call only after field authority, exact-effect authorization, and invocation authority all bind to the same action manifest. We evaluate CXI on open-weight field-projection runs, AgentDojo live episodes, a code-agent exact-effect benchmark, manifest-bound ledger faults, proposal-pressure controls, and hosted/API compatibility traces. AgentDojo covers 720 live episodes and 1,739 LLM calls; the code-agent benchmark covers 400 repository episodes with exact-effect authorization and lease-bound execution, yielding 231 safe task completions and zero observed field, effect, or invocation escapes. The accounting reports parser outcomes, authorization outcomes, and task-quality outcomes together with the admission-integrity result. Across the evaluated sinks, CXI admits execution only when field, effect, and invocation authority bind to the same action manifest.
1
Introduction
Language-model agents now turn text into side effects: they send mail, modify files, update calendars, open pull requests, run shell commands, query databases, and call administrative APIs [27, 36, 49]. They also read emails, webpages, issue comments, README files, retrieval chunks, CI logs, tool outputs, package metadata, and memories that an attacker can write or influence [9, 14, 28, 32]. Many agent stacks put those sources in the same model context that proposes the next tool call. The resulting failure is not just that malicious text may be followed as an instruction. The systems failure is authority 1
effect path requires exact authorization for sink-interpreted payloads; and its execution path consumes an invocation capability before the sink runs. A deterministic gate ties those obligations to one canonical action manifest. The model may inspect writable context, but writable context becomes executable authority only through a destination-scoped typed release, an exact-effect authorization, or a consumed invocation capability for the same manifest-bound action. CXI is enforced at the last point before the side effect. The gate canonicalizes the proposed action, checks field evidence, verifies exact-effect authorizations for payloads interpreted by the sink, validates semantic bindings under the trusted sink snapshot, consumes the selected invocation capability in a linearizable ledger, and executes only with the resulting lease. CXI’s claim is mediated admission integrity: before a side effect occurs, the host checks that the invocation, protected fields, and sink-interpreted effects are authorized for the same canonical action. Task quality, validator completeness, provider internals, external exactly-once delivery, and complete transformer-level noninterference are separate obligations. We evaluate CXI on open-weight field-projection paths, AgentDojo live episodes, live code-agent exact-effect tasks, manifest-bound ledger faults, proposal-pressure controls, and hosted/API compatibility rows. The evaluation keeps proposals, admissions, leases, external effects, and task success as separate units. Unauthorized proposals measure attack pressure; field, effect, and invocation escapes measure whether unsafe authority crossed the mediated sink boundary; parse failures and fail-closed behavior are not counted as task success. This paper makes three contributions:
only trusted state, typed releases, or opaque data slots can cross the boundary with the authority shown in the verdict column. Trusted state (T ) contains the objective, policy, registry, approvals, and other trusted inputs. Writable context (W ) is attacker-writable or attacker-influenced input. Typed releases (D) carry validated values from W to a specific destination field. Opaque data (O) is copied untrusted text with no current-boundary authority. Protected sink fields (X) select, authorize, or parameterize an external effect. Vocabulary. CXI distinguishes five kinds of state at the boundary.
Trusted state
T
Writable context
W
Typed release Opaque data
D O
User objective, policy, registry, approvals, and other trusted authority sources. Attacker-writable or attacker-influenced input read by the agent. Typed release from W to a specific destination field. Copied W data without authority at the current boundary. Sink field that selects, authorizes, or parameterizes a side effect.
Policy tables may group protected sink fields and effectbearing fields under a H IGH I NTEGRITY enum; the main text names each case directly. Sink schemas partition fields by authority. Every field in a mediated sink must have an explicit class; unknown fields and omitted classes are rejected. Protected sink fields include tool, operation, approval, recipient, namespace, target, path, CI target, delegation, package-install target, and any argument that can change the external effect. Declared non-effect data is allowed only after the side effect is authorized and only when the adapter demonstrates that the sink treats the field as inert. If a field can trigger renderers, slash commands, webhooks, bots, downstream agents, policy interpretation, or later side-effecting workflows, it is opaque data that re-enters as W or a protected or effect-bearing field. Opaque fields may contain uninterpreted W payloads, so the same string can be admissible in a comment and inadmissible in an approval field. Some payloads look like data but still carry effect authority. Patch diffs, file contents, shell text, SQL, CI YAML, package manifests, policy files, deployment configuration, generated code, and install hooks can change behavior. CXI treats them as effect-bearing unless a policy-specific validator constrains their destination, scope, and allowed effect. Scopes keep release decisions local. A FilePath extracted from CI may authorize arguments.file_path; it cannot authorize tool, operation, approval_state, or later package-install targets. A typed release is therefore scoped to one destination field.
• We design a manifest-bound admission system that composes protected-field evidence, exact-effect authorization, and consumable invocation capabilities into one sink decision. • We evaluate CXI across open-weight field-projection paths, AgentDojo live episodes, a live code-agent exact-effect benchmark, manifest-bound ledger faults, proposal-pressure controls, and hosted/API compatibility traces while keeping parse failures, utility loss, and validator completeness outside the core admission claim.
2.1
Symbol Meaning
Protected sink field X
• We define context-to-execution integrity (CXI): protected selections, sink-interpreted effects, and invocation events must each carry authority for the same canonical action before a model proposal becomes executable.
2
Term
Boundary and Threat Model
2.2
Boundary Objects and Fields
CXI uses a small vocabulary at side-effect boundaries. In Figure 1, the CI log and runbook are readable evidence, but
Threat Model
The attacker controls writable-context sources but not trusted policy, the explicit user objective, model weights, host run2
Sources / releases T: registry/task repo.write_file
Candidate field
Gate
tool/operation repo.write_file / modify
ACCEPT
W: CI log users.legacy_token
D(FilePath) typed release
file_path accepted for this field
ACCEPT
W: log quote diagnostic evidence
OpaquePayload data only
comment/evidence quoted for review
DATA ONLY
no release
approval/tool raw W-to-X authority
REJECT
W: runbook approved; prod_admin
Figure 1: Authority laundering at a structured sink. Writable evidence may be read, quoted, or converted into a typed release for one destination, but raw writable context cannot authorize protected sink fields such as tool selection or approval state. time, or privileged tools. The attacker may write issues, documentation, CI logs, tool outputs, retrieval documents, package metadata, persistent memories, or another agent’s messages. The goal is to influence a privileged sink: select a tool, change an operation, mark approval as satisfied, choose a recipient or namespace, skip confirmation, persist false authority, or delegate to a more privileged agent. Context-to-Execution Integrity mediates one boundary: whether adversarially writable data has authority to influence privileged side-effect fields. It composes with normal authorization, sandboxing, host integrity, and service-specific access control. The trusted components are explicit: policy, provenance tracking, declassifier validators, backend evidence verification, and the host runtime.
lease; it is not itself field or invocation authority. Constructive payloads such as patches, file bodies, SQL, shell commands, CI YAML, package manifests, and deployment descriptors use adapter-specific exact-effect commitments over the object interpreted by the sink under its trusted snapshot, principal, defaults, policy epoch, and manifest. The validator decides which effect is acceptable; CXI binds admission so the executed effect must match the effect authorized for that adapter and snapshot. Deployments may produce different evidence records, but they feed the same sink-admission check. Operational rules for reads, summaries, memory, tool outputs, schema repair, cached prefixes, and agent handoff follow the same conservative influence rule. As in classical information-flow work, the security question is what information could have influenced an output, not merely where a string originated from [10, 13, 33, 40]. For every accepted sink call, Πcall must authorize the invocation under the action history, budget, ordering, idempotency, schedule, and retry policy. Each protected sink field must satisfy the field rule:
Non-goals. Context-to-Execution Integrity relies on a trusted host runtime, trusted tools, correct approval state, and mediated sinks. It checks field authority before execution. Semantic task quality remains a separate concern: a patch, diagnosis, or workflow can be wrong even when its side-effect fields have valid authority. Opaque text can influence humans, bots, or later agents outside the current mediated sink; when it re-enters a side-effecting component, it is treated as writable context again.
2.3
W ̸→ X
unless W → Dauthorized → X.
The invocation event has the analogous call-level rule:
Provenance and Security Goal
W ̸→ Invoke
CXI tracks provenance of influence, not only provenance of bytes. A field such as tool="repo.write_file" may be spelled with bytes from a trusted registry while the choice to call it came from writable text; that field is W-derived for CXI. Each protected field has a conservative influence set Π[ f ], and the invocation event has Πcall for whether the action is emitted, retried, scheduled, ordered, or batched. Unknown, stale, repaired, or ambiguous provenance rejects. The security goal is field-level authority admissibility plus invocation authority for the side-effect event. A protected sink field may be selected only by trusted authority valid for that field or by a matching typed release. Raw W may explain a re-
unless W → Dcall → Invoke.
The claim separates two requirements. Manifest-bound admission is the gate property: given policy, validators, complete mediation, and conservative field and call provenance, the gate enforces admission before execution. CXI-Provenance is the runtime requirement: the record must conservatively capture the influences on each protected field and on the invocation event. Open-weight and hosted/API deployments use different records for this purpose; neither claims end-to-end model independence. This use of typed releases follows prior IFC systems: declassification is an explicit downgrade boundary with a policy justification [5, 17, 25, 26, 34]. 3
3 3.1
Design
clared non-effect data is valid only when the adapter demonstrates that the field is inert; anything that can affect the sink or a downstream actor is protected, effect-bearing, or opaque with reentry as W.
Boundary Overview
Context-to-Execution Integrity checks authority at the action boundary. A model may propose a structured action, but the host admits it only through ordered boundary steps. Admission pipeline. CXI admits an action through six ordered boundary steps: (1) canonicalize the candidate into an action manifest; (2) check fields against field-local authority and provenance; (3) check effects against exact-effect commitments; (4) authorize invocation with a manifest-bound capability; (5) consume that capability to obtain an execution lease; and (6) execute only through the mediated sink. A single JSON object may contain a tool name, operation, approval state, recipient, path, command intent, and payload, but each field has its own authority requirement. The manifest binds those requirements to one canonical action so that a release for one field cannot authorize another field, an effect authorization cannot be replayed against another sink state, and an invocation capability cannot be spent on a different action. The design combines total field policy, typed releases, opaque data slots, field/effect gate checks, manifest-bound invocation capability, and deployment-specific provenance records. This follows complete mediation and least privilege: privileged side effects are checked at the boundary, and authority is never inferred from text content alone [15, 35, 43].
3.2
3.3
Declassification and Opaque Data
A declassifier is trusted code that mints a narrow typed release. A model or extractor may propose a path, approval reference, dependency name, time interval, or patch intent, but its output remains W until trusted declassifier code canonicalizes the candidate, validates it against the trusted snapshot, and mints a typed release (D) scoped to a destination field. The release carries its output type, source scope, destination scope, declassifier identity, validator identity, and provenance. Valid releases are narrow: a normalized time interval, a repository-relative path, a bounded enum, a hash, a trusted approval identifier, or an opaque payload handle. Broad natural-language rationales stay data, and syntactically valid values still reject when outside policy. Representative releases include FilePath, ApprovalRef, and OpaquePayload. Opaque data handles preserve evidence without granting authority. A log line, ticket body, PR description, commit message, or email body can be copied into a declared evidence field, but the copied body keeps provenance. If a later agent, bot, tool, or memory system reads it and can create side effects, the payload enters that boundary as writable context. This follows the declassification view from IFC: each release states what is released, where it may flow, and under whose authority [18, 26, 34].
Policy Model
A CXI policy is the trusted authority map for a mediated sink. It declares writable origins, trusted roots, mediated sinks, total field classifications, allowed declassifiers, opaque slots, effect validators, backend evidence requirements, and authorized sink operations. The policy is fail-closed: unknown fields, omitted classifications, invalid branch expansions, stale policy versions, and unsupported evidence modes reject before execution. Writable text may describe an emergency exception, a new namespace, or a policy change. Those claims become authority only if trusted state or a policy-authorized declassifier grants that authority. The policy is field-scoped. A FilePath release may authorize arguments.file_path; it cannot choose tool, operation, approval_state, a shell command, or a CI target. Table 1 is the compact design rule: the manifest binds authority to field paths, interpreted effects, and invocation events, not to surrounding natural-language text. Policies also classify effect-bearing payloads. Patch diffs, file bodies, shell commands, SQL statements, CI workflows, package manifests, policy files, deployment descriptors, and install scripts are effect-bearing unless a validator bounds their effect. Opaque slots remain useful for quoting evidence or writing user-visible descriptions; they carry data only. De-
3.4
Gate Semantics
The gate is the only component allowed to turn a schema-valid candidate action into an executable sink call. It receives the canonical action, a field provenance map Π, a call provenance set Πcall , policy P, effect commitments, and any required backend or field-local evidence records. It returns either reject or an execution lease. Byte origin alone is insufficient: a field can contain a trusted-looking string while its selection was caused by W, and summaries, memory writes, tool outputs, and schema repairs preserve W influence until a typed release authorizes the destination. Inputs. The core objects are intentionally small. A PolicyEntry, keyed by (sink, f ield), declares the class, accepted influence atoms, validators, scopes, policy version, and backend evidence requirement. A canonical Value is interpreted under the sink snapshot. The provenance map Π assigns each field a conservative set of T , W , D, and O atoms. InvokeCapability is the matching authority object for the side-effect event: it names the sink, operation, budget, sequence state, idempotency token, expiry, trusted snapshot, and policy version, and a linearizable consume must return a lease before 4
Table 1: Authority objects in the main CXI boundary. The model can propose values, but field selection, sink-interpreted effects, and the invocation event need separate authority bound to the same canonical action manifest. Object
Authority question
Accepted source
Rejected laundering
Tool/operation Target path
Which sink action? Which target value?
Trusted registry and task policy. Scoped FilePath release for this field.
Patch or file body Approval Invocation event Comment/evidence
Which interpreted effect? Is approval satisfied? Should the action occur or retry? Can W be copied as data?
Exact-effect authorization over the state delta. Trusted approval state or ApprovalRef. Manifest-bound invocation capability. Opaque slot with preserved provenance.
Issue or log text chooses the tool. The same path chooses a CI target or command. Raw W patch bytes execute directly. Copied “approved” string from W. W controls schedule, batch, or retry. Quoted text reused as future authority.
execution. The full call-atom rules, control-flow propagation rules, capability resolver, and verifier are in the appendix. Authority predicates. mayInfluence(P, sink, field, atom) answers whether an atom may participate in choosing this field. authorizesValue(P, sink, field, value, atom) is stricter: it asks whether that atom authorizes the actual semantic value or effect by exact-value digest, exacteffect commitment, or a bounded predicate over the canonical value and trusted snapshot. A protected sink field is accepted only if every atom in Π f may influence the field and at least one atom authorizes the selected semantic value or effect. W, opaque, unknown, wrong-domain trusted, cross-field D, unknown optional branches, and missing referenced fields reject. Operational field check. Operationally, the field predicate checks six conditions. First, the field must be in the active sink schema and must have a total policy classification. Second, the field must carry known conservative provenance. Third, opaque slots may preserve trusted or opaque data but grant no later authority. Fourth, declared non-effect data is admitted only for adapter-demonstrated inert fields. Fifth, every influence on a protected sink field must be trusted or a destinationscoped typed release (D) for that exact field, and at least one atom must authorize the canonical value or adapter-specific effect. Sixth, validators and relational action constraints must accept under the trusted snapshot. Fail-closed behavior. Raw W provenance in a protected sink field, D outside scope, wrong type, opaque text in an authority field, unauthorized tool or operation, schema repair over a protected field, backend evidence record mismatch, and unsupported protected backend paths all make the sink call non-executable. In other words, any failure to satisfy field, effect, or invocation authority causes the gate to reject before execution.
Table 2: Exact-effect authorization binds the sink-interpreted effect, not the payload spelling. Validators decide which exact effect is acceptable; CXI binds the accepted effect to the action that may be admitted. Payload
Authorized commitment
Repository patch
Repository state delta over base commit, canonical paths, old/new blobs, modes, symlinks, renames, and allowed path set. File body Canonical path, bytes, mode, target snapshot, and adapter revision. SQL Parsed statement or AST, parameters, schema snapshot, role, and allowed write set. Shell command Trusted-rendered argv/env/cwd plus sandbox, network, filesystem, and process policy. CI or package manifest Canonical state delta plus workflow, dependency, installhook, and policy-file predicates.
test failure, or user document. That dependency makes the payload useful, not authorized. Simple canonical fields use E XACT VALUE(hash) over the sink-parsed semantic value. Effect-bearing payloads use E XACT E FFECT(commitment): the adapter computes the effect the sink will apply under the trusted snapshot, policy epoch, effective principal, explicit defaults, adapter revision, validator set, and action nonce. The action manifest is the final binding object. It records the action nonce, canonical action digest, adapter ID/revision, effective principal, trusted snapshot, policy epoch, assembly revision, protected-field evidence digests, effect-authorization digests, and call-authority digest. The capability ledger consumes that manifest digest. Any mutation after validation changes a digest and causes execution to fail. Replaying the same payload bytes against a different repository, workspace, base commit, validator set, adapter revision, principal, or policy epoch changes the manifest and rejects the action. The manifest binds the action, the field authorizations, the effect authorization, and the invocation capability into one commitment.
3.5 Exact-Effect Authorization and Action Manifests
CXI runs only the exact effect the validator authorized and only the exact manifest the capability admitted. CXI does not judge whether the effect is desirable; it enforces that the admitted effect matches the exact effect trusted validator code authorized for this snapshot, principal, adapter, and policy epoch. Validator completeness remains a separate adapter obligation.
Field isolation is sufficient only when the protected object is the value the sink consumes. Constructive payloads such as patches, file bodies, SQL, commands, workflows, package manifests, or deployment descriptors may legitimately depend on W because the task comes from an issue, log, 5
3.6
Admitted-Action Contract
Table 3: Field-closed reference contract. This is the reference target for open-weight protected-field decoding; optimized serving paths must match this target on deterministic canaries or fail closed.
Fix a policy P, fail-closed validators, conservative field provenance Π, conservative call provenance Πcall , complete mediation of privileged sinks, and any backend or field-local evidence required by policy. If the CXI gate accepts a sink call, the accepted action satisfies four obligations. Invocation authority. The invocation event is authorized by a valid invocation capability for the sink, operation, task/run, sequence state, retry budget, idempotency key, schedule, history, trusted snapshot, policy epoch, and adapter revision. All call-level influences in Πcall may influence that invocation under policy. The selected capability is the one consumed by the linearizable capability store, and the store returns an execution lease before the sink executes. Field authority. Every executed protected sink field has only trusted authority valid for that field or a policy-valid typed release (D) whose type, source scope, destination scope, validator, value binding, action context, and policy version match that field’s policy. At least one trusted or D atom authorizes the executed semantic value by exact digest, exact-effect commitment, or bounded predicate. Effect binding. For any sink-interpreted payload, the executed effect equals the effect commitment authorized by the adapter for the trusted snapshot, principal, policy epoch, validator set, adapter revision, and action nonce. Opaque reentry. Opaque data may only go into declared non-authority slots. If it later enters another agent, tool, bot, memory, or workflow that can create side effects, that boundary treats it as W again. Raw W, W-derived summaries or memory, opaque data in authority fields, missing provenance, stale metadata, repaired protected fields, evidence record mismatches, and out-of-scope typed releases fail closed. The gate cannot infer these facts at runtime: sinks must be mediated, policies must classify fields correctly, provenance must conservatively track influence, validators must fail closed, and evidence records must match the required path. Composition with provenance records. The admitted-action contract works with different provenance records. Openweight deployments can satisfy the field-provenance requirement with field-closed protected-field decoding; direct-span, suffix-taint, and runtime-map exclusion records are narrower evidence checks for direct W-source, generated-prefix, and declared-atom exclusion. Hosted/API deployments satisfy the requirement with field-local writer visibility under the host. Both still require call-level provenance for the invocation event.
Reference requirement Meaning One protected field Physical projection Clean reference state
Field grammar Host assembly Field evidence
Each decode produces one authority-bearing field. The prompt contains only T, field-valid typed releases, and authorized parent field records for f . Reference mode uses fresh prefill and fresh KV, with no W-seen prefix reuse, batching, CUDA graph replay, or speculative decode. Grammar and candidate/value predicates are local to f . The host assembles fields deterministically after per-field decodes. The backend evidence record binds the projected input, grammar, raw output, canonical value, parent records, backend profile, nonce, and action manifest.
Table 4: Two provenance paths for the same sink-authority check. The open-weight path provides backend evidence for protected-field decoding; the hosted/API path provides fieldlocal construction evidence when provider internals are unavailable. Path
Evidence produced
Boundary checked
Open-weight Backend evidence record with Serving stack plus final sink gate mask state, blocked ranges, action digest, field path, and evidence record serialization mode Hosted/API Extractor record, field-local writer Host plus final sink gate visibility, typed releases, opaque data handles, final action provenance
field f , policy builds a field-specific projection containing only trusted state, typed releases valid for f , authorized parent field records, the field grammar, candidate/value authorizers, backend profile, action nonce, and sampling configuration. The decoder emits one field value and one backend evidence record; the host assembles the canonical action and the gate verifies the record before consuming invocation authority. The contract separates the reference target from evidence checks. Direct-span, suffix-taint, and runtime-map records check declared W source, generated-prefix, and runtime-map influence; they are not field-closed lineage unless they satisfy Table 3. Hosted/API deployments cannot observe provider internals, so they use field-local construction evidence instead. Both paths feed the same manifest-bound sink gate. Open-weight and hosted/API paths differ in the evidence they can produce, not in the sink-authority check. Section 5 reports the evaluated surfaces.
4
3.7 Authority-Projected Protected-Field Decoding
Implementation
CXI is implemented as one shared sink gate with deploymentspecific provenance records. The open-weight path gives the strongest evidence because the runtime can constrain protected-field generation directly. The hosted/API path is for
The open-weight path gives the strongest evidence because the runtime can constrain protected-field generation before the sink gate sees a completed tool call. For each protected 6
scheduler or Dcall validator
invocation capability
Πcall manifest digest
Hosted/API field-local evidence
reader sees T+W
extract D/O
field writer sees T + D/O
field-local record
Open-weight backend evidence
influence map
field projection / mask
protected-field decode
backend evidence record
Effect authorization
sink payload
effect adapter
exact-effect commitment
Invocation authority
Manifest-bound gate canonical manifest field OK effect OK invoke OK lease / reject
Figure 2: CXI admission architecture. Invocation, hosted/API, open-weight, and effect-adapter lanes produce separate authority or evidence records for one canonical manifest. The manifest-bound gate verifies field authority, exact-effect authorization, and invocation capability before issuing a lease. Dashed paths show writable influence excluded from protected-field construction.
4.2
models whose attention masks and cache state are unavailable: it records what a reader and controlled field constructors were allowed to see. Both paths end at the same execution point: execute only when the invocation event, protected fields, and sink-interpreted effects are authorized for the same canonical manifest.
4.1
Declassifiers and Effect Adapters
Declassifiers. Declassifiers are trusted release points. Each specification declares an input scope, output type, destination field set, canonicalizer, validator, and negative tests. A model may propose a candidate; trusted policy code mints the typed release (D) only after validation. Validators are destination-specific: a FilePath release can authorize arguments.file_path, not tool, operation, approval_state, or a CI target. Values are normalized under the trusted snapshot: paths resolve against the repository snapshot, package coordinates against the trusted registry view, recipients and URLs are canonicalized, and closed command or SQL intents are rendered by trusted code. Validator families, an auditable FilePath fragment, and declassifier trust assumptions are summarized in the appendix. Effect adapters. For effect-bearing repository patches, the implementation instantiates Section 3.5 with a repository statedelta adapter. The delta binds repository and workspace identity, base commit, canonical paths, file modes, old/new blob digests, symlink targets, adapter revision, validator set, policy epoch, and action nonce. The adapter rejects traversal, forbidden paths, symlink escapes, CI disablement, install hooks, secret writes, network side-effect markers, and replay across another nonce, repository, workspace, base commit, validator set, or adapter revision. The exact-effect adapter rows are deterministic checks; live code-agent task success is measured separately. Opaque data handles. Opaque data handles preserve evidence without granting field authority and re-enter any later side-effecting boundary as writable context.
Common Execution Boundary
A policy is a deterministic data object naming writable origins, trusted roots, mediated sinks, field classes, opaque slots, declassifiers, effect validators, evidence requirements, and allowed sink operations. The gate classifies authority, not text intent: it canonicalizes the candidate action, attaches field influence records, rejects unmediated sinks or invalid policies, authorizes the invocation event, validates protected fields, verifies backend evidence records when required, consumes the capability, and executes only with the returned lease. Complete mediation is required: a CXI result is meaningful only for side-effect paths that enter the shared gate. Every effect interface must be routed through this manifest-bound control point, and alternate paths must be blocked. Table 5 lists representative entry points and negative bypass checks. Invocation authority is checked separately from argument authority. The predicate validates sink, operation, precondition, sequence state, retry count, batch cardinality, idempotency key, budget, expiry, task/run ID, and history against an invocation capability. The reference ledger consumes against the ActionManifest, not a free-form proposal digest; the capability must match the manifest’s call-authority digest, policy epoch, trusted snapshot, effective principal, adapter ID, and adapter revision. The implementation records local consume, deduplication, rejection, and double-spend checks; the evaluation reports those rows separately. Exactly-once external application remains an adapter contract requiring durable delivery and sink-side deduplication or a shared transactional boundary.
4.3
Open-Weight Protected-Field Path
The open-weight path labels a protected field before it is decoded. The runtime maps prompt spans to token ranges, labels influence atoms, assigns the next structured-output field to 7
Table 5: Representative complete-mediation checks. CXI’s admission result is meaningful only for side-effect paths routed through the shared manifest-bound gate. Sink family
Mediated entry point
Filesystem
Write, delete, move, and generated-file oper- Path, operation, payload effect, trusted snapshot, and Direct file APIs and helper paths are denied or wrapped. ations. adapter revision. Trusted-rendered argv/env/cwd plus sand- Command intent, environment, cwd, network, filesys- Raw shell strings from W do not execute. box policy. tem, and process scope. Endpoint, recipient, namespace, method, and Operation authority, effective principal, endpoint scope, Alternate clients require the same policy and lease. idempotency. and call lease. Patch, branch, PR, workflow, and CI Allowed paths, base commit, old/new blobs, modes, and Patch bytes cannot execute raw or replay on another changes. state delta. base. Store, retrieve, summarize, and repair events. Influence provenance, freshness, parent records, and Unlabeled or stale memory reads fail closed. destination scope. Agent target, task, permissions, and event Delegation target, task scope, permissions, and invoca- Opaque data reentry is treated as W. capability. tion authority. Dependency, registry, workflow, and install- Registry scope, workflow privilege, policy files, and Install-hook and workflow side effects require adapter hook changes. exact-effect validator. authority.
Shell/process Network/API Repository Memory/state Delegation/bots Package/CI
Authority checked
Negative bypass check
a policy class, and creates a contract naming the field path, blocked authority ranges, and any trusted or typed-release regions allowed for that field. The reference implementation decode_protected_field constructs the field projection, rejects raw W, opaque data, cross-field releases, wrongdomain authority, undeclared parents, and unsupported serving paths, and emits a backend evidence record only for a completed field. This reference implementation is the reference target for optimized serving paths; open-weight utility and hosted/API compatibility are evaluated separately. Optimized paths reuse the same projection and evidence record schema while adding lineage-compatible cache keys, batch-slot metadata checks, repeated-field nonce rejection, and fail-closed preflight for CUDA graph replay and speculative decoding. The evaluated open-weight serving implementation integrates with vLLM’s paged KV-cache runtime [19] and attention optimizations [7, 21, 51, 53]; the Triton path sets attention scores from protected X query tokens to blocked Wderived key tokens to −∞ before softmax. An active mask on an unsupported backend path fails before execution. Table 3 gives the reference target and evidence checks: direct-span, suffix-taint, and runtime-map rows check direct W-source, generated-prefix, and declared active K/V influence-map exclusion rather than full field-closed model independence.
and protected-field binding used for admission; remote attestation against a compromised host would require a separate mechanism. Hosted/API compatibility. Hosted APIs expose neither attention masks nor KV-cache labels, so this path cannot rely on provider internals for exclusion. Instead, it records a fieldlocal construction boundary: an extractor may read the trusted objective and writable context, but it emits only typed facts, provenance records, and opaque data handles. Protected fields are then assembled only from trusted policy and valid typed releases or by a field-specific writer whose visible inputs are trusted state plus typed releases for that destination. The API record documents which inputs the host controlled, while provider-internal decoder dependencies remain inside the hosted provider. Serving optimizations are allowed only when they preserve CXI metadata.
5 5.1
Evaluation and Results Methodology
Endpoint. The evaluation tests an admission boundary, not a single benchmark score. The primary security endpoint is unauthorized execution: a protected-field value, invocation event, or sink-interpreted effect reaching the sink without the corresponding authority. Proposal pressure, canonical-action yield, benign-call recall, backend evidence validity, and finalstate quality are reported separately; escape is reserved for unauthorized execution. Surfaces and setup. The evaluation covers six surfaces: openweight field projection, AgentDojo task episodes, code-agent exact-effect tasks, manifest-bound ledger faults, proposal pressure before the gate, and hosted/API compatibility. Deterministic rows are fixed checks and fault-injection tests; sampled rows report recorded behavior. Open-weight sampled runs used NVIDIA H100 80GB HBM3 GPU hosts with driver 570.172.08, CUDA 12.8, PyTorch 2.11.0+cu128, and vLLM 0.21.1rc1.dev268 precompiled builds; GPT-OSS used native
4.4 Evidence Verification and Hosted/API Compatibility Backend evidence verification. A protected-field backend evidence record binds evidence to one field in one action. The verifier recomputes the canonical action digest, checks freshness and field binding, confirms a supported backend path, enforces the policy minimum evidence mode, checks input, influence-map, cache-lineage, and trusted-snapshot bindings, and then runs the normal gate. Anti-downgrade rejects directspan evidence when policy requires suffix-taint, runtime-map, or field-closed evidence. Any repair, retry, or edit to a protected field changes the digest and requires a fresh protectedfield decode [1, 41, 50]. These records prove the backend path 8
MXFP4. This is the machine and serving setup, not a result category. Model matrix. Open-weight IDs are Qwen/Qwen3.6-27B, google/gemma-3-27b-it, openai/gpt-oss-120b, and Qwen/Qwen3-Coder-30B-A3B-Instruct. Archived hosted/API IDs are gpt-5.5, claude-opus-4-7, claude-sonnet-4-6, and gemini-3.5-flash; hosted aliases are archived record identifiers. Open-weight vLLM rows use temperature 0.0 and 64 generated tokens; the appendix records model-specific context, precision, quantization, and hosted/API parameters. Accounting. One scorer keeps task success, field/effect/invocation integrity, safe-task-completion, evidence-valid actions, admissions, attempts, effects, failclosed outcomes, and false suppressions as separate columns. Each case fixes trusted task state, writable sources, candidate sink, field classes, declassifiers, opaque slots, and expected outcome before model output is scored; records include the proposed action, influence sets, gate decision, model settings, and backend evidence or API-boundary record. Deployment audits cover 100 utility workflows and 270 typed or opaque steps.
5.2
the reference behavior: one protected field, a physical fieldspecific projection, fresh prefill/KV in the reference path, field grammar, and host assembly. The open-weight serving rows then test serving-path and utility evidence checks against that target. Unmasked shared decoding is an unsafe control; directspan and suffix-taint are ablation contracts; runtime-map exclusion is a declared-atom check; Hosted/API field-local is a compatibility check rather than provider-internal mask, attention, or KV-lineage evidence. The model matrix identifies where the evidence was observed; Table 7 identifies what each evidence surface contributes before the common gate: field, effect, and invocation evidence for the same admission check. These rows define the evaluated claim boundary; provider internals, validator completeness, and external exactly-once delivery require separate checks. CXI-Core focuses on code agents because they combine attacker-writable inputs with high-impact repository, shell, package, ticket, and CI actions. The evaluation spans four open-weight models and four hosted/API models; the appendix records the model and runtime settings and summarizes the evidence boundaries. Hosted rows are archived compatibility traces. Evidence details. CXI uses one sink predicate in openweight and hosted/API settings, but the evidence differs. Open-weight rows attach backend evidence to protected-field generation. Hosted/API rows attach host-observed construction evidence: field writers receive trusted state plus fieldvalid typed releases, opaque data stay out of writer context, and the same final gate checks the assembled action. Availability is reported separately from evidence validity in both paths. Open-weight backend evidence. CXI distinguishes the fieldclosed target from narrower evidence checks. Field-closed decoding generates each protected field from a field-valid projection with clean cache lineage and binds the value into the final action manifest. The open-weight serving rows are checks toward that target: direct-span exclusion covers declared raw W source keys but not generated prefixes or other atoms; suffix-taint exclusion covers both raw W keys and generated W-derived prefixes; and runtime-map exclusion is a backend ablation over declared runtime influence atoms for cross-field D, opaque, W, and wrong-trusted relay risks. Full causal taint over internal transformer state requires stronger serving support. The gate requires a matching backend evidence record for each protected field. In the direct-span validation run, each of the four fixed openweight model/backend pairs decodes 768 protected fields with no runtime-visible W source positions exposed to the privileged field; matched unmasked records are rejected and invalid evidence admissions remain 0.000. Direct-span evidence covers declared raw W source keys only. Runtime-map rows add declared-atom checks and fail closed before the sink when canonical action construction or evidence validation is incom-
Evaluated Surfaces and Denominators
Table 6 is the main accounting table. It reports the evaluated surfaces, their units, the evidence produced before execution, and the boundary outcome observed at the mediated sink. The rows use different unit types and should not be averaged: AgentDojo and code-agent measure live task surfaces, the ledger row measures deterministic admission faults, and the hosted/API row measures archived field-local compatibility. Safe task completion is meaningful only for live task episodes; the integrity columns are the admission boundary. The table is not a single-score scoreboard. AgentDojo STC uses all six live conditions, while the AgentDojo field records, leases, and exact-effect authorizations come only from exacteffect admission conditions. The code-agent benchmark exercises the exact-effect and manifest design in Section 3.5, reporting safe task completion separately from parse failures, parse-ok rows without effect authorization, and authorized executions that still miss the task oracle. These are utility, parser, validator, or task-quality outcomes, not field/effect/invocation escapes. For the code-agent benchmark, non-STC decomposes as 73 parse failures, 61 parse-ok rows with no effect authorization, and 35 authorized/executed rows without task success.
5.3
Evidence Contributions to Admission
Evidence ladder. The open-weight rows form an evidence ladder rather than interchangeable claims, following the design hierarchy in Table 3. Field-closed reference decoding is 9
Table 6: Main evaluated surfaces and denominators. Rows use different units and are not averaged. Task utility is meaningful only for live episodes; integrity outcomes refer to mediated admission. Surface
Unit / N
AgentDojo live task bank 720 episodes
Task utility
Admission evidence
199 STC
1,739 LLM calls; exact-effect subset: 306 field records, 204 no observed leases/effects field/effect/invocation escapes in protected admissions 306 field records; 204 exact-effect authorizations 0/0/0 field/effect/invocation exact-effect authorization + manifest verification + capability 0/0/0 consume + lease field/effect/invocation
AgentDojo exact-effect 204 leases – admissions Code-agent exact-effect 400 repo 231 STC benchmark episodes Manifest-bound ledger faults Hosted/API field-local compatibility
10 cases / 29 – consumes 800 archived – rows
Boundary outcome
19 rejects; 2 deduplicated retries 85 unsafe selections blocked; 0 parse failures
0 duplicate sions/applications 0 gate escapes
Accounting note STC across six live conditions
not a standalone STC denominator 73 parse failures; 61 no effect authorization; 35 taskquality failures admis- adapter-contract claim no provider-internal decoder evidence
Table 7: Evidence contributions to the admission boundary. Each row names the evidence contributed before the common manifest-bound gate. Different deployments expose different evidence, but all feed the same field/effect/invocation admission check. Evidence source
Boundary role
Field-closed reference Protected-field authority Open-weight serving check Protected-field authority Direct-span / suffix-taint / Open-weight evidence checks runtime-map Hosted/API field-local Compatibility evidence Exact-effect adapter Effect authority Manifest-bound ledger Invocation authority
What it contributes Reference target for field-local authority and host assembly. Serving-path check against the field-closed target. Increasingly stronger exclusion checks over declared W influence before a protected field is admitted. Host-visible construction evidence when provider internals are unavailable. Binds a sink-interpreted payload to the authorized semantic effect. Consumes the matching capability, suppresses duplicate admissions under the adapter contract, and issues the execution lease.
5.4
plete. These rows cover declared source and atom checks; complete KV-lineage independence would require stronger backend evidence. Detailed backend roles are summarized in the appendix.
Proposal Pressure Before Admission
Figure 3 summarizes the pressure rows as a pre-gate measurement. Each row keeps its own denominator; the point is not an average, but the contrast between unsafe proposal behavior before admission and zero observed executed escapes at the mediated sink. The rows are 196/300 unauthorized field proposals for the utility adversarial setting, 407/522 unauthorized field proposals for stress rows, 85/400 unauthorized field proposals for hosted/API adversarial rows, and 45 unauthorized field plus 16 unauthorized invocation proposals over 240 free-form actions.
Hosted/API compatibility and offline mapping. Hosted APIs expose no attention masks, KV-cache labels, or backend evidence records. The Hosted/API field-local compatibility path therefore checks host construction: a reader may see raw W, but protected-field writers see only trusted state and typed releases valid for that field. Across 800 archived proposals, the host-observed API compatibility path blocks 85 unsafe selections and records 0 gate escapes and 0 parse failures. This evidence supports hosted/API compatibility while providerinternal decoder state, attention masks, and KV lineage remain unavailable.
unauthorized proposals before gate Utility adversarial Stress rows Hosted/API adversarial Free-form actions
Offline policy mappings are reported separately from live task success. The final mapping audit covers CXI-Core 192, AgentDojo 609, and ToolEmu 144 denominators and records no observed unauthorized admissions in the archived compatibility rows. The broader evaluated task-bank run records 720 episodes, 1,739 live LLM calls, 306 backend field evidence records, 204 leases, 204 exact-effect authorizations, and 199 safe task completions across all six defense conditions. Non-STC leased episodes are task-quality, availability, or model-output outcomes rather than field, invocation, or effect escapes. Validator completeness beyond the evaluated AgentDojo suite is not claimed.
196/300 field
executed escapes 0
407/522 field
0
85/400 field
0
45+16 / 240
0
Figure 3: Proposal pressure before admission. Bars show unauthorized proposals before the CXI gate; right-hand boxes show executed escapes at the mediated sink. The figure measures model proposal pressure; backend evidence is evaluated separately. Rows use different denominators and are not averaged. 10
Choice pressure. Models still choose unauthorized fields when attack cases offer them, which is why CXI enforces authority at the sink. In the proposal-before-gate experiments, the model chooses between an authorized typed or opaque action and an unauthorized raw-W action; candidate identifiers are opaque, and the gate runs only after the choice. These rows measure proposal pressure; backend evidence is evaluated separately. The field-policy prompt reduces the open-weight utility adversarial subset to 67/300, while the hosted field-policy prompt produces 0/400 in the archived run. Call-level proposal pressure is measured separately. Free-form construction. Two free-form construction assays build complete action objects from task text rather than choosing between opaque candidate IDs. The 60-case deterministic free-form construction assay records 40 unauthorized field proposals, no unauthorized invocation proposals, no executed field or invocation escapes, and 20 benign executions. The open-weight free-form run emits 240 free-form action objects across the four open-weight models. All 240 are parseable; the runs record 45 unauthorized field proposals, 16 unauthorized invocation proposals, no field or invocation escapes reaching execution, and 60 benign executions. GPT-OSS emits call=false for all 20 benign cases in this policy-aware freeform setting. Benign-call outcomes are reported as availability metrics. The takeaway is narrow: unauthorized proposal pressure appears before enforcement and varies by model and prompting condition; decoder dependencies, backend evidence, and task quality are evaluated at other boundaries.
authorized approval declassifier validates a trusted approval reference. Mechanism baselines. We also include a mechanism-level baseline suite beyond schema checks. These rows isolate which authority checks are lost without CXI’s sink-and-field specialization; they are not implementation-level comparisons with PACT, CaMeL, FIDES/PFI, or ARGUS. “Argument-role provenance approximation” rejects 12/20 attack cases and preserves 6/6 utility cases but leaves call-event and backendbinding failures; “field-scoped capabilities, no call ledger” rejects 10/20 attacks but leaves invocation-authority failures; and “typed reader/writer plus call ledger, no field gate” rejects 8/20 attacks but leaves cross-field typed-release reuse, evidence record substitution, opaque reentry, and effect-bearing payloads. The CXI row rejects 20/20 attack cases while preserving 6/6 utility cases.
5.6 Why the CXI Mechanisms Are NonInterchangeable The mechanisms in CXI are not interchangeable. Transitive provenance blocks summary and memory laundering; destination scope blocks one-field releases from authorizing another field; semantic validators constrain typed outputs; opaque reentry keeps copied evidence from becoming safe forever. Backend evidence binding blocks replay, mutation, and schema-repair substitution. The distilled map is: shape-valid laundering still needs a field-local gate; summary laundering needs transitive provenance; wrong-field D reuse needs destination scope; W-controlled retry or batching needs capability consume; opaque reentry remains W; effect-bearing payloads need exact-effect authorization; and stale or substituted backend records need manifest-bound evidence binding. Focused witnesses. Focused witness suites cover reviewerraised corner cases without model sampling. Field-authority witnesses exercise wrong trusted authority, cross-field D reuse, value-digest mismatch, action-context mismatch, closed optional-schema branches, and unmediated alternate sinks. Invocation-authority witnesses exercise W-controlled retries, batch cardinality, sequence order, idempotency keys, schedule time, missing invocation capabilities, ambiguous capability identifiers, and the requirement that an accepting call consumes the same selected capability identifier and receives an execution lease. Semantic sink-binding witnesses check that the authorized object is the object consumed after parser, canonicalizer, trusted-snapshot, renderer, and resolver effects. These tests check distinct failure modes; aggregate ablations are reported separately. Field-authority binding covers 8 cases with 7 field proposals, no executed field or call escapes, and 1 accept; invocation-authority binding covers 34 cases with 25 call proposals, no executed escapes, and 9 accepts; semantic sink binding covers 8 cases with 6 field proposals, no executed escapes, and 2 accepts. Ledger witnesses. Ledger witnesses exercise admission sep-
5.5 Schemas and Summaries Do Not Carry Authority Schema baseline. Schema validation checks form, not authority. Across all 192 CXI-Core cases, a raw co-resident context can read W and choose side effects directly: W-derived X is 1.000, malicious-sink use is 1.000, benign admission is 0.000, and unauthorized execution is 1.000. Schema-only structured output constrains JSON shape but still allows W-derived values to fill X fields: W-derived X remains 1.000, malicioussink use falls to 0.000, benign admission rises to 1.000, and unauthorized execution remains 1.000. The CXI boundary checks source authority instead: the field must carry trusted authority or a destination-scoped typed release. Its 192-case row reports W-derived X=0.000, malicious-sink use=0.000, benign admission=1.000, and unauthorized execution/gate escape=0.000. The same evidence can receive different decisions in different fields. A W-derived approved string is rejected for approval_state; a W-derived path validated as FilePath is admitted only for arguments.file_path; and a PR body may carry opaque evidence but re-enters as W if a later bot or agent uses it to create side effects. Free-form summaries fail for the same reason: “approved” remains W-derived unless an 11
arately from external-effect multiplicity. Table 6 reports the manifest-bound rerun: 10 cases, 29 consume attempts, 19 rejections, 2 deduplicated retries, no duplicate admissions, and no duplicate external applications. Additional concurrent stress and crash/recovery campaigns also record no doublespends under the declared idempotent-adapter contract. This is duplicate suppression under the adapter contract, not a general exactly-once external-effect claim. Typed releases are the utility mechanism: removing them leaves the gate conservative, but useful W-derived facts can no longer cross into protected fields. These tests show distinct failure paths; they are not prevalence estimates for arbitrary deployments.
5.7
184/195 assertion passes. The 11 review-required cases are ordinary task-quality issues such as missing regression tests, install-hook review, ambiguous current-source evidence, approval/delegation scope review, namespace review, reentry scope review, and stale status review. Task success still depends on tests, review, and application-specific quality checks.
5.8
Cost and Policy Effort
The cost rows report boundary overhead rather than production throughput. The open-weight CXI-Core evidence record path reports wall seconds per case plus peak CUDA reserved memory; mask construction is about 0.16 ms per case at the median (0.04 ms per protected field), so model execution and loading dominate. Hosted/API rows are slower because each case uses structured reader and writer round trips; full-request API latency ranges are 9.328–15.275 seconds for AgentDojo hosted rows and 10.672–14.017 seconds for ToolEmu hosted rows. The backend evidence footprint is about 677 bytes per case for four protected fields. This cost measurement excludes vLLM worker peak memory because the process-local CUDA snapshot does not capture worker VRAM. Canonical JSON parseability is reported separately from backend evidence validity. Policy effort. CXI also exposes the policy work required to mediate representative sinks. This policy-surface audit covers 24 evaluated sinks: 149 fields, 85 X fields, 20 D fields, 29 O fields, 19 effect-bearing payloads, and 141 validator tests. The initial 18 findings include missing effect-bearing payloads, over-broad opaque slots, missing destination scopes, naturallanguage approval, unmarked reentry, and validator scope gaps. The regenerated audit records 9 high-severity and 9 medium-severity findings, no unclassified findings, and no final blockers for the evaluated policy set. This supports the evaluated policies; independently written policies still need review.
Boundary Utility and Task Quality
Boundary utility. CXI keeps two utility channels open: typed releases carry narrow facts for declared fields, and opaque data slots preserve evidence in comments, tickets, PR bodies, or reports without granting authority to that text. The same Wderived values are rejected when reused as tool, operation, or approval_state. We run 100 workflows over 270 boundary steps so utility is measured across complete boundary steps, not isolated fields. The suite covers 50 code-agent workflows over 150 steps, 20 Web/RAG workflows over 60 steps, 12 productivity workflows over 24 steps, 10 ops workflows over 20 steps, and 8 memory workflows over 16 steps. All declared workflows succeed at the boundary with no observed false blocks: typed values are admitted only at destination scope, opaque payloads are preserved, and matching raw-W probes are rejected for the same field. This measures boundary utility, not end-toend task success. The remaining utility risks are practical policy risks: underspecified scopes, over-narrow validators, missing opaque slots, and effect-bearing payloads classified as ordinary data. Validator assurance. Validator assurance is field-dependent. The policy-surface audit separates syntactic validators, trusted-lookup validators, and semantic/effect-bounding validators; it records 20 D types over 21 audited occurrences, 20 sinks, and 134 tests. A deterministic sandboxed code-agent check over issue, README, CI-log, package-metadata, tooloutput, and retry risks shows why this matters: across 48 episodes, no-gate and schema-only conditions admit all six unsafe actions; the argument-role provenance approximation leaves one patch-payload gap and one retry gap; CXI blocks the unsafe actions and preserves the six clean actions. The same harness checks 28/28 exact-effect authorization cases over repository state-delta effects. This sandbox/oracle check is reported separately from live LLM benchmarks. Task-quality audit. We also run a 40-task final-state audit to keep task utility separate from boundary utility. All 40 representative tasks complete the boundary, 29 satisfy task-level assertions without follow-up review, and the audit records
6
Discussion
Execution is the boundary. CXI evaluates security at the moment a candidate action becomes an external effect. Unsafe proposals are attack pressure; the relevant measure is whether an unauthorized field, effect, or invocation reaches a mediated sink. The AgentDojo and code-agent rows support this admission claim under fixed policies, snapshots, adapters, and task banks. Validator completeness, task quality, and unreviewed sinks remain separate concerns. Authority is local. A log line may be quoted as opaque evidence, a path extracted from it may fill one file_path field after a typed release, and the same text still has no authority for operation, approval_state, ci_target, or retry state. 12
Effect-bearing payloads need adapter-specific authorization because the authorized object is the sink-interpreted effect, not the payload spelling. CXI does not ask whether text is generally trustworthy, but whether a specific value, effect, or invocation event carries authority for this sink manifest.
LLM agents and policy enforcement [5, 17, 29]. CXI uses this lineage narrowly: it records enough field, effect, and invocation evidence for the host to reject one concrete sink call when the authority chain does not close. Action authority and capabilities. ARGUS and AIRGuard also check action authority near execution [31, 46]. CXI’s contribution is a deterministic predicate over a canonical sink object: verify protected fields, consume the matching invocation capability, and execute only with the resulting lease. This follows the confused-deputy and capability tradition [1, 15, 22, 37, 41, 43, 44, 50]. CaMeL extracts control and data flows from a trusted query and executes the resulting program with capabilities [8]; CXI operates later, checking candidate actions at admission time. A candidate action can be syntactically valid, policy-shaped, and useful while still lacking authority for the field, interpreted effect, or invocation event that would make it execute.
Policy remains trusted work. Every mediated sink needs field classification, field-scoped declassifiers, exact-effect validators, opaque slots, bypass tests, and complete mediation. Broad validators, wrong field classes, unmediated sinks, or compromised runtimes still break the guarantee; CXI makes that work explicit and does not infer missing policy. The policy author must decide which fields select authority, which payloads are interpreted by the sink, and which alternate entry points could bypass the gate. The appendix summarizes the audited sink families, bypass checks, adapter checks, and residual-risk examples. Evidence differs by regime. Open-weight deployments can verify protected-field decoding with backend evidence records that bind each field to a single manifest before admission. Hosted/API deployments cannot see provider internals, so they use the same admission rule with host-observed compatibility evidence instead. That means hosted/API checks can confirm the action fits the gate, but they do not prove provider-internal enforcement for masks, attention, or KVcache lineage. Remote attestation against a compromised host and coverage for each transformer implementation still need separate mechanisms; open-weight serving checks can exercise the actual serving path.
Prompt defenses, serving stacks, and benchmarks. Prompt-injection defenses, instruction hierarchies, StruQ, Prompt Control-Flow Integrity, guards, judges, sanitizers, and priority-aware middleware reduce unsafe proposals or prompt-flow confusion [2–4, 14, 24, 30, 42, 45, 55]. CXI assumes unsafe proposals may still occur and checks authority before execution. High-throughput serving stacks introduce KV-cache reuse, batching, custom attention kernels, guided decoding, and fast paths [6, 7, 19, 21, 38, 51, 53]; CXI requires backend evidence for supported paths and fail-closed behavior for unsupported ones. Tool-use benchmarks provide task environments [9, 16, 20, 23, 32, 39, 47, 48, 54]; CXI keeps benchmark utility separate from admission integrity.
Takeaway. The model proposes actions, but the host admits only manifest-bound actions that tie protected fields, interpreted effects, and the invocation event to the same sink authority. A field, payload effect, or retry event is admitted only when the corresponding authority object is present and valid. Unsafe text may shape a proposal, but it only becomes authority through a typed release, exact-effect authorization, or invocation capability.
7
8
Conclusion
LLM agents read untrusted text and act through real tools with external effects. CXI makes that transition explicit by admitting only actions whose field evidence, exact-effect authorization, and invocation capability all bind to the same canonical manifest before the mediated sink executes. It makes the action admissible only when the gated authority chain is complete. Untrusted evidence may still be quoted, summarized, validated into a typed release, or bound to an authorized effect. Those uses preserve provenance, but they do not silently grant authority for a different field, effect, or invocation event. This is a concrete systems property for mediated sinks. It does not make validators complete, tasks correct, provider internals observable, or external effects exactly-once on its own. What it does do is make the final step from context to execution explicit, checkable, and fail-closed: before the host grants execution, the fields, effects, and invocation event must each point to where their authority came from.
Related Work
Argument provenance and agent IFC. CXI’s novel contribution is not provenance, IFC, nor capabilities; it specializes them to manifest-bound admission of mixed-authority tool actions. PACT identifies the granularity mismatch in agent security: whole-call trust is too coarse when only some arguments carry authority [12]. CXI targets admission: plausible arguments may still lack authority to occur, recur, batch, schedule, consume budget, or spend an idempotency token. Classical IFC supplies labels, integrity, noninterference, and declassification [10, 11, 13, 18, 25, 26, 33, 34, 40, 52]; FIDES, Prompt Flow Integrity, and FORGE bring related ideas to 13
Ethics Considerations
control-flow integrity: A priority-aware runtime defense against prompt injection in LLM systems. https: //arxiv.org/abs/2603.18433, 2026.
This work evaluates a boundary for side-effect authority in tool-using agents. The experiments use public benchmarks, synthetic action-selection cases, sandboxed repositories, and archived API traces; they do not access real user accounts, secrets, payments, or production services. Attack cases are evaluated as candidate actions, gate decisions, and sandboxed effects rather than dangerous live side effects. The main dual-use risk is that failure examples may help attackers reason about prompt-injection and authoritylaundering patterns. The release therefore emphasizes policies, declassifier contracts, gate decisions, evidence records, and aggregate results rather than operational playbooks against live systems.
[3] Patrick Chao, Alexander Robey, Edgar Dobriban, Hamed Hassani, George J. Pappas, and Eric Wong. Jailbreaking black box large language models in twenty queries. https://arxiv.org/abs/2310. 08419, 2023. [4] Sizhe Chen, Julien Piet, Chawin Sitawarin, and David Wagner. StruQ: Defending against prompt injection with structured queries. In 34th USENIX Security Symposium, pages 2383–2400. USENIX Association, 2025. [5] Manuel Costa, Boris Köpf, Aashish Kolluri, Andrew Paverd, Mark Russinovich, Ahmed Salem, Shruti Tople, Lukas Wutschitz, and Santiago Zanella-Béguelin. Securing AI agents with information-flow control. https: //arxiv.org/abs/2505.23643, 2025.
Open Science An anonymous review artifact is available at https: //anonymous.4open.science/r/cxi. The primary entry point is submission_artifact/. The release contains the operational audit material for the paper: policy and toolschema manifests, field classifications, declassifier specifications and negative tests, gate decisions, backend evidence records, manifest-bound ledger traces, benchmark mappings, frozen result records, generated tables, checksums, and aggregate-table regeneration scripts. The default audit path regenerates the reported tables and proposal-pressure figure from checked-in records and requires no provider API keys, model weights, GPU access, or production service access. Run manifests tie sampled rows to model settings, policy hashes, source hashes, and result hashes so compatible serving stacks can replay the backend-evidence checks. Live openweight and hosted/API reruns are documented as optional reruns rather than required review steps. Hosted/API results are archived compatibility traces rather than provider-internal evidence. They preserve requested model identifiers, returned identifiers where available, timestamps, provider settings, request/response traces, selections, gate decisions, and boundary evidence, but cannot expose provider-internal attention, masks, or KV-cache lineage. Released records exclude credentials, local machine addresses, local paths, and author-identifying metadata.
[6] Tri Dao. FlashAttention-2: Faster attention with better parallelism and work partitioning. In International Conference on Learning Representations, 2024. [7] Tri Dao, Daniel Y. Fu, Stefano Ermon, Atri Rudra, and Christopher Ré. FlashAttention: Fast and memoryefficient exact attention with IO-awareness. In Advances in Neural Information Processing Systems, 2022. [8] Edoardo Debenedetti, Ilia Shumailov, Tianqi Fan, Jamie Hayes, Nicholas Carlini, Daniel Fabian, Christoph Kern, Chongyang Shi, Andreas Terzis, and Florian Tramèr. Defeating prompt injections by design. https://arxiv. org/abs/2503.18813, 2025. [9] Edoardo Debenedetti, Jie Zhang, Mislav Balunović, Luca Beurer-Kellner, Marc Fischer, and Florian Tramèr. AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. In The Thirty-Eighth Annual Conference on Neural Information Processing Systems, Datasets and Benchmarks Track, 2024. [10] Dorothy E. Denning. A lattice model of secure information flow. Communications of the ACM, 19(5):236–243, 1976.
References [1] Martín Abadi, Mihai Budiu, Úlfar Erlingsson, and Jay Ligatti. Control-flow integrity: Principles, implementations, and applications. In Proceedings of the ACM Conference on Computer and Communications Security, 2005.
[11] Petros Efstathopoulos, Maxwell Krohn, Steve VanDeBogart, Cliff Frey, David Ziegler, Eddie Kohler, David Mazières, Frans Kaashoek, and Robert Morris. Labels and event processes in the asbestos operating system. In Proceedings of the ACM Symposium on Operating Systems Principles, 2005.
[2] Md Takrim Ul Alam, Akif Islam, Mohd Ruhul Ameen, Abu Saleh Musa Miah, and Jungpil Shin. Prompt
[12] Linfeng Fan, Ziwei Li, Yuan Tian, Yichen Wang, Rongsheng Li, and Xiong Wang. The granularity mismatch 14
in agent security: Argument-level provenance solves enforcement and isolates the LLM reasoning bottleneck. https://arxiv.org/abs/2605.11039, 2026.
[22] Henry M. Levy. Capability-Based Computer Systems. Digital Press, 1984. [23] Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, Shudan Zhang, Xiang Deng, Aohan Zeng, Zhengxiao Du, Chenhui Zhang, Sheng Shen, Tianhua Zhang, Yu Su, Huan Sun, Minlie Huang, Yuxiao Dong, and Jie Tang. AgentBench: Evaluating LLMs as agents. In International Conference on Learning Representations, 2024.
[13] Joseph A. Goguen and José Meseguer. Security policies and security models. In IEEE Symposium on Security and Privacy, pages 11–20, 1982. [14] Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. Not what you’ve signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. In Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security, pages 79–90, 2023.
[24] Anay Mehrotra, Manolis Zampetakis, Paul Kassianik, Blaine Nelson, Hyrum Anderson, Yaron Singer, and Amin Karbasi. Tree of attacks: Jailbreaking black-box LLMs automatically. https://arxiv.org/abs/2312. 02119, 2023.
[15] Norman Hardy. The confused deputy: Or why capabilities might have been invented. http://cap-lore. com/CapTheory/ConfusedDeputy.html, 1988. Accessed 2026-06-27.
[25] Andrew C. Myers. JFlow: Practical mostly-static information flow control. In Proceedings of the ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 1999.
[16] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. SWE-bench: Can language models resolve real-world GitHub issues? In International Conference on Learning Representations, 2024.
[26] Andrew C. Myers and Barbara Liskov. Protecting privacy using the decentralized label model. ACM Transactions on Software Engineering and Methodology, 9(4):410–442, 2000.
[17] Juhee Kim, Woohyuk Choi, and Byoungyoung Lee. Prompt flow integrity to prevent privilege escalation in LLM agents. https://arxiv.org/abs/2503.15547, 2025.
[27] Reiichiro Nakano, Jacob Hilton, Suchir Balaji, Jeff Wu, Long Ouyang, Christina Kim, Christopher Hesse, Shantanu Jain, Vineet Kosaraju, William Saunders, Xu Jiang, Karl Cobbe, Tyna Eloundou, Gretchen Krueger, Kevin Button, Matthew Knight, Benjamin Chess, and John Schulman. Webgpt: Browser-assisted question-answering with human feedback. https: //arxiv.org/abs/2112.09332, 2021.
[18] Maxwell Krohn, Alexander Yip, Micah Brodsky, Natan Cliffer, M. Frans Kaashoek, Eddie Kohler, and Robert Morris. Information flow control for standard OS abstractions. In Proceedings of the ACM Symposium on Operating Systems Principles, 2007. [19] Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. Efficient memory management for large language model serving with PagedAttention. In Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, 2023.
[28] OWASP Foundation. OWASP LLM01:2025 prompt injection. https://genai.owasp.org/llmrisk/ llm01-prompt-injection/, 2025. Accessed 202606-27.
[20] Thibault Le Sellier de Chezelles, Maxime Gasse, Alexandre Lacoste, Massimo Caccia, Alexandre Drouin, Léo Boisvert, Megh Thakkar, Tom Marty, Rim Assouel, Sahar Omidi Shayegan, Lawrence Keunho Jang, Xing Han Lù, Ori Yoran, Dehan Kong, Frank F. Xu, Siva Reddy, Graham Neubig, Quentin Cappart, Russ Salakhutdinov, and Nicolas Chapados. The BrowserGym ecosystem for web agent research. Transactions on Machine Learning Research, 2025.
[29] Nils Palumbo, Sarthak Choudhary, Jihye Choi, Guy Amir, Prasad Chalasani, and Somesh Jha. Formal policy enforcement for real-world agentic systems. https: //arxiv.org/abs/2602.16708, 2026. [30] Fábio Perez and Ian Ribeiro. Ignore previous prompt: Attack techniques for language models. https:// arxiv.org/abs/2211.09527, 2022.
[21] Yaniv Leviathan, Matan Kalman, and Yossi Matias. Fast inference from transformers via speculative decoding. In International Conference on Machine Learning, pages 19274–19286, 2023.
[31] Suliu Qin, Haomin Zhuang, Yujun Zhou, Yufei Han, and Xiangliang Zhang. AIRGuard: Guarding agent actions with runtime authority control. https://arxiv.org/ abs/2605.28914, 2026. 15
[32] Yangjun Ruan, Honghua Dong, Andrew Wang, Silviu Pitis, Yongchao Zhou, Jimmy Ba, Yann Dubois, Chris J. Maddison, and Tatsunori Hashimoto. ToolEmu: Identifying the risks of LM agents with an LM-emulated sandbox. In International Conference on Learning Representations, 2024.
[43] Robert N. M. Watson, Jonathan Anderson, Ben Laurie, and Kris Kennaway. Capsicum: Practical capabilities for UNIX. In USENIX Security Symposium. USENIX Association, 2010. [44] Robert N. M. Watson, Jonathan Woodruff, Peter G. Neumann, Simon W. Moore, Jonathan Anderson, David Chisnall, Nirav Dave, Brooks Davis, Khilan Gudka, Ben Laurie, Steven J. Murdoch, Robert Norton, Michael Roe, Stacey Son, and Munraj Vadera. CHERI: A hybrid capability-system architecture for scalable software compartmentalization. In IEEE Symposium on Security and Privacy, 2015.
[33] Andrei Sabelfeld and Andrew C. Myers. Languagebased information-flow security. IEEE Journal on Selected Areas in Communications, 21(1):5–19, 2003. [34] Andrei Sabelfeld and David Sands. Declassification: Dimensions and principles. Journal of Computer Security, 17(5):517–548, 2009.
[45] Alexander Wei, Nika Haghtalab, and Jacob Steinhardt. Jailbroken: How does LLM safety training fail? In Advances in Neural Information Processing Systems, 2023.
[35] Jerome H. Saltzer and Michael D. Schroeder. The protection of information in computer systems. Proceedings of the IEEE, 63(9):1278–1308, 1975. [36] Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools. In Advances in Neural Information Processing Systems, 2023.
[46] Shihao Weng, Yang Feng, Jinrui Zhang, Xiaofei Xie, Jiongchi Yu, and Jia Liu. ARGUS: Defending LLM agents against context-aware prompt injection. https: //arxiv.org/abs/2605.03378, 2026. [47] Tianbao Xie, Danyang Zhang, Jixuan Chen, Xiaochuan Li, Siheng Zhao, Ruisheng Cao, Toh Jing Hua, Zhoujun Cheng, Dongchan Shin, Fangyu Lei, Yitao Liu, Yiheng Xu, Shuyan Zhou, Silvio Savarese, Caiming Xiong, Victor Zhong, and Tao Yu. OSWorld: Benchmarking multimodal agents for open-ended tasks in real computer environments. In The Thirty-Eighth Annual Conference on Neural Information Processing Systems, Datasets and Benchmarks Track, 2024.
[37] Jonathan S. Shapiro, Jonathan M. Smith, and David J. Farber. EROS: A fast capability system. In Proceedings of the ACM Symposium on Operating Systems Principles, 1999. [38] Ying Sheng, Lianmin Zheng, Binhang Yuan, Zhuohan Li, Max Ryabinin, Beidi Chen, Percy Liang, Christopher Ré, Ion Stoica, and Ce Zhang. FlexGen: Highthroughput generative inference of large language models with a single GPU. In International Conference on Machine Learning, 2023.
[48] Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik R. Narasimhan. τ-bench: A benchmark for tool-agent-user interaction in real-world domains. In International Conference on Learning Representations, 2025.
[39] Harsh Trivedi, Tushar Khot, Mareike Hartmann, Ruskin Manku, Vinty Dong, Edward Li, Shashank Gupta, Ashish Sabharwal, and Niranjan Balasubramanian. AppWorld: A controllable world of apps and people for benchmarking interactive coding agents. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics, pages 16022–16076, 2024.
[49] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models. In International Conference on Learning Representations, 2023.
[40] Dennis Volpano, Geoffrey Smith, and Cynthia Irvine. A sound type system for secure flow analysis. Journal of Computer Security, 4(2–3):167–187, 1996.
[50] Bennet Yee, David Sehr, Gregory Dardyk, J. Bradley Chen, Robert Muth, Tavis Ormandy, Shiki Okasaka, Neha Narula, and Nicholas Fullagar. Native client: A sandbox for portable, untrusted x86 native code. In IEEE Symposium on Security and Privacy, 2009.
[41] Robert Wahbe, Steven Lucco, Thomas E. Anderson, and Susan L. Graham. Efficient software-based fault isolation. In Proceedings of the ACM Symposium on Operating Systems Principles, 1993.
[51] Gyeong-In Yu, Joo Seong Jeong, Geon-Woo Kim, Soojeong Kim, and Byung-Gon Chun. Orca: A distributed serving system for transformer-based generative models. In USENIX Symposium on Operating Systems Design and Implementation. USENIX Association, 2022.
[42] Eric Wallace, Kai Xiao, Reimar Leike, Lilian Weng, Johannes Heidecke, and Alex Beutel. The instruction hierarchy: Training LLMs to prioritize privileged instructions. https://arxiv.org/abs/2404.13208, 2024. 16
[52] Nickolai Zeldovich, Silas Boyd-Wickizer, Eddie Kohler, and David Mazières. Making information flow explicit in HiStar. In Proceedings of the USENIX Symposium on Operating Systems Design and Implementation. USENIX Association, 2006.
σW to destination σX , minted by declassifier d after validator v accepts binding b under action constraint κ. O(h, I) is an opaque data handle with parent influence I. Call atoms use the same shape but carry a capability identifier. Unknown, stale, or malformed atoms reject. For a protected field f with value v f , FieldOK( f ) holds when f appears in the active sink schema, P classifies f , Π[ f ] is known and fresh, every atom in Π[ f ] may influence f , and at least one trusted or D atom authorizes the canonical value. Raw W, opaque-only O, cross-field D, wrong-domain T, stale policy versions, repaired protected fields, and missing referenced fields reject. For each sink-interpreted payload,
[53] Lianmin Zheng, Liangsheng Yin, Zhiqiang Xie, Chuyue Sun, Jeff Huang, Cody Hao Yu, Shiyi Cao, Christos Kozyrakis, Ion Stoica, Joseph E. Gonzalez, Clark Barrett, and Ying Sheng. SGLang: Efficient execution of structured language model programs. In Advances in Neural Information Processing Systems, 2024. [54] Shuyan Zhou, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Tianyue Ou, Yonatan Bisk, Daniel Fried, Uri Alon, and Graham Neubig. WebArena: A realistic web environment for building autonomous agents. In International Conference on Learning Representations, 2024.
Table 8: Boundary obligations. Each obligation binds one part of the execution boundary to the same canonical action manifest.
[55] Andy Zou, Zifan Wang, Nicholas Carlini, Milad Nasr, J. Zico Kolter, and Matt Fredrikson. Universal and transferable adversarial attacks on aligned language models. https://arxiv.org/abs/2307.15043, 2023.
What must be bound
Typical failure blocked
Field authority
Protected sink field value, destination scope, policy epoch, trusted snapshot, and action context.
Effect authority
Sink-parsed payload effect under the trusted snapshot, adapter revision, principal, and manifest digest. Call, retry, batch, schedule, or delegation event plus a consumable invocation capability. Every side-effecting route reaches the shared gate before execution.
Copied approval text, wrong-field typed release, stale trusted state, or raw W selecting a protected field. Same patch on another base, path rewrite, SQL role mismatch, or raw command text from W. Stale capability, duplicate consume, wrong-manifest replay, or W-controlled retry. Helper API, alternate client, generated file, bot, or install hook bypassing admission. Evidence substitution, lower evidence mode, repair after evidence, or stale parent record.
Invocation authority
Appendices The appendices provide technical details for readers who want to inspect the admission boundary behind the main text. Appendix A states the boundary obligations; Appendix B gives the operational contract and gate checks; Appendices C– E cover complete mediation, typed releases, exact effects, and mechanism composition; Appendix F records the evaluation setup and model settings; Appendices G–H describe evidence boundaries and the records behind the main result rows; and Appendix I summarizes residual deployment risks.
A
Obligation
Complete mediation
Evidence binding
Field evidence, exact-effect record, ledger consume, policy epoch, snapshot, backend/API profile, and parent records.
Table 9: Operational influence events. CXI tracks what may have selected a value, not only where its bytes came from. Derived values keep W influence until trusted code mints a destination-scoped typed release.
Boundary Obligations at a Glance
Table 8 summarizes the obligations checked before an action becomes executable.
Event
Influence rule
Fail-closed condition
Read trusted state
Adds field- or call-scoped T.
B
Read writable context
Adds W (o) for attacker-writable or attacker-influenced origin o. Union of all visible inputs.
Missing policy, wrong domain, stale snapshot, or untrusted origin metadata. Unknown origin is treated as W.
Operational Contract and Gate Checks
Let an action manifest be m = (sink, op, ρ, ν, σ, η, ⃗f ,⃗p), where ρ is the task/run context, ν the policy epoch, σ the trusted sink snapshot, η the action nonce, ⃗f the protected field assignments, and ⃗p the sink-interpreted payloads. The gate receives policy P, field provenance Π[ f ], call provenance Πcall , effect commitments E, and required backend or field-local evidence records B. Field atoms have four forms. T (p, α, σ, b, ρ, ν) is trusted authority in domain p. W (o) is writable influence. D(τ, σW , σX , d, v, b, κ, ρ, ν, I) is a typed release from W-scope
Summarize/copy text Extract typed fact Memory or tool output Repair/retry/batch Opaque data / reentry
17
Remains W until validator emits D. Preserves prior influence; tool output is W unless policy marks it trusted. Union of candidate, repair context, previous action, and control inputs. Opaque data carries parent influence but no current authority.
Summary later used as authority without D. Type, scope, destination, validator, or policy mismatch. Missing provenance or tool output selects a protected field without D. Protected field or event changes without fresh authority. Later side-effect boundary treats reentry as W.
path, CXI no longer claims admission integrity for that route. The gate can reject an unauthorized manifest; it cannot protect a sink call that bypasses it.
Table 10: Gate checks. Each check is evaluated against one canonical manifest, policy epoch, trusted snapshot, and action context. Predicate
Question
Rejects
M AY I NFLUENCE
May this atom participate in choosing this field or event?
AUTHORIZES VALUE
Does this atom authorize the executed semantic value or effect?
Wrong sink, field, operation, authority domain, destination scope, policy epoch, or action context. Digest mismatch, stale snapshot, wrong adapter, wrong validator, wrong principal, or cross-field D reuse. Payload replay, post-validation mutation, wrong base state, stale policy, or untrusted renderer. No capability, wrong manifest, stale sequence, budget mismatch, or duplicate spend.
E FFECT OK
AUTHORIZE I NVOKE
Does an adapter-specific commitment authorize the sink-interpreted payload? May this call, retry, batch, schedule, or delegation event occur?
Table 11: Side-effect families and bypass checks. The gate protects a deployment only when every side-effect path reaches it. Sink family
Mediated entry points and authority
Negative bypass checks
Filesystem
Write, delete, move, generated files; path, operation, and payload effect require authority. Trusted-rendered argv/env/cwd plus sandbox, network, and filesystem policy. Endpoint, recipient, namespace, method, and idempotency bind to the manifest. Patch, branch, PR, workflow, and CI changes bind path and state delta. Store, retrieve, summarize, and repair preserve provenance. Agent target, task, permissions, and event capability are protected. Dependency, registry, workflow, and install hooks use exact-effect validators.
Direct file APIs and helper paths are denied or wrapped.
Shell/process
Network/API
Repository Memory/state
EffectOK requires an exact-effect authorization over the effect that the sink will apply under the trusted snapshot, policy epoch, principal, adapter revision, and action nonce. For the invocation event, every atom in Πcall must be allowed by invocation policy. The resolver must identify exactly one capability to spend, unless policy declares a deterministic equivalence or priority rule. The selected capability is consumed by a linearizable ledger against digest(m); only the returned lease may reach the sink. Verifier skeleton. The gate first canonicalizes the candidate under the trusted snapshot and rejects malformed, policyincompatible, or post-validation-mutated manifests. It then checks each protected field with M AY I NFLUENCE and AU THORIZES VALUE , verifies required backend or field-local evidence for that field, checks exact-effect commitments for each sink-interpreted payload, resolves one invocation capability, consumes that capability against the digest of the same manifest, and sends only the resulting lease to the mediated sink. The admitted-action contract is therefore
Delegation/bots Package/CI
D
Alternate clients require the same policy and lease. Patch bytes cannot execute raw or replay on another base. Unlabeled or stale memory fails closed. Opaque data reentry becomes W. Install-hook and workflow side effects require adapter authority.
Typed Release and Exact-Effect Contracts
Table 12: Release and effect contracts. A typed release grants one destination-scoped value; exact-effect authorization grants the sink-interpreted effect under the trusted snapshot.
Admit(m) ⇒ Fields(m) ∧ Effects(m) ∧ Invoke(m).
Mechanism
Binding checked
Failure blocked
File path release
Repository-relative path for one destination field after canonicalization and scope check. Trusted approval reference bound to principal, epoch, and action context. Registry-scoped dependency name for one dependency field. State-delta authorization under the trusted repository snapshot. Base commit, canonical paths, old/new blobs, modes, renames, and allowed path set. Sink-parsed payload, role/snapshot, trusted renderer, and sandbox or endpoint policy.
Tool choice, CI target, shell command, or package target.
Approval release
Here Fields(m) means all protected fields satisfy the field predicate; Effects(m) means all sink-interpreted payloads match exact-effect commitments for the same manifest; and Invoke(m) means a manifest-bound capability is consumed into an execution lease. The trusted assumptions are complete mediation, conservative influence tracking, correct policy classification, fail-closed validators, and evidence records that over-approximate influence.
C
Raw shell strings from W do not execute.
Dependency release Patch intent release Repository adapter
patch
File body / SQL / shell adapters
Complete Mediation Checks
These entries are part of the claim, not optional hardening. If a deployment leaves a side-effecting route outside the mediated
Copied “approved” text.
Registry switch or install hook. Arbitrary patch bytes or replay on another base. Patch replay, path switch, stale base, or post-validation mutation. Raw string authority, role mismatch, wrong path, command-text laundering, or sandbox escape.
These contracts separate value authority from effect authority. Before the gate treats a release, effect commitment, 18
E
Table 14: Model/runtime/settings matrix. Identifiers and settings are copied from recorded run configurations; “not sent” means deliberately omitted. Path and model identifiers
Recorded setup
Open-weight vLLM BF16: Qwen/Qwen3.6-27B; google/gemma-3-27b-it; Qwen/Qwen3-Coder-30BA3B-Instruct.
dtype=bfloat16; max_model_len=2048; max_new_tokens=64; temperature=0.0; gpu_memory_utilization=0.85; max_num_seqs=1. dtype=auto; quantization=gpt_oss_mxfp4; max_model_len=1024; max_new_tokens=64; gpu_memory_utilization=0.96. chat.completions; strict JSON schema response format; max_completion_tokens=2048; seed=0; temperature=1.0; top_p=1.0; reasoning_effort=medium; four retries; 120s timeout. messages; anthropic_version=2023-06-01; max_tokens=2048; forced tool choice; seed unsupported; temperature and top-p not sent; four retries; 120s timeout. chat.completions; strict JSON schema response format; max_completion_tokens=2048; seed not sent; temperature=0.0; top_p=1.0; four retries; 120s timeout.
GPT-OSS vLLM MXFP4: openai/ gpt-oss-120b.
OpenAI hosted: gpt-5.5.
Anthropic claude-opus-4-7; claude-sonnet-4-6.
Gemini 5-flash.
hosted:
hosted:
gemini-3.
Table 13: Mechanism coverage. Different failures need different boundary checks; no single partial mechanism covers all rows.
Supports
Does not support
Field-closed openweight
Reference target for protected-field decoding: fresh projection, field grammar, parent records, nonce, backend profile. Declared raw-W source, generated-prefix, or declared-atom exclusion before field admission. Field-local construction and evidence binding on the evaluated open-weight profile. Reader/extractor and field-local writer visibility when provider internals are unavailable. Sink-interpreted state deltas or commitments for effect-bearing payloads. One manifest-bound capability consume and execution lease.
All serving stacks or compromised-host attestation.
Direct-span suffix-taint runtime-map
/ /
Open-weight serving check Hosted/API compatibility Exact-effect adapters Ledger
Failure class
Boundary component needed
Shape-valid authority laundering Summary or memory laundering Wrong-field D reuse W-controlled retry/batch/schedule Opaque reentry Effect-bearing payload Evidence substitution or repair Stale policy or snapshot Unmediated alternate sink
Field-local gate over protected sink fields. Transitive influence provenance. Destination-scoped typed release. Invocation capability plus consume. Opaque data reenters later boundaries as W. Exact-effect authorization. Manifest-bound evidence record. Policy epoch and trusted snapshot digest. Complete mediation of side-effect paths.
The rows are independent failure paths. A schema can rule out malformed objects, but it does not say who chose a protected field. A call ledger can prevent duplicate invocation, but it does not authorize patch content or approval state. A typed release can carry one validated value, but it cannot be reused for another field. CXI closes these cases only when the field, effect, and invocation checks meet at the same manifest.
Table 15: Evidence boundary summary. Each path supports a specific part of the admission claim and leaves different non-claims outside the boundary. Path
Mechanism Coverage and Composition
F
Evaluation Setup and Model Settings
The setup records identify where sampled evidence was collected. They are not result categories. Deterministic rows use fixed checks and fault-injection cases; sampled rows use the model and serving configurations below. Hosted/API aliases are archived record identifiers and may not denote providerinternal model revisions. Open-weight sampled rows ran on NVIDIA H100 80GB HBM3 GPU hosts with driver 570.172.08, CUDA 12.8, PyTorch 2.11.0+cu128, and vLLM 0.21.1rc1.dev268 precompiled builds. GPT-OSS used native MXFP4. This specifies the machine and serving environment; it does not define a separate evidence claim.
Full hidden-state, KV-lineage, or model-level noninterference. Other optimized backend variants unless they satisfy the same gate check. Provider-internal masks, attention, KV-cache lineage, or enforcement. Validator completeness beyond the adapter contract. Automatic exactly-once external delivery without adapter idempotency.
G
Evidence Boundaries
Different evidence paths support different parts of the same admission predicate. The boundaries below say what each path contributes before the gate and what remains outside the claim. Common record invariants. All evidence verifiers bind the action digest, protected field path, policy epoch, trusted snapshot, backend or hosted/API profile, action nonce, adapter revision, and parent records. They reject field changes after evidence recording, evidence for a different field, stale policy or snapshot, lower evidence mode than policy requires, unsupported backend paths, hosted/API writers that see raw W
or capability as authority, the validator must bind destination scope, sink-parsed value, trusted snapshot, post-validation immutability, adapter coverage for the sink class, and the mediated entry point. A typed release can justify one field value, but it does not authorize the side effect of interpreting a patch, SQL statement, workflow, or command. The adapter checks close that second step under the trusted snapshot.
19
I
for protected fields, stale or wrong-manifest capability consume, exact-effect replay, stale base states, and path rewrites. Missing policy fields, broad validators, and unmediated sinks remain deployment risks outside CXI admission.
H
Policy audit. Policy authoring is part of the trusted boundary, not an automatically inferred property. The evaluated policy set records protected fields, typed-release destinations, opaque data slots, effect-bearing payloads, validator tests, and bypass checks for each mediated sink. The useful failure classes are practical: a field can be left unprotected, a typed release can be scoped too broadly, an opaque slot can reenter a downstream bot, an exact-effect adapter can miss a sink-parsed effect, or a helper API can bypass the shared gate. CXI exposes those cases as policy or mediation failures; it does not make the missing policy true. Residual risks. The residual risks have the same shape as the contract assumptions. A compromised host can lie about provenance or evidence records. A provider-internal hosted decoder cannot expose masks, attention, or KV-cache lineage to the reviewer. A validator can be too weak for a sink class, even when the gate enforces it consistently. A task can fail for parser, benchmark, or quality reasons after the admission decision is correct. These cases remain outside mediated admission integrity; the claim stays narrow: field, effect, and invocation authority must bind to the same canonical manifest before execution. Deployment checklist. For a new mediated sink, the minimum checklist is small but strict. The policy must classify every field that selects, authorizes, or parameterizes a side effect. Each typed release must name its source scope, destination field, validator, trusted snapshot, policy epoch, and action context. Each effect-bearing payload needs an adapter that validates the sink-parsed effect, not just the JSON shape or byte string. Each invocation capability must name the same manifest digest that the field and effect evidence name, and the ledger must consume it before execution. Alternate clients, helper APIs, retry paths, batching, delegation, package hooks, and generated files must reach the same gate or stay outside the claim. If a deployment cannot answer one of these checks, the correct outcome is not a weaker claim about CXI; it is an unmediated or under-specified sink.
Result-Row Backing
The result records keep denominators separate. Episodes, field records, leases, consume attempts, archived hosted/API rows, and proposal rows are different units, so the paper never averages them into one success rate. A row supports the admission claim only when the recorded action reaches the mediated sink with field, effect, and invocation authority checked against the same manifest. Table 16: Evidence behind the main result rows. The table names the checked records behind each denominator without replaying individual traces. Main item
Records checked
What the row establishes
AgentDojo live task bank
Episodes, LLM calls, STC rows, protected-admission outcomes. Field records, leases, effect authorizations, gate decisions.
720 episodes, 1,739 calls, and 199 STC define the evaluated live task surface. 306 field records and 204 leases/effects support the exact-effect admission subset. 400 episodes, 231 STC, and the 73/61/35 non-STC split separate parsing, authorization, and task quality. 10 cases, 29 consumes, 19 rejects, and 2 dedup retries support manifest-bound consume/dedup. 800 rows, 85 unsafe selections blocked, and 0 gate escapes support hosted/API compatibility. Figure 3 measures pre-gate unsafe proposal pressure separately from execution.
AgentDojo exacteffect admissions Code-agent effect
exact-
Repository episodes, manifests, exact effects, leases, task oracle outcomes.
Ledger faults
Consume attempts, rejects, dedup retries, admitted leases.
Hosted/API compatibility
Archived action rows, field-local construction records, and gate decisions. Adversarial proposal rows and executed-escape counters.
Proposal pressure
Residual Risks and Deployment Checklist
20