Patterns/Security Patterns

Separate Contexts for Separate Trust Levels

Why processing untrusted content in isolated contexts limits contamination

The Conventional Framing

Context isolation processes content from different trust levels in separate model contexts. Untrusted content doesn't share context with sensitive instructions or data.

The pattern applies the security principle of isolation to LLM architectures.

Why Isolation Has Integration Challenges

Context isolation works well when you can cleanly separate concerns. But many LLM applications need to combine untrusted input with trusted context—that's the use case.

If the model needs to answer questions about a user-provided document, it needs to see both the document (untrusted) and instructions (trusted) in the same context. Isolation trades capability for security.

The integration boundary:

Eventually isolated contexts must connect—outputs flow between them, summaries are combined. Each integration point is a potential contamination point.

Architecture

Components:

  • Context boundaries— separate model calls for different trust levels
  • Data sanitization— clean data before crossing boundaries
  • Integration points— where contexts must connect
  • Output filtering— validate what crosses boundaries

Trust Boundaries

Context 1 (untrusted): Input: User-provided document Task: Extract key facts Output: "The document discusses X, Y, Z..." Context 2 (trusted): Input: Extracted facts from Context 1 Task: Generate report with sensitive formatting Risk: Did Context 1's output carry injection? Isolation helps, but output flows between contexts.
  1. Untrusted → Context 1 — process untrusted in isolation
  2. Context 1 → Integration — output crosses boundary
  3. Integration → Context 2 — sanitized content enters trusted context

Threat Surface

ThreatVectorImpact
Cross-context contaminationInjection survives sanitization into trusted contextTrusted context processing compromised content
Output channel attacksEmbed injection in output format that bypasses filtersStructured output carries hidden instructions
Integration point exploitationTarget the specific mechanism that combines contextsAttack the handoff rather than either context
Isolation bypassConvince model to access other contextsModel crosses boundaries it shouldn't

The ZIVIS Position

  • •
    Isolation is architectural defense.Separate contexts genuinely limit contamination scope. This is one of the more robust patterns.
  • •
    Integration points need scrutiny.Where contexts connect is where isolation breaks down. Sanitize and validate at every boundary crossing.
  • •
    Accept capability tradeoffs.True isolation means some things can't be done together. That's the price of security.
  • •
    Consider what crosses boundaries.Small, structured data crossing boundaries is safer than rich text. Minimize what flows between contexts.

What We Tell Clients

Context isolation is one of the most effective architectural defenses. Processing untrusted content separately genuinely limits contamination.

But integration points are critical—if outputs from untrusted contexts flow into trusted contexts, you need robust sanitization at those boundaries. Design for minimal, structured data crossing between contexts.

Related Patterns