ollie/doc/nerv-outreach-draft.md

5.0 KiB

Outreach Draft: NERV Systems / Peter D. Finn

Subject: Independent 9P agent runtime — complementary findings on structural vs behavioral defense


Hi Peter,

I came across your "Namespace-Bounded Agents" paper while researching who else is working on 9P-based agent architectures. I've been building Ollie, an open-source AI agent runtime that independently arrived at similar structural properties — though from a different starting point.

Background

Ollie uses 9P as its coordination API (agent state, plans, peer messaging are all files in a namespace) and Landlock for execution sandboxing. I wasn't originally solving a security problem — I was solving usability and organization problems (different agents need different tools, composability with Unix tools, etc.). Over time, security concerns led me to add kernel-enforced sandboxing and a bypass broker for controlled escape.

Reading your paper, I realized the structure I'd evolved has security properties I hadn't formally characterized.

Our parallel finding on model compliance

Your paper distinguishes behavioral defense (model refusal) from structural defense (namespace enforcement). We documented the same insight from a different angle:

"Models don't follow multi-step loading protocols. When a model wants to read a file, it calls file_read. It doesn't first call client_9p to load file_read, then call file_read. The indirection step is almost always skipped regardless of prompt instructions."

We attempted progressive capability loading (Phase 36 in our evolution log) where agents started with minimal tools and loaded others on demand. It failed because models skip the loading step. Our fix was config-time enforcement via explicit autoLoad declarations — the capability boundary is set before the model runs, not dependent on model behavior.

Your data showing that GPT-4o attempts attacks (25% structural blocks) while Claude refuses (100% behavioral blocks) confirms the broader pattern: model compliance varies, so security boundaries must be structural.

Empirical validation

I ran an adapted version of your 31-attack corpus against Ollie's Landlock sandbox:

Configuration Attacks Blocked Hostile ASR
Strict policy 20 20 (100%) 0%
Real Ollie config 22 17 + 5 allowed by design 0%

The "allowed by design" operations (curl for API calls, /tmp writes, process listing) are usability trade-offs, not security failures. All path traversal, privilege escalation, and symlink escape attacks were blocked.

Differences in approach

Aspect NERV Ollie
Kernel Inferno (Plan 9 derived) Stock Linux 5.13+
Isolation mechanism Inferno namespaces Landlock LSM
Tool capability grant Namespace mounting Per-agent registry + autoLoad
Formal verification TLA+/SPIN/CBMC Working code, empirical tests
Escape mechanism Not mentioned Bypass broker with user approval

Both achieve the same security property: agents cannot call tools outside their capability set, enforced structurally regardless of model behavior.

What I'd be interested to discuss

  1. Your experience with Inferno deployment — does requiring a non-standard kernel limit adoption? Ollie runs on any modern Linux, which trades some elegance for accessibility.

  2. The bypass broker pattern — Ollie allows controlled sandbox escape with explicit user approval. Is this something you've considered, or does it violate your threat model?

  3. Config-time vs runtime capability grants — your paper shows namespace mounting; we found models don't reliably follow loading protocols, so we moved to config-time enforcement. Did you observe similar issues?

  • Ollie repo: [GitHub link when ready]
  • Documented findings: doc/lessons-learned.md — "Model compliance is not a security boundary"
  • Security evaluation: experiments/security-eval/RESULTS.md

Would be happy to share more details or compare notes on the different enforcement mechanisms.

Best, [Your name]


Notes for self (not for sending)

Tone: Collegial, not competitive. "We arrived at similar conclusions from different directions."

Key points to emphasize:

  • Independent discovery validates the approach
  • Empirical finding about loading protocols complements their formal analysis
  • Different trade-offs (Inferno vs Landlock) for same security goal

What NOT to claim:

  • Don't claim formal verification (they have it, we don't)
  • Don't claim novelty on security analysis (they published the paper)
  • Don't oversell — we solved usability problems, security properties emerged

Follow-up if they respond:

  • Offer to run their full 629-attack AgentDojo corpus
  • Discuss whether Landlock achieves equivalent isolation to Inferno namespaces
  • Explore potential collaboration on tooling or benchmarks

Contact options: