Summary

Add hook surfaces needed for trust-aware security/provenance plugins (identity context, loop observability, LLM/tool/response interception, and session-memory controls).

Problem to solve

Security/provenance plugins need intervention points, not just observation. Today it’s hard (or impossible) for a plugin to reliably:

• determine who triggered a run (owner vs non-owner, group vs DM, provenance chain) in a consistent hook context
• observe iteration/loop behavior for guardrails and debugging
• filter/block tool calls based on trust/taint policies as a batch after the LLM responds
• redact/block the final response/tools before used or emitted and persisted
• prevent/quarantine/redact session-memory persistence for sensitive conversations

Without these, policy plugins either can’t enforce controls or must rely on brittle workarounds.

Proposed solution

A small series of additive PRs that expand the hook surface and session-memory policy controls while keeping each change reviewable and low-risk. Exact event/result shapes and detailed semantics live in the PRs; this issue is intended to provide the motive and rationale behind developed, proposed solutions to these problems.

Proposed merge order:

1. Identity context plumbing: feat(hooks): add sender identity and session context to plugin hook agent context [claude, human developer oversight] #33914
2. Loop observability hooks (void/parallel): feat(hooks): add context_assembled, loop_iteration_start/end observability hooks [claude, human developer oversight] #33915
3. Session-memory policy controls (block/quarantine/override content): feat(hooks): add session memory policy controls (blockSessionSave, redirectPath) [claude, human developer oversight] #35567
4. New content/tool-mutating interception hooks (largest): feat(hooks): add before_llm_call, after_llm_call, before_response_emit tool/content mutating hooks [claude, human developer oversight] #33916

Alternatives considered

• Bake security/provenance into core instead of as a plug-in: heavier architectural commitment; less flexible than providing hook primitives; genuinely believe in plugin power as an alternative to a massive openclaw core
• Rely only on existing void hooks (llm_input/llm_output) + before_tool_call: still missing early LLM input filtering, batch tool-call gating, and response emission gating.

My belief at the moment is that something of this shape is necessary for the kind of plugin that can address prompt injection risks in a deterministic way.

Impact

• Enables a new class of security/provenance plugins to implement trust-aware controls without invasive core changes.

Evidence/examples

• I’ve been running my openclaw-provenance and openclaw-vestige plugins locally for ~1 month: https://github.com/zeroaltitude/openclaw-plugins/,
• openclaw-provenance: demonstrates trust/taint tracking that can dynamically gate tooling during an agent run (e.g. content fetched from an untrusted URL taints context and blocks subsequent exec). Screenshot below shows a live example while building a PhaserJS OpenClaw dashboard,
• Hooks used: after_llm_call (batch tool-call filtering/blocking), before_response_emit (optional output gating), identity/loop hooks for provenance context,
• openclaw-vestige: deterministically injects salient memories into the prompt by modifying context right before the LLM call,
• Hooks used: before_llm_call (inject/remove content). Measured overhead: ~50ms pre-staging per call in my setup (DeBERTa-based scoring)

Additional information

In local production for ~1mo. Developer working with well-groomed agents.