Integration interest — SAFE authorization layer + node9 governance

[rudi193-cmd]

Hi node9 team — I came across node9-proxy and it maps well onto something we're building. We have SAFE (Sovereign Authorized Prompting), a consent/identity-first authorization layer for a local AI agent fleet. SAFE gates at the manifest level (per-app permissions, ratification flow); node9's behavior-first approach (bash AST, tool pinning, credential-in-args detection) covers the gap SAFE does not address.

We're planning a hardening pass on SAFE and want to pull in the rug-pull protection and credential leak detection patterns from node9. Interested in any collaboration, feedback, or whether there's a clean integration point between an identity layer and node9's policy engine.

Happy to share more about the SAFE spec if useful.

[node9ai]

Hey @rudi193-cmd — sorry for the slow response, this slipped through.

The framing you laid out is exactly right: manifest-level identity/consent and behavior-level execution policy are complementary, not overlapping. node9 deliberately doesn't touch the identity layer, so a split where SAFE handles "is this agent allowed to attempt this class of action" and node9 handles "is this specific tool call safe given everything else we know" is genuinely clean.

On the rug-pull / credential-in-args patterns: the policy engine ships separately at @node9/policy-engine (~50KB, Apache-2.0, takes a normalized tool call → allow/deny/ask + reason). You're welcome to use it directly, fork the rules, or just lift the patterns.

Two questions before I dig in further:

1. Is SAFE public somewhere I can read the spec or code? Curious about the manifest format and the ratification flow.
2. Is this primarily research/spec work, or are you shipping to actual deployments? Changes how I'd think about the integration shape.

Either way, happy to keep talking through the design.

— Nadav

[rudi193-cmd]

Thanks Nadav — glad the framing landed, and no worries on the delay.

1. Is SAFE public?

Yes — the spec and code are open:

• Fleet contract: willow.md — boot path, trust model, namespace rules
• Gate implementation: sap/core/gate.py — manifest lookup, PGP verify, permissions[] → tool groups
• Manifest format: app_id, name, version, permissions[], GPG-signed by a single root key. Agents live in ~/SAFE/Agents/, apps in ~/SAFE/Applications/

Ratification flow today: Sean signs manifests; agents with ENGINEER trust bypass PGP in dev but still hit per-tool ACL. Cross-namespace writes need an explicit sap.app_connections row — "direction is not authorization."

2. Research or shipping?

Shipping. Willow 2.0 is a local-first agent fleet (Postgres KB, SOIL store, Grove bus, Kart task queue) running daily on real hardware — beta, single operator, but not a paper spec. The node9 split you described is exactly what we need next: SAFE answers "is this agent allowed to attempt this class of action?"; node9 answers "is this specific tool call safe?"

We're planning a hardening pass and @node9/policy-engine looks like the right shape to evaluate — normalized tool call → allow/deny/ask. Would be happy to spike an adapter (SAFE manifest pass → node9 policy pass → MCP dispatch) in a branch if you're open to a design thread.

What's the best way to engage — issue on node9-proxy, or a short spec doc comparing the two layers?

[node9ai]

Thanks Sean — that's exactly the answer that makes this worth pursuing. Willow shipping on real hardware + the layered framing you laid out is what I needed to know.

For the adapter spike: I'd point you at @node9/policy-engine on npm directly. It's the standalone package, ~50KB, designed for exactly this use case — take a normalized tool call, return allow/deny/ask + reason, no node9-proxy dependency. README at the npm page covers the surface.

The pattern that fits your architecture cleanly:

agent tool call
  → SAFE manifest pre-pass (per-app permissions, ACL)
  → @node9/policy-engine (per-call behavior policy)
  → MCP dispatch

Each layer has a single concern. SAFE doesn't have to know about bash AST or rug-pull detection; the policy engine doesn't have to know about your manifest format.

If you spike that and run into anything that doesn't fit the policy-engine surface — missing rule, weird normalization, context you'd want passed through — file issues on node9-proxy. That's the right feedback shape and I'd be glad to act on real signal from real use.

A few things I'd want to know once you have it running:

1. Latency overhead of the policy-engine pass in your hot path (we benchmark ~8-15ms but real-deployment numbers are more interesting)
2. Whether you'd want a "context object" extension — e.g., SAFE could pass identity info that the policy engine can key into rules
3. Which rule patterns from node9 (rug-pull, credential-in-args, blast radius) translate cleanly vs. need SAFE-aware variants

No pressure on timing — Willow obviously has its own work. Keep me posted in this thread when something runs end-to-end. Happy to amplify if it ships.

— Nadav

[rudi193-cmd]

Thanks Nadav — @node9/policy-engine as the standalone spike target is perfect. I'll wire a thin SAFE gate → normalized tool call → policy-engine adapter on the Jetson side and report back on latency/overhead once it's exercised against real MCP dispatch (not just synthetic calls).

Will keep the split clean: SAFE manifest/trust for who may attempt, policy-engine for this specific call. Will tag you when the spike branch is up.

[rudi193-cmd]

Spike branch is up: spike/node9-policy-engine

Pattern implemented (opt-in via WILLOW_NODE9_POLICY=1):

MCP tool call → SAFE manifest ACL (permitted) → @node9/policy-engine → dispatch

• Adapter: sap/adapters/node9_policy/ — @node9/policy-engine@1.5.0, evaluate.mjs CLI
• Bridge: sap/core/node9_policy_bridge.py — Python subprocess wrapper
• Hook: sap/middleware.py step 4.5 (after manifest, before write sanitizer)
• Bench: scripts/bench_node9_policy.py

Early latency numbers (honest): subprocess-per-call on this host is ~230ms p50 — node cold-start dominates. Your ~8–15ms benchmark is in-process; next step is a persistent node worker (or embedding policy-engine in a long-lived sidecar) before this hits the hot path on Jetson.

Context object question: currently passing { agent/app_id, cwd } into PolicyContext. Would you want SAFE manifest fields (trust level, namespace, permissions[]) forwarded as an extension block for rule authors?

Happy to file issues on node9-proxy for anything that doesn't fit the surface once this runs against real MCP dispatch on hardware.

[rudi193-cmd]

Update: PR is up — rudi193-cmd/willow-2.0#24

Added persistent worker since the last note. Benchmark on dev host:

Mode	p50	Notes
Persistent worker (default)	~2ms	worker.mjs — config loaded once
Subprocess per call	~230ms	node cold-start dominates

So your in-process ~8–15ms range looks reachable once the worker is warm. Subprocess was the misleading number in my earlier post.

Still opt-in (WILLOW_NODE9_POLICY=1). Next: real MCP dispatch on Jetson hardware.