Context Lock

The Problem: Blind Execution

LLM-based systems process natural language instructions to perform tasks, make decisions, and execute actions. The context window - the text provided to the model - determines its behavior entirely. This creates a critical vulnerability: the model has no way to verify that the instructions it is reading are the instructions that were intended to be executed.

1.1 The Trust Gap

In traditional software systems, code integrity can be verified through signatures, checksums, or trusted execution environments. These mechanisms rely on external infrastructure: certificate authorities, key management systems, secure hardware, or network-accessible validation services.

LLM prompts and instructions exist as plaintext. They can be modified in transit, corrupted at rest, or manipulated through injection attacks. The model itself has no mechanism to detect these modifications - it simply processes whatever text appears in its context.

1.2 Attack Vectors

The absence of instruction integrity verification enables multiple attack vectors:

• Prompt Injection: Malicious instructions inserted into user input that override or modify system behavior.
• Context Poisoning: Modification of the instruction set before it reaches the model, either in transit or at rest.
• Man-in-the-Middle Tampering: Interception and modification of prompts between the issuing system and the executing model.
• Supply Chain Attacks: Compromised plugins, agents, or prompt libraries that contain modified instructions.

1.3 The Infrastructure Problem

Existing solutions to instruction integrity require external dependencies: PKI systems for signatures, blockchain for immutable records, trusted hardware for secure execution, or network connectivity for validation services. These dependencies create their own attack surfaces and are often unavailable in the environments where integrity matters most - air-gapped systems, contested networks, or zero-trust architectures.

Context Lock: Architecture

Context Lock is a text-native integrity mechanism that enables an LLM to verify the authenticity of its own instructions before execution. The mechanism operates entirely within the context window, requiring no external infrastructure.

2.1 Core Mechanism: Mutual File Dependency

Context Lock uses a three-file architecture where each file contains cryptographic or semantic references to the other two files. This creates a validation chain that breaks if any single file is modified, removed, or injected.

The three components:

• 1. Primary Instruction File Contains the executable instructions, encoded or obfuscated, with embedded references to the manifest and sentinel files.
• 2. Validation Manifest Contains hashes, semantic fingerprints, or structural signatures of the primary instruction file and sentinel file.
• 3. Sentinel File Contains validation logic and cross-references that verify the integrity of the other two files.

2.2 Validation Protocol

Before executing any instruction from the locked context, the model performs a validation check:

1. Verify that all three files are present in the context.
2. Check that the manifest's references match the current state of the primary and sentinel files.
3. Verify that the sentinel's cross-references match the manifest and primary files.
4. If all checks pass, proceed with execution. If any check fails, halt and report tampering detected.

2.3 Encoding Layer

The primary instruction file can optionally be encoded or obfuscated. This serves two purposes: it prevents casual inspection of the instruction content, and it makes surgical modification impractical. An attacker cannot simply find and change "15% discount" to "90% discount" if they cannot locate that string in the encoded payload.

Properties

3.1 Self-Contained Verification

Context Lock operates entirely within the context window. The text validates the text. No external calls, no hardware dependencies, no infrastructure requirements. This property is unique and critical for deployment in air-gapped, contested, or zero-trust environments.

3.2 Tamper Evidence

Any modification to any of the three files causes validation failure. The mechanism does not prevent tampering - it detects it. This distinction is important: Context Lock is a tamper-evident seal, not a tamper-proof container.

3.3 Intent Preservation

The core value proposition is intent preservation: ensuring that the instructions executed by the model are the instructions that were intended by the author. The model can verify, at execution time, that its context has not been modified since the lock was created.

3.4 Infrastructure Independence

Unlike signature-based systems (which require PKI), blockchain-based systems (which require network access), or hardware-based systems (which require secure enclaves), Context Lock requires only the context window itself. The prompt carries its own proof of integrity.

Applications

4.1 Autonomous Agents

Long-running autonomous agents operate across sessions and environments. Context Lock provides a mechanism for the agent to verify its own instruction integrity at each decision point, detecting context poisoning or instruction drift.

4.2 Agent Supply Chains

As agent ecosystems mature, agents invoke other agents, use third-party plugins, and delegate to untrusted contexts. Context Lock provides verification at the boundaries - ensuring that a plugin or sub-agent is executing its intended instructions, not a modified version.

4.3 Regulated Industries

Financial services, healthcare, and other regulated industries require audit trails demonstrating that AI systems operated according to approved instructions. Context Lock creates verifiable evidence that prompts were intact at execution time, supporting compliance requirements.

4.4 Defense and Critical Infrastructure

Military and critical infrastructure applications often operate in contested or air-gapped environments where external validation infrastructure is unavailable or compromised. Context Lock's self-contained verification is uniquely suited to these deployments.

4.5 Franchise and White-Label AI

Organizations licensing AI workflows to franchisees or partners need assurance that deployed systems match approved configurations. Context Lock verifies instruction integrity without requiring central hosting or continuous network connectivity.

Threat Model and Limitations

Context Lock is a security layer, not a complete solution. Understanding its limitations is essential for appropriate deployment.

5.1 What Context Lock Addresses

• Opportunistic tampering by actors unaware of the lock mechanism
• Man-in-the-middle modifications during transit
• Prompt injection attacks that modify instruction content
• Supply chain attacks through compromised plugins or prompt libraries

5.2 What Context Lock Does Not Address

• Authorized Bad Actors: If the person creating the lock is malicious, the lock validates malicious instructions. Context Lock verifies integrity, not authorization.
• Lock Generation Compromise: If an attacker controls the lock creation process, they can create valid locks for malicious payloads.
• Model Non-Compliance: The model must choose to follow the validation protocol. A sufficiently manipulated context could instruct the model to skip validation.
• Sophisticated Forgery: An attacker with full knowledge of the lock mechanism and sufficient time could potentially forge a coherent set of three files.

5.3 Defense in Depth

Context Lock should be deployed as one layer in a defense-in-depth strategy, not as a sole security measure. It complements access controls, input validation, output monitoring, and other security mechanisms.

Comparison with Existing Approaches

Demonstration Scenario

The following scenario illustrates Context Lock's operation in a business application context.

Conclusion

Context Lock addresses a fundamental gap in LLM security: the inability of models to verify the integrity of their own instructions. By introducing a text-native, self-validating mechanism that operates entirely within the context window, Context Lock enables execution integrity verification without external infrastructure dependencies.

The mechanism is not a silver bullet. It is one layer in a defense-in-depth strategy, addressing specific attack vectors while remaining vulnerable to others. Its value lies precisely in its unique properties: infrastructure independence, air-gap compatibility, and runtime self-verification.

As AI systems become more autonomous and operate in more adversarial environments, the ability to verify instruction integrity at execution time will become increasingly critical. Context Lock provides a foundational primitive for this capability.

Contact

Email: delaney@zero2one.ee
Web: https://zero2one.ee