OpenShell Policy Persistence Memory — supervised promotion of repeated approvals into scoped durable policy

[Hardonian]

OpenShell already gets the hard part right: deny-by-default enforcement with explicit operator approval for blocked requests. What seems missing is a policy persistence memory layer that can safely transform repeated human-approved behavior into reviewable, scoped, durable policy knowledge.

Today there is a sharp gap between:

• static baseline / preset policy
• ephemeral session approvals

That is a good security default, but it means repeated real operator decisions do not accumulate into operational policy intelligence.

Proposed feature:
A supervised Policy Persistence Memory layer that would:

• record approved blocked requests with provenance
  • host / port / protocol
  • method / path pattern if available
  • initiating binary / assistant profile
  • operator identity
  • approval timestamp
  • repetition count / session count / denial count
• detect repeated stable approval patterns
• surface promotion candidates for review
• require explicit operator promotion into durable policy
• support scoped persistence
  • assistant
  • workspace
  • machine
  • org
  • global extension
• support expiry, review, rollback, and revocation
• preserve deny-by-default with no silent auto-whitelisting

The key idea is not convenience alone. It is giving OpenShell a supervised memory layer so repeated human decisions can become evidence-backed policy recommendations rather than being lost after each session.

That would make OpenShell much more practical for long-running assistants while preserving the security model.

A possible architecture split:

1. baseline policy
2. preset/tier policy
3. session approval layer
4. persistence memory layer
5. durable learned policy layer

Questions:

1. Is something like this already being considered?
2. Would this belong in OpenShell directly or at the NemoClaw layer?
3. Would maintainers want learned policy to remain fully explicit and review-driven, or is there interest in recommendation workflows based on observed approvals?

I think this would be a strong future direction because it improves operator ergonomics, auditability, and production-readiness without weakening deny-by-default.

Cheers,
Scott

[ljefford2-cmyk]

Interesting idea. I’ve been working on some adjacent issues around supervised policy promotion, but from the perspective of a governance/control-plane layer above the OpenShell/NemoClaw enforcement substrate rather than something necessarily implemented inside core NemoClaw.

The overlap I see is the same one you point to here: preserving deny-by-default while allowing repeated operator decisions to become evidence-backed, reviewable policy intelligence instead of disappearing after each session.

[Hardonian]

I like that a lot.

The current "allow/deny" loop in general is too ephemeral—we treat approvals as one-off gates and then bin the context. I’m leaning toward a model where approvals function as structured operational memory.

By capturing execution context, override patterns, and trust boundaries as persistent data, we move from static permissions to supervised policy governance. We get the benefits of an evolving system without losing operator control or trust.

Might even be worthwhile decoupling the stack:

Enforcement/Execution Substrate: stays deterministic, "dumb," and strictly fail-closed. This is the only way to ensure the system remains predictable; the substrate shouldn't be "smart," it should be an unbreakable anchor.

Governance & Policy Layer: handles the heavy lifting, lineage, trust scoring, and policy promotion.
This keeps the core safety model rock-solid while allowing the higher layer to learn from "replay evidence" and manage the actual evolution of trust.

[ljefford2-cmyk]

That split is exactly where I think the design should land.

I would not want “learned policy” inside the enforcement substrate itself. OpenShell/NemoClaw should stay deterministic and fail-closed: given a policy, it enforces that policy; it should not infer trust, mutate durable allowlists, or silently promote behavior.

Where I think this belongs is an approval-evidence/control-plane layer that produces policy proposals.

A possible lifecycle:

1. Observed denial

   • host / port / protocol
   • binary
   • HTTP method/path where available
   • assistant/workspace/machine identity
   • operator identity
   • timestamp
   • decision
   • session/run ID

2. Repeated approved pattern

   • same or compatible endpoint shape
   • same initiating binary/profile
   • same workspace or assistant scope
   • no conflicting denials or anomaly flags
   • sufficient count across sessions

3. Promotion candidate

   • generated as a proposed policy diff, not an applied rule
   • includes evidence summary and replayable provenance
   • recommends the narrowest observed scope, not a broader wildcard
   • includes expiry/review metadata by default

4. Explicit operator promotion

   • operator chooses scope: assistant, workspace, machine, org, or global preset
   • operator can narrow/widen before applying
   • durable policy revision is signed/audited
   • rollback and revocation remain first-class

That preserves the existing safety property: repeated approvals become evidence, not authority.

I also think the substrate/control-plane boundary is important:

• OpenShell enforcement substrate

  • captures denial/approval events
  • exposes policy-safe metadata
  • validates policy patches
  • enforces only explicit policy
  • remains fail-closed

• NemoClaw or governance layer

  • stores approval evidence
  • clusters repeated patterns
  • computes confidence/risk
  • generates proposal diffs
  • handles review queues, expiry, rollback, and org-level workflow

In that model, OpenShell does not need to become “smart.” It only needs stable event emission, policy patch validation, and maybe a proposal API. The intelligence lives above it, where it can be audited, disabled, versioned, and governed.

The key distinction I’d want to preserve is:

approvals can become evidence-backed recommendations, but never implicit authorization.

That would make long-running assistants much more usable without changing the deny-by-default trust model.