Summary

Add first-class AI safety and quality observability signals so OpenClaw operators can monitor non-deterministic agent behavior, prompt-injection exposure, source/citation quality, and human feedback through the existing diagnostics/OTEL/logging surfaces.

Problem to solve

OpenClaw already has useful operational observability: JSONL logs, trace correlation, diagnostics events, OpenTelemetry export, token/cost metrics, model-call timing, tool execution spans, queue/session metrics, and security audit checks.

However, for AI-native operation it is still difficult to answer safety/quality questions such as:

• Did this turn consume untrusted external content?
• Did the model encounter likely prompt-injection instructions?
• Was a suspicious instruction blocked, ignored, or passed through?
• Which tool call was requested, blocked, approved, or executed because of content from an untrusted source?
• Did a response rely on citations/sources, and were those sources actually used to support the claims?
• Did the user mark the response as wrong, unsafe, hallucinated, over-permissioned, or useful?
• Which memory/context items were selected, excluded, compacted, or persisted for a turn?
• Are safety events increasing for a given channel, agent, tool, model, or content source?

The current controls reduce blast radius — allowlists, sandboxing, approvals, tool policy, external-content wrapping, special-token sanitization, and security audit — but operators still lack a cohesive event stream for AI safety/quality posture. This makes it harder to meet the kind of AI-era observability expectations described in Google Cloud's “From twelve to sixteen-factor app” discussion: https://cloud.google.com/transform/from-the-twelve-to-sixteen-factor-app

This is not a vulnerability report and not a claim that prompt injection can be fully solved. Prompt injection remains a general risk for all tool-enabled LLM agents. The request is for better detection, telemetry, feedback, and auditability around that risk.

Proposed solution

Build on the existing diagnostics/OTEL/logging architecture with structured AI safety and quality events. Suggested scope:

1. Safety event taxonomy

Emit structured events/spans/metrics for:

• external_content.consumed
  • channel, agent, source type, tool/source name, content size/hash, trusted/untrusted classification, wrapper/sanitizer applied
• prompt_injection.signal
  • detection source, severity, pattern/category, source type, action taken: observed/warned/blocked/redacted
• tool_policy.decision
  • requested tool, decision: allowed/blocked/approval_required/approved/denied, policy reason, sandbox/elevated state
• safety.boundary_bypass_flag_used
  • e.g. allowUnsafeExternalContent, including agent/session scope and source
• memory_context.selection
  • count/hash/labels of memory/context items selected, excluded, compacted, or persisted; no raw private content by default
• source_quality.review
  • citation/source count, claim-check status, unsupported-claim count, stale-source warning, confidence category
• user_feedback.received
  • thumbs up/down plus optional labels such as wrong, unsafe, hallucinated, too much access, not enough access, useful

The important point is bounded metadata by default, not raw prompt/response capture.

2. OTEL/Prometheus/log integration

Expose counters/histograms/spans for dashboards and alerting, for example:

• prompt-injection signals per channel/agent/source/tool
• untrusted external-content turns per channel/agent
• blocked vs approved tool calls
• human approval frequency and denial rate
• unsafe-content bypass usage
• citation/source review failures
• user negative-feedback rate by model/agent/channel
• memory/context write or persistence events

These should follow the existing privacy stance: no raw prompt, response, tool input, tool output, or system prompt content unless existing explicit content-capture options are enabled.

3. Minimal operator UX

Add a lightweight way for operators to inspect the safety timeline for a turn/session, either in CLI, logs, or Control UI:

• per-turn safety summary
• external content sources consumed
• policy decisions taken
• blocked/approved tool calls
• feedback labels
• links to trace IDs / session/run IDs

4. Optional feedback controls

Where channels/UI support it, allow users/operators to mark responses as:

• useful
• wrong
• hallucinated
• unsafe
• excessive tool access
• insufficient tool access
• poor citation/source support

Export the labels as diagnostics events so they can feed dashboards and later eval/regression datasets.

5. Optional prompt/spec-as-code follow-up

A later phase could support versioned agent behavior specs, golden prompts, and regression/eval runs. That may be separate from this issue, but the telemetry above would provide the raw signal needed for it.

Alternatives considered

• Rely only on existing logs/OTEL metrics: good for operational debugging, but not enough for AI-specific safety and quality questions.
• Enable raw content capture: useful in controlled debugging, but not acceptable as the default because prompts, responses, tool payloads, and system prompts may contain sensitive data.
• Build a broad external governance layer: likely too wide for core and similar proposals have been closed as better suited to plugins/ClawHub. This request is narrower: add core diagnostic events and surfaces that plugins and dashboards can consume.
• Rely only on prompt instructions: insufficient. Prompt-injection mitigation needs hard controls, audit trails, and observable safety decisions, not only model guidance.

Impact

Affected users/systems:

• Operators running OpenClaw with messaging channels, browser/web tools, file tools, exec, cron, hooks, or memory enabled.
• Anyone using OpenClaw in environments where untrusted content may be read: web pages, emails, documents, attachments, chat messages, logs, code, or issue bodies.
• Plugin authors building safety, audit, evaluation, or governance integrations.

Severity:

• Medium to high. Existing controls reduce risk, but operators lack enough structured visibility to detect trends, prove controls worked, or build safety dashboards without custom instrumentation.

Frequency:

• Continuous for tool-enabled agents. Every turn that reads external content or requests tools could benefit from structured safety/quality telemetry.

Practical consequences:

• Harder to audit why a tool was used or blocked.
• Harder to detect repeated prompt-injection exposure.
• Harder to measure hallucination/source-quality issues.
• Harder to turn user feedback into regression tests or model/tool-policy improvements.
• Harder to satisfy AI-era operational expectations around non-deterministic systems.

Evidence/examples

Related OpenClaw issues that this should complement rather than duplicate:

• [Feature] Content-based prompt injection scanning on tool output #79168 — content-based prompt injection scanning on tool output
• [Feature]: Prompt injection defense at tool result and message boundaries #62939 — prompt injection defense at tool result and message boundaries
• Tool call observability: input sanitization, error categorization, and context writeback #55806 — tool call observability: input sanitization, error categorization, and context writeback
• Plugin Hooks: Missing trace context for observability (messageId, runId in all hooks, parentSpanId) #50291 — missing trace context for observability in plugin hooks
• Observability gap — gateway.log lacks per-turn response duration and content hash; byte-identical stuck-loops are undetectable from gateway logs alone #81004 — response duration/content-hash observability gap
• Subagent lifecycle observability + async supervision controls #38626 — subagent lifecycle observability
• Unified run trace schema across agent, ACP, subagent, and task flows #68204 — unified run trace schema

Relevant existing docs/features observed:

• OpenTelemetry export already covers metrics, traces, and logs for model usage, model calls, tool execution, exec, message flow, context assembly, and memory pressure.
• Logging already supports trace correlation and redaction.
• Security docs explicitly note that prompt injection is not solved and must be mitigated with allowlists, sandboxing, tool policy, approvals, and model choice.
• Existing content capture is intentionally opt-in, which is the right privacy default; this request is for structured safety/quality metadata that remains useful without raw content capture.

Additional information

Suggested implementation approach:

1. Start with diagnostics event schema only, emitted from existing boundaries:
   • external-content wrapping/sanitization
   • tool policy/approval decisions
   • tool execution result path
   • memory/context assembly
   • feedback/reaction handling where available
2. Export via existing diagnostics-otel / diagnostics-prometheus plugins.
3. Add CLI/Control UI summaries later once the event stream is stable.

This should remain backward-compatible and opt-in where content or potentially sensitive metadata is involved. Default telemetry should use bounded identifiers, hashes, categories, counts, and policy outcomes rather than raw content.