Patterns/Security Patterns

Architecturally Limiting Blast Radius

Why limiting what a compromised model can do matters more than preventing compromise

The Conventional Framing

Privilege separation limits what each component can do. Applied to LLMs, it means the model only has access to capabilities it needs for the current task, reducing damage from successful attacks.

The pattern follows the principle of least privilege from traditional security.

Why Privilege Separation Is Necessary but Hard

Privilege separation is the right architectural approach, but implementing it for LLMs is challenging. Many LLM use cases require broad capabilities— that's why you're using an LLM instead of deterministic code.

The tension: more capabilities make the LLM more useful but also increase blast radius. The "minimum necessary privilege" may still be substantial.

The implementation challenge:

Traditional privilege separation uses OS-level controls, separate processes, distinct credentials. LLM capabilities are often all in one process, one API call. Retrofitting privilege separation requires architectural changes.

Architecture

Components:

  • Capability router— directs requests to appropriate privilege level
  • Separate privilege contexts— distinct capability sets for different tasks
  • Approval workflows— human approval for sensitive operations
  • Credential separation— different credentials for different privilege levels

Trust Boundaries

Without privilege separation: Model can: read all data, write all data, delete data, send emails, call external APIs, modify configs With privilege separation: Chat model can: read FAQ, generate responses Action model can: update user preferences (with approval) Admin model can: nothing without human in loop Compromise of chat model → limited damage.
  1. User → Router — requests classified by required privilege
  2. Router → Models — each model has specific capabilities
  3. Models → Resources — access limited to granted permissions

Threat Surface

ThreatVectorImpact
Privilege escalationTrick router into granting higher privilegesAccess capabilities beyond intended level
Capability creepGradually expand what 'minimum privilege' meansUseful features increase attack surface
Cross-context contaminationUse shared state between privilege contextsLow-privilege context influences high-privilege one
Credential exposureModel leaks credentials for higher privilege contextsAttacker gains direct access bypassing controls

The ZIVIS Position

  • •
    Assume compromise, limit damage.You can't perfectly prevent injection. You can limit what a compromised model can do. Focus on blast radius.
  • •
    Separate by capability, not just role.Don't just separate 'admin' from 'user'. Separate 'read' from 'write' from 'delete'. Granular privileges.
  • •
    Different credentials for different contexts.If the read-only model and the write model share credentials, separation is theater.
  • •
    Human approval for high-impact actions.Some actions should require human approval regardless of what the model requests. Break the automation chain for sensitive operations.

What We Tell Clients

Privilege separation is the most important architectural pattern for LLM security. Accept that injection will sometimes succeed; limit what success means for the attacker.

Give each model context only the capabilities it needs. Use separate credentials. Require human approval for sensitive operations. The goal is making compromise boring, not impossible.

Related Patterns