MOD-17269 Document Agent Memory sensitive-data exclusions - #3760
Merged
Conversation
Add a Sensitive-data exclusions section to the Redis Cloud Agent Memory create and view pages, covering the semantic exclusions toggle and exclusion prompt, the advisory limits, which memory paths exclusions apply to, and the prompt validation rules. Phase 1 ships semantic (prompt-based) exclusions only. The authored prompt is injected at system-message priority into the three LLM-mediated promotion paths (INSTRUCT promotion, custom extraction, session summarisation), so the docs say plainly that direct long-term writes and raw session events are untouched, and that the policy is advisory rather than a guarantee. The rejected-phrasing table exists because the injection guard refuses ordinary prose — a bare occurrence of the word "system" followed by a colon matches the instruction-override rule, as do "forget everything" and "ignore all instructions". All six strings in that table were verified against the patterns in iris memory-common/domain/valueobjects/prompt.go. Learned: The exclusion-prompt injection guard rejects innocuous customer prose, which the UI error message does not explain. Constraint: Publish only once isAgentMemorySensitiveDataExclusionsEnabled is enabled in production; the UI card is flag-gated and ships dark. Gaps: On-prem YAML authoring (MOD-17150) and the exclusions preview playground (MOD-17161, MOD-17162) are unmerged and undocumented; neither public OpenAPI spec exposes longTermMemoryExclusions yet. Ticket: MOD-17269 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
🧠 Redis MemoryFound 7 related items from repository history:
Memory updated at 61c4de4 |
Contributor
Drop the example exclusion prompt's code block and the prompt-assembly detail from the section intro. The fenced block was the only code block in the file, and the closest analogue — the Extraction prompt field for custom memory types, another free-text natural-language setting — carries no example at all. It was also redundant once the rejected-phrasing table landed, since that table already shows six concrete prompt strings. The example survives as prose, matching how Automatic summarization presents its worked example. The intro previously described how the authored text reaches the model, which is prompt plumbing a customer cannot act on, and said "promoting" — vocabulary used nowhere else in this page, where every other reference is to the extraction pipeline. The warning below already establishes that exclusions only steer the model, so the causality survives the trim. Directive: Keep "extraction pipeline" in this page's prose; "extraction model" is reserved for quoting the UI's own wording, which is visible in the screenshots. Ticket: MOD-17269 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
🧠 Redis MemoryFound 5 related items from repository history:
Memory updated at e723770 |
Review of the exclusions docs against the shipped implementation in iris (origin/main) turned up two factual errors and two omissions. "Where exclusions apply" listed automatic summarization as a covered path. It is not: buildSummaryViewMessages injects the exclusion section only on the session_summary_view path, and its doc comment states that summarisation keeps using the unmodified prompt builder. The TDD lists session summarisation as an explicit non-goal. Name the summary-view memory type in the covered list instead, and add automatic summarization to the "do not apply" list so the omission cannot be read as coverage. The prompt rules told customers to avoid the bare words forget, ignore, pretend, and simulate. The injection guard matches phrases, not words — forget\s+(everything|all|previous), ignore\s+(previous|all|above)\s+ instructions?, pretend\s+(?:you\s+are|to\s+be), simulate\s+(?:a|being) — so all four words pass on their own. Describe the blocked phrasings instead, note that system= rejects as well as system:, and add rows for two traps an ordinary prompt hits: override\s+(system|instructions?) and run\s+(?:code|command|script). On the view page, state that flushing is the only way to clear previously stored memories and that it erases all of them, and repeat the advisory caveat where the setting is actually edited. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
🧠 Redis MemoryFound 5 related items from repository history:
Memory updated at 747bbce |
Collaborator
|
Hi, the merge of Raphael's refactor has moved these two pages to content/operate/iris, if you can update this pr to add your new content there please. |
main moved the Redis Cloud Iris pages from content/operate/rc/context-engine/ to content/operate/iris/ and, in the same window, added its own shorter Sensitive-data exclusions section to both pages. The merge therefore had to reconcile two independently written versions of the same section rather than just follow a rename. Kept this branch's version, which is a superset: it carries the screenshots, the "Where exclusions apply" coverage list, and the "Exclusion prompt rules" guidance with the rejected-phrasing table. Folded in what main's version said better: the explicit heading anchor, "the extraction model provider" over "the model provider", "through the API or an SDK" over "your application writes directly", and its example data (passwords, access tokens, recovery codes, payment card information, booking confirmation codes). Dropped main's fenced example block. It was the only code block in create-service.md, and the rejected-phrasing table already carries concrete prompt strings, so the example stays as prose next to the settings table. Repointed the view page's relref at /operate/iris/agent-memory/create-service and took main's "Redis Agent Memory service" wording in the Actions bullet. Constraint: Exclusions do not cover automatic summarization; the exclusion section is injected only on the session_summary_view path. Do not re-add summarization to the covered list. Ticket: MOD-17269 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The "Where exclusions apply" subsection read as an implementation map: it framed coverage as "the memory paths that use the extraction model" and named the session_summary_view recap to explain which of those paths are wired up. None of that is actionable for someone filling in the field. It was also mostly duplication. The advisory warning above already states that exclusions are not a guarantee, that content reaches the extraction model provider, and that they do not apply to long-term memories created directly through the API or an SDK — three of the four bullets. Two sentences carry what was left: exclusions apply when long-term memories are created from a session, and session memory is untouched. The second half is worth keeping because a reader could reasonably assume a summary of a sensitive message gets filtered, and it does not. Uses "session memory" rather than "short-term memory". The develop docs never use "short-term memory" at all (0 occurrences; "session memory" appears 38 times), and it survives on the console pages only as a gloss on the Short-term TTL field label, so it is the UI-driven alias rather than the house term. Directive: Prefer "session memory" over "short-term memory" in Agent Memory prose; the latter is only for describing the Short-term TTL field. Ticket: MOD-17269 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The subsection documented the prompt-injection guard as though it were specific to exclusions. It is not: Prompt.Validate and ExclusionPrompt.Validate both call validation.By(validateNoInjection), differing only in their length bound (10,000 runes for a custom extraction prompt, 2,000 for an exclusion prompt). The custom extraction prompt has carried that guard all along with nothing written about it, so documenting it under exclusions made two identical fields look different. Both settings tables now state a length bound and nothing more, which is the parallel treatment. This does leave a real gap: cloud-ui relays the server message straight to the field, so a rejected prompt reports "must not match a <category> injection pattern" with no hint about which phrasing caused it, for either field. The fix is to document the guard once somewhere both fields can reference, which means editing the custom-extraction section and is outside this ticket. Tracked separately rather than left half-done here. Gaps: The prompt-injection guard is undocumented for both prompt fields; a rejection surfaces only iris's raw category message. Ticket: MOD-17269 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The section intro described the whole feature in terms of the only mechanism that ships today: "describe, in plain language" and "the extraction pipeline uses your description as guidance" are true of a semantic prompt and of nothing else. The advisory warning had the same problem, and it sat above the mechanism heading where it read as a property of exclusions in general. Restructured so the section intro states only what the section is for, and every claim that depends on how exclusions are evaluated now lives under Semantic exclusions: the plain-language framing, the scope sentence, and the advisory caveat. A second mechanism becomes a sibling subsection with no edit to the intro, the note, the screenshot, or the page's section list. Moving the warning below the prompt settings also matches the console, where the advisory banner renders under the prompt field rather than above the toggle. Deliberately says nothing about mechanisms that are not shipped. Directive: Keep the Sensitive-data exclusions intro mechanism-neutral. Anything that depends on how an exclusion is evaluated belongs under its mechanism's subsection. Ticket: MOD-17269 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
seth-riedel
approved these changes
Aug 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ticket: MOD-17269 (epic: MOD-17267)
Documents the Sensitive-data exclusions card on the Redis Cloud Agent Memory console pages, placed to mirror where the card sits in the UI (last in the create flow, before Actions on the Configuration tab).
Availability framing
The feature is enabled per account rather than generally available, so both pages carry a note:
This follows the existing private-preview note on the self-managed Agent Memory index page. This PR is safe to merge — readers who don't have the feature are told how to ask for it.
What this adds
create-service.md— the semantic exclusions toggle and exclusion prompt (2,000 char limit, required when enabled), an advisory warning, an example, a "Where exclusions apply" coverage list, and the prompt validation rules.view-service.md— the read-only/editable settings, that disabling preserves the saved prompt, and that existing memories are not re-evaluated (flush being the only way to clear them).Scope
Phase 1 is semantic (prompt-based) exclusions only. The docs state that exclusions are advisory, that content still reaches the extraction model provider, and that they do not apply to long-term memories created directly through the API or an SDK.
Coverage is deliberately precise: exclusions apply to built-in extraction (including the
session_summary_viewrecap) and custom memory types, but not to automatic summarization, which compresses messages within a session and never writes to long-term memory.Not covered, because unmerged and not publicly exposed: on-prem YAML authoring (MOD-17150), the preview playground (MOD-17161 / MOD-17162), and
longTermMemoryExclusionsin either public OpenAPI spec.Merge note
mainmoved these pages fromcontent/operate/rc/context-engine/tocontent/operate/iris/and separately added its own shorter exclusions section. The merge commit reconciles the two: this branch's fuller version is kept, with main's better phrasings, heading anchor, and example data folded in, and main's fenced example block dropped (it was the only code block in the file). Net change againstmainis 4 files.The rejected-phrasing table
#### Exclusion prompt ruleslists phrasings the injection guard refuses, because it rejects ordinary customer prose and the UI error does not explain why. All strings in that table were verified against the live patterns inmemory-common/domain/valueobjects/prompt.go. The guard matches phrases, not bare words —forget everythingandoverride systemreject, whileforgetalone passes.Verification
.claude/hooks/check_shortcode_paths.py --scanreports 0 issues, 0 broken file refs, 0 broken relrefs on both pages. Every in-page anchor referenced has a matching heading, and the view page's relref was repointed at the new/operate/iris/path.🤖 Generated with Claude Code
Note
Low Risk
Documentation-only changes to operate guides; no runtime, auth, or data-path code is modified.
Overview
Documents the Redis Cloud Agent Memory “Sensitive-data exclusions” UI on the create and view service guides under
operate/iris/agent-memory/, aligned with where the card appears in the console flow.On create-service, the section is promoted in the custom-create outline and rewritten around semantic exclusions: early-access note, screenshot, toggle and exclusion prompt (2,000 characters, required when enabled), example behavior (generalized memories vs dropping detail), scope (extraction to long-term memory only; session memory unchanged), and a stronger advisory warning (model provider exposure; no effect on API/SDK-created memories).
On view-service, the Configuration tab lists the card; the section links back to create docs, adds the same availability note and screenshot, documents editable settings, explains that disabling preserves the saved prompt, and clarifies that existing long-term memories are not re-evaluated—only a full flush clears data stored before exclusions were configured.
Reviewed by Cursor Bugbot for commit 61c4de4. Bugbot is set up for automated code reviews on this repo. Configure here.