PaperlayerView exact revision on arXiv

Source-linked AI summary

CONTINUITY: Security-Context Contracts for Composable LLM Agent Controls

Chris Zheng, Geng Yang

arXiv:2609.05269v1cs.CRcs.AI

TL;DR

LLM security controls can fail to compose when security context is altered across component boundaries. CONTINUITY uses contracts and authenticated transition evidence to preserve that context, and in its deterministic evaluation it prevented harmful effects across all modeled attack classes while completing benign tasks and escalating ambiguous ones.

  • Problem

    Locally correct provenance, authorization, policy, and execution controls may still fail end-to-end when neighboring components drop, widen, rebind, or reinterpret security context.

  • Method

    CONTINUITY models components with contracts and carries authenticated context through signed grants, provenance commitments, transition receipts, typed releases, transformation witnesses, and effect-bound permits.

  • Results

    CONTINUITY committed no harmful effect across 2,560 attack instances spanning 128 fault-domain classes, completed all 700 benign tasks, and escalated all 200 ambiguous tasks.

  • Takeaways & Limitations

    The evaluation supports explicit cross-component contracts as a way to preserve security guarantees across the instruction-to-effect path.

  • Takeaways & Limitations

    The prototype does not provision or choose trusted roots, and malicious or compromised trusted validators, verifiers, or mandatory sinks can invalidate corresponding guarantees.

Abstract

from arXiv · show

LLM agent systems increasingly combine provenance tracking, authorization, policy enforcement, protocol adapters, and execution controls. However, individually correct security mechanisms do not necessarily compose into an end-to-end secure system: security-critical context may be dropped, widened, rebound, or reinterpreted as actions cross component boundaries. We identify this failure mode as security-context discontinuity and introduce CONTINUITY, a framework for verifiable composition of agent security controls. CONTINUITY models each component with an assume-guarantee contract and carries authenticated security context across transitions using signed root grants, provenance commitments, role-bound transition receipts, bounded typed releases, transformation witnesses, and effect-bound execution permits. We formalize end-to-end consequence integrity, requiring every realized external effect to be backed by a valid and current authorization witness linking the principal, task, provenance, delegation, policy state, canonical action, and finality boundary. We implement a reference verifier and deterministic cross-layer fault-injection suite covering 32 fault classes across four application domains. In 2,560 parameterized attack instances spanning 128 fault-domain classes, the full CONTINUITY configuration commits no harmful external effect, while completing all 700 benign tasks and escalating all 200 ambiguous cases. These results show that secure agent execution requires not only sound individual controls, but explicit contracts that preserve their guarantees across the complete instruction-to-effect path.

1 Introduction

LLM agent controls can be locally sound yet fail compositionally when security context is lost, weakened, reinterpreted, or rebound across component boundaries. CONTINUITY addresses this gap with contracts and authenticated transition evidence linking proposals to mediated effects.

  • Problem: Security-context discontinuity occurs when a security-relevant fact is lost, weakened, reinterpreted, modified without authorization, or stale before the effect.Signatures alone authenticate emitters but do not establish stage authorization or preservation of upstream security contracts.
  • Problem: The central question is which explicit conditions let independently useful agent-security controls compose into an end-to-end consequence boundary.
  • Execution boundary: The framework separates proposal, admission, and effect, treating the planner as adversarial and making deterministic controls—not model prose—the authority for execution.Its primary security objective is preventing harmful external commitment, not preventing the planner from proposing an action.
  • Formal model: CONTINUITY models controls with assume–guarantee contracts whose upstream guarantees discharge downstream assumptions and whose changed security fields require checked relation witnesses.Contracts preserve fields and justify authorized transformations across heterogeneous stages.
  • Security principles: The design combines complete mediation, least authority, canonical binding, and freshness restrictions so these principles remain meaningful after multiple controls transform a request.The distinctive focus is what security context must be carried and checked across independently implemented transformations.

3 System and Threat Model

CONTINUITY treats the planner as outside the trusted computing base and carries a signed envelope through authorized components, verification, permit issuance, and finality. Its threat model covers malicious inputs and faulty non-root components while explicitly assuming protected verifier and sink infrastructure.

  • System path: A task begins with a signed ingress envelope, traverses components that emit envelopes and transition receipts, and ends with a verifier-issued permit consumed by a finality sink.The sink commits the effect and produces an outcome receipt.
  • Threat model: The planner may propose arbitrary actions and explanations, but its natural-language output is data until deterministic verification and sink controls admit it.The planner is not part of the trusted computing base.
  • Adversary: The adversary controls external content and may exploit faulty non-root components, reorder or truncate chain elements, and substitute signed values.The model does not assume correct planner behavior.
  • Trusted configuration: The trusted deployment configuration fixes issuers, stage identities, manifests, predicates, canonicalization, validators, revocation state, nonce handling, sinks, and key provisioning.
  • Effect model: Complete mediation must cover effect classes rather than individual tool names because syntactically different actions can produce equivalent external effects.Email, HTTP, browser, shell, and remote-agent interfaces may all exfiltrate the same data.
  • Security objective: The objective is structural consequence integrity: harmful proposals must not become externally committed effects without a complete, current authorization witness.The scope excludes semantic correctness, arbitrary covert channels, denial of service, compromised operating systems, and population-level attack probabilities.

4 Security-Context Discontinuity

Security-context discontinuity occurs when security-relevant facts are dropped, weakened, rebound, reinterpreted, or made stale across representations, even when objects are signed. CONTINUITY addresses this with authenticated origins, field-level continuity, checked transformations, and end-to-end witnesses.

  • A discontinuity exists when a fact needed to justify an effect is absent, weakened, reinterpreted, unauthorizedly modified, or stale.
  • Signatures alone are insufficient because they do not establish role authorization, predecessor relationships, or equality between approved and executed actions.
  • Minimal counterexample: The alias-resolution counterexample shows that an action-bound permit can faithfully authorize a malicious output without proving the input-to-output relation.
  • Minimal counterexample: A transformation witness binds both value digests, the path, task, component, contract, trusted issuer, and expiry; the verifier independently checks the declared relation.
  • Safe composition requires endpoint authenticity, checked transition relations, role authorization, semantic predicates, and assume–guarantee compatibility.
  • Theorem 1 states that, under signature unforgeability and digest collision resistance, satisfying C1–C7 ensures every protected effect has a valid witness, even against an adversarial planner.
  • Context truncation can make distinct security states observationally identical, forcing downstream components either to fail closed or risk accepting an invalid state.
  • Authority non-laundering prevents ordinary derivation, summarization, memory consolidation, or translation from creating execution authority absent from authenticated roots and grants.

6 Design

The design authenticates chain origin, constrains untrusted data through typed releases, validates role-bound transitions and transformations, and rechecks permits at finality. Complete mediation is required because correctly protected paths cannot secure effects reachable through an alternate path.

  • Authenticated chain origin: The first envelope and root grant use separate trusted roles, preventing self-signed origins and authority declarations that exceed the authenticated grant.
  • Provenance and releases: Provenance claims bind each path to a source identity and value digest, so a source claim accompanying a different amount fails verification.
  • Provenance and releases: Typed releases authorize one validated source value to influence one target path under a bounded predicate, task, operation, and tool context.
  • Provenance and releases: A release bound to H(v) cannot be replayed for v′, and expired or revoked credentials are rejected.
  • Component contracts: Each transition receipt commits to input and output envelopes, contracts, changed paths, assumptions, guarantees, and transformation witnesses, with deployment fixing the expected signer and stage.
  • Component contracts: Transformation witnesses permit legitimate alias, unit, schema, or routing changes only when an independently trusted relation validates the changed field.
  • Permits and finality: The finality sink rechecks caller, audience, action digest, policy, revocation, expiry, nonce, and idempotency immediately before committing an effect.
  • Complete mediation: Disabling mediation permits an effect through a direct alternate path despite correct receipts and permits on the normal path.

7 Reference Implementation

The reference implementation provides deterministic, fail-closed verification for authenticated security context, typed releases, transformations, and finality. It combines runtime checks with static contract-flow linting and reproducible artifact support.

  • Artifact: The Python 3.11+ artifact contains a 1,523-line security core and 1,697 lines for scenarios, fault injection, configurations, aggregation, and timing.It also includes 30 regression tests and publication scripts, without invoking an LLM.
  • Cryptography and serialization: Deterministic JSON serialization uses sorted keys, integer-only benchmark numerics, normalized sets, SHA-256 digests, and Ed25519 signatures.The encoder is sufficient for internal reproducibility but is not claimed to implement RFC 8785 completely.
  • Verification: The verifier resolves security fields at RFC 6901-style leaf paths and fails closed when paths are missing.The same resolver supports provenance claims, root constraints, release targets, transform rules, and change-set recomputation.
  • Verification: The verifier accumulates reason codes and rejects duplicate identifiers, chain mismatches, sequence gaps, false change sets, and invalid transformation witnesses.This supports auditability and targeted regression tests.
  • Finality: The sink independently verifies one-shot permits, caller subjects, runtime state, consumed nonces, and outcome receipts before recording effects.Idempotent retries return the existing signed outcome without applying the action again.
  • Pipeline: Three role-bound stages preserve authenticated context, enforce deterministic policy postconditions, and authorize canonical destination transformations with an alias-resolution witness.Independent monotonicity checks and a pre-runtime linter add redundant defense, while runtime verification remains authoritative.

8 Evaluation

The evaluation tests 32 modeled fault classes across four domains using deterministic parameterized scenarios and compares complete with incomplete control compositions. The full system contains all modeled attacks while retaining benign completion and escalating unreleased cases, whereas incomplete configurations leave substantial attack success.

  • Methodology: 32 fault classes across four domains with 20 parameterized instances per fault–domain pair produce 2,560 attack instances spanning 128 fault–domain classes.The generated suite also includes 700 benign tasks and 200 ambiguous tasks, for 3,460 scenarios overall.
  • Methodology: The evaluation treats attack candidates as directly instantiated after planner compromise rather than crediting an LLM for refusing payloads.Reported rates are exact conformance counts over generated scenarios, not population-level security estimates.
  • Main results: Continuity commits no harmful effect in 2,560 attack instances, contains all 128 fault–domain classes, completes all 700 benign tasks, and escalates all 200 ambiguous tasks.Lifecycle correctness is 100%, including replay and retry semantics.
  • Main results: 65.6% effect ASR remains for Gateway+Finality, while EffectBoundPermit reaches 81.3% because each incomplete configuration omits cross-layer justification or upstream security context.These results support the composition claim that final-action binding alone is insufficient.
  • Utility and escalation: All 300 signed typed-release tasks complete, whereas all 200 otherwise plausible tasks without a release escalate and commit no effect.Out-of-bound values, substitutions, and expired credentials are rejected.
  • Ablations: Field-provenance removal, contract-conformance removal, and incomplete mediation each reopen 24 fault–domain classes in targeted ablations.Root authentication reopens 16 classes, release validation 12, and transform validation and replay protection eight each; authority monotonicity alone reopens none in this benchmark.
  • Performance: Verification scales approximately linearly with signed transitions, while recorded bundle sizes grow from approximately 8.1 KiB at one transition to 49.4 KiB at 20 transitions.Timing excludes network, model, external-policy-service, and durable-storage latency.
  • Limitations: The evaluation supports conformance to modeled obligations but does not establish universal attack rates, fault-taxonomy completeness, trusted-validator correctness, or resistance to a compromised trusted computing base.The fault classes are designed to exercise distinct proof obligations and common boundary failures, not claimed to be exhaustive.

9 Security Analysis

The security analysis maps formal composition conditions to concrete verifier checks, then examines assumptions and residual attack surfaces. It shows where guarantees depend on trusted issuers, validated transformations, complete mediation, and provider semantics.

  • Enforced conditions: The artifact enforces theorem conditions through trusted roots, role bindings, field continuity, bounded releases, exact effect binding, and finality checks.The implementation maps C1–C7 to concrete checks, including root constraints, transition predicates, signed relation witnesses, action digests, and permit-required effect brokerage.
  • Security assumptions: Monotonicity fails when an accepted root or trusted validator is compromised, and stage-key compromise remains limited by configured role boundaries.A compromised root can issue an over-broad grant; a compromised stage key cannot start a chain or impersonate another stage, although permissive predicates remain exploitable.
  • Enforced conditions: A valid signature is insufficient unless the signer is authorized for the role and the transition satisfies its contract.The verifier separately checks signature validity, role authorization, and transition validity before accepting an object.
  • Enforced conditions: Release credentials require exact value, source, manifest, principal, task, operation, and tool binding to prevent replay or misattribution.Predicate satisfaction alone does not bind a credential to the specific value or workflow context.
  • Security assumptions: Trusted-release issuance and transformation validation remain security-critical because CONTINUITY does not prove semantic correctness of validator outputs.Relation witnesses must bind before and after values, while production deployments need relation-specific validators and versioned semantics.
  • Residual boundaries: The sink rechecks policy, revocation, caller, expiry, nonce, and idempotency state at finality, but real providers require provider-specific concurrency and failure handling.The prototype assumes in-memory atomicity, while distributed providers may have retries, partial failures, and non-idempotent effects.
  • Residual boundaries: Unmediated paths can bypass protection, and adversarial planners can still cause denial of service, unsafe unprotected output, or covert leakage.Complete mediation must cover aliases, direct SDK calls, browser automation, shell commands, remote agents, and recovery paths.

10 Discussion

The discussion frames CONTINUITY as an interoperability layer for preserving authenticated security facts across heterogeneous controls. It also identifies escalation, versioning, evidence retention, and broader information-flow mechanisms as practical complements.

  • Interoperability: A cross-control contract must standardize principals, task and delegation scope, field-level provenance, canonical effects, typed releases, transformation witnesses, and freshness state.The proposed contract extends beyond a universal ALLOW/DENY hook by defining stable semantics for the security context carried across stages.
  • Interoperability: MCP and runtime-hook standards can transport these objects, but implementations must align canonicalization and field paths between producers and verifiers.The proposed integration point is an extension or sidecar envelope associated with tool calls and agent handoffs.
  • Operational handling: The system distinguishes Escalate from Deny when missing proof may reflect insufficient validation rather than a forbidden task.Escalation can request signed validation, narrower confirmation, reauthentication, or human approval tied to the exact action digest.
  • Deployment: Deployment trust may use enterprise PKI or workload identity, while cross-organization use requires shared issuer discovery, revocation, and evidence anchoring.A ledger is optional; the stated safety property comes from authenticated contracts and finality enforcement.
  • Deployment: Contracts, predicates, and relation semantics are versioned security code, so updates require review, compatibility testing, and policy-epoch changes.Long-lived workflows need explicit migration or reauthorization rather than silent compatibility.
  • Auditability: A complete witness answers which root, source, release, component, relation, policy epoch, and sink authorized and committed an effect.Evidence can be retained off-chain with privacy controls while hashes or batch roots are externally anchored.
  • Scope: CONTINUITY complements broader control/data-flow and provenance systems by checking whether their authenticated outputs survive to finality.It focuses on structured effect fields and explicit transitions rather than providing full language-level information-flow control.

11 Related Work

Related work provides defenses for prompt injection, control/data isolation, policy enforcement, provenance, protocols, and compositional assurance. CONTINUITY’s stated distinction is an end-to-end composition property across heterogeneous controls.

  • Prompt-injection evaluation: Prompt-injection benchmarks test whether attacker-controlled observations redirect agent behavior, whereas CONTINUITY tests downstream discontinuities from adversarial proposals.The paper treats these evaluation styles as complementary rather than interchangeable.
  • Control and privilege: Prior systems isolate control from data, constrain capabilities, isolate components, or provide programmable tool privileges; CONTINUITY focuses on the interface theorem between such controls.Its question is which authenticated fields must survive across component boundaries.
  • Policy enforcement: Policy languages and runtime hooks enforce decisions, while CONTINUITY models a policy decision as one stage guarantee whose supporting facts later components must preserve.The framework does not replace policy languages or hook APIs.
  • Provenance and execution integrity: Provenance and execution-integrity systems motivate field authority, typed releases, causal support, and exact effects; CONTINUITY composes these across heterogeneous controls.Its distinct contribution is composition from trusted roots through role-bound transitions to finality.
  • Protocols and authorization: Protocol standards address tool invocation, authorization, audience, least privilege, freshness, and replay resistance, while CONTINUITY binds these concepts to a concrete task and action witness.Transport and user authentication remain delegated to existing protocols.
  • Compositional assurance: Assume–guarantee and supply-chain frameworks provide precedents for compositional specifications and authorized transformations, which CONTINUITY applies to agent execution.Each security-sensitive transformation must be attributable to an authorized role and satisfy an explicit relation before final effect.

12 Limitations

The limitations constrain CONTINUITY’s trust assumptions, implementation status, benchmark interpretation, provider realism, semantic coverage, and integration scope. The framework preserves authenticated authorization context but does not establish semantic correctness or universal information-flow security.

  • Trust assumptions: Trusted roots and validators are deployment inputs, so compromise or malicious configuration of these authorities can invalidate their corresponding guarantees.The prototype enforces trust relationships but does not provision roots or decide which organizations should be trusted.
  • Runtime scope: The runtime must ensure that the authenticated context manifest covers all planner-visible bytes and tool outputs, an assumption the prototype does not prove.Silently exposing additional attacker-controlled content violates this context-capture assumption.
  • Transformation scope: The implementation supports alias resolution and a small deterministic predicate registry, while richer transformation semantics introduce soundness, decidability, and review challenges.Production deployments need versioned semantics for currency conversion, schema mapping, identifier resolution, aggregation, and declassification.
  • Implementation status: The Python artifact is regression-tested but not mechanically verified or formally shown to refine the model, and its restricted JSON encoder is unsuitable as an interoperability standard.Interoperable deployments should replace it with a standards-conformant canonicalizer.
  • Evaluation scope: The synthetic benchmark contains 32 designed fault templates across four domains and is not an exhaustive attack population or an estimate of universal failure probability.It validates specified invariants and artifact behavior without measuring model quality because no LLM is invoked.
  • Provider scope: The prototype assumes in-memory atomic finality, whereas real providers require handling concurrency, retries, eventual consistency, non-idempotent effects, and partial failures.Production use therefore needs provider-specific transaction protocols and durable evidence.
  • Information-flow scope: The system covers declared protected fields and effects but does not eliminate covert channels, unknown equivalent effect paths, or leakage through allowed outputs and downstream behavior.Complete mediation remains an engineering and governance obligation.
  • Semantic scope: CONTINUITY preserves authorization context but does not guarantee that authorized goals, trusted facts, releases, or transformations are semantically correct.Semantic correctness of trusted validators remains part of the trusted computing base.

13 Conclusion

Security-context discontinuity occurs when locally correct controls fail to preserve security assumptions across component boundaries. CONTINUITY addresses this with contracts and checks that maintain authorization context from instruction to external effect.

  • Security controls can fail end-to-end when neighboring components drop assumptions, alter actions, accept unauthorized signers, or act under stale state.
  • CONTINUITY authenticates roots, binds stages to authorized identities and contracts, validates provenance and releases, witnesses transformations, and revalidates state at finality.
  • A deterministic proof-carrying control plane can mediate external consequences even when planning remains probabilistic and adversarial.

A Proofs

The proofs establish that authenticated roots, transition contracts, field continuity, transformation witnesses, and finality checks preserve consequence integrity across the pipeline. They also show why omitted security fields or bypassed sinks permit unauthorized effects.

  • Root and transition proofs: Root boundedness ensures accepted initial context is authorized by a trusted issuer and constrained for identity, task, policy, provenance, authority, delegation, tools, effects, and validity.
  • Root and transition proofs: Transition preservation requires every security-critical change to be a monotone reduction or an independently witnessed, contract-declared transformation.
  • Continuity proof: Inductive context continuity connects every downstream security field to an authorized root through preserved values, restrictions, or valid transformation relations.
  • Finality proof: Finality binding requires the actual caller, action, audience, policy, grant, expiry, nonce, and idempotency state to match the permit immediately before commitment.
  • Impossibility and bypass results: If a security-relevant field is omitted from checked commitments or a path bypasses a compatible finality sink, an adversary can present or commit an unauthorized effect.

B.1 Root grant

The artifact encodes bounded root grants, typed releases, transformation witnesses, and effect-bound permits as signed structured records. The deterministic suite checks these controls across faults, lifecycle behavior, and benign or ambiguous tasks.

  • Root grant: A root grant binds the principal, actor, task, authority, delegation scope, permitted tools and servers, field constraints, policy epoch, provenance roots, context roots, and expiry.
  • Release and transformation records: A typed release binds an external source and value digest to a target field, predicate, task, action, tool, and expiry.
  • Release and transformation records: An alias-resolution witness records the relation, field path, before and after digests, component signer, contract, and resolved destination.
  • Effect permit: The finality permit binds the principal, subject, task, grant, audience, action and bundle digests, policy state, nonce, idempotency key, one-time status, and expiry.
  • Evaluation boundary: Timing columns are not invariant because latency depends on the host, Python version, and cryptographic-library versions.
  • Deterministic evaluation: 2,560 attack instances across 128 fault-domain classes are expected to yield zero harmful effects, benign auto-completion of 1, ambiguous escalation of 1, and lifecycle correctness of 1.
Loading 2609.05269v1…