5K

Tool Capability Compartmentalization

Splits tools into reader, processor, and writer classes with scoped permissions and blocks tool chains that combine private data, untrusted input, and external writes

emerging Updated 2026-10-13 By Nikola Balic (@nibzard) Based on Simon Willison (MCP critique)
View .md Edit on GitHub
Add to Pack
or

Saved locally in this browser for now.

Cite This Pattern
APA 
Nikola Balic (@nibzard) (2026). Tool Capability Compartmentalization. In *Awesome Agentic Patterns*. Retrieved October 14, 2026, from https://agentic-patterns.com/patterns/tool-capability-compartmentalization
BibTeX 
@misc{agentic_patterns_tool-capability-compartmentalization,
  title = {Tool Capability Compartmentalization},
  author = {Nikola Balic (@nibzard)},
  year = {2026},
  howpublished = {\url{https://agentic-patterns.com/patterns/tool-capability-compartmentalization}},
  note = {Awesome Agentic Patterns}
}

Use when

  • Agent tools read private data and also reach the network
  • Untrusted input can reach tools that write or send data
  • MCP or framework tools mix several capability classes

Avoid when

  • All tools are read-only and local
  • Team cannot maintain per-tool permission manifests

Problem

Model Context Protocol (MCP) and agent frameworks often combine three capability classes in a single tool: private-data readers (email, filesystem), web fetchers (HTTP clients), and writers (API mutators). This creates the "lethal trifecta"—malicious input can trigger chains that read sensitive data, exfiltrate it, and modify systems in one operation.

Solution

Adopt capability compartmentalization at the tool layer:

  • Split monolithic tools into reader, processor, and writer micro-tools.
  • Require explicit, per-call user consent when composing tools across capability classes.
  • Run each class in an isolated subprocess with scoped API keys and file permissions.

Treat each capability class as a separate trust zone with its own runtime identity and policy checks. Cross-zone composition should require explicit policy evaluation and short-lived delegation tokens so the agent cannot silently chain read+fetch+write into a high-risk path.

Scope note: Willison's post diagnoses the trifecta and prescribes keeping at least one of the three capabilities out of any execution path; it does not propose reader/processor/writer splitting or manifests. The micro-tool splitting below is this pattern's extrapolation of his principle. The call-time blocking rule itself belongs to the sibling pattern Lethal Trifecta Threat Model; what this pattern adds is the per-class isolation and manifest machinery that makes such a rule enforceable.

# tool-manifest.yml
email_reader:
  capabilities: [private_data, untrusted_input]
  permissions:
    fs: read-only:/mail
    net: none

issue_creator:
  capabilities: [external_comm]
  permissions:
    net: allowlist:github.com

How to use it

  • Generate the manifest automatically from CI.
  • Your agent runner consults the manifest before constructing action plans.
  • Flag any attempt to chain tools that would recreate the lethal trifecta.
  • Group tools by capability class (fs, web, runtime, memory) and assign profiles (minimal, coding, messaging) to prevent mixing.
  • Validate tool chains at call time: reject if all three capability classes are present.
// Cross-zone validation
function validateToolChain(tools: string[]): boolean {
  const classes = new Set(tools.map(t => getCapabilityClass(t)));
  if (classes.has("PRIVATE_DATA") &&
      classes.has("UNTRUSTED_INPUT") &&
      classes.has("EXTERNAL_COMM")) {
    return false; // Lethal trifecta detected
  }
  return true;
}

Trade-offs

Pros: Fine-grained; plays well with modular architectures. Cons: More tooling overhead; risk of permission creep over time.

References

  • Willison's warning that "one MCP mixed all three patterns in a single tool."